《大模型在知乎舰桥平台的应用和实践.pdf》由会员分享,可在线阅读,更多相关《大模型在知乎舰桥平台的应用和实践.pdf(25页珍藏版)》请在三个皮匠报告上搜索。
1、DataFunSummit#2023大模型在知乎舰桥平台的应用和实践演讲人-侯容-知乎-舰桥平台 Leader自我介绍姓名:侯容Title:舰桥平台 Leader个人简介:18 年入职知乎,曾担任社区、社交等业务高级研发和业务架构师,21 年加入平台团队担任用户理解&数据赋能组研发Leader。带领团队从 0 到 1 从底层到业务层搭建实时数据基建和业务,同时整合资源完成用户理解工程及 DMP 的建设。目前担任舰桥平台Leader,从 0 到 1 搭建知乎舰桥平台(一站式内容&用户管理平台。面向找人、找内容、盯人、盯内容、找机会、查问题六大核心的筛选、打包、分析、监控的运营平台)。今年随着大模
2、型的发展,将3个适用于大模型应用的典型场景在舰桥中完成了落地。业务现状和背景01知识体系分类整理 业务背景 困难与挑战 事件聚合-解决方案 事件聚合 业务效果 知识整理 解决方案 知识整理 业务效果02自然语言转筛选条件 业务背景及困难与挑战 解决方案 微调 问题与解决 版本 1&版本 2 问题与解决 版本 3 业务效果03自然语言数据分析 业务背景及困难与挑战 解决方法 动态 prompt 业务效果04总结与展望 总结 痛点 展望目录CONTENTDataFunSummit#202301 知识体系分类整理业务背景困难与挑战聚不上的 case:布克全面发挥,带队反弹胜利。太阳将与掘金对战。NB
3、A季后赛,太阳淘汰快船晋级。过度聚合的 case:科大讯飞申请星火大模型商标。“熊猫丫丫”已被多方申请注册商标。事件聚合-解决方案整体分 4 个阶段1、新闻提前关键信息并处理成向量。2、多轮高准聚类直到无法聚类。3、一轮高召聚类,通过大模型判断聚类节点中事件是否相同。4、生成事件-新闻的最终结果。事件聚合 业务效果业务效果输入:新闻标题和正文。输出:事件名,该事件下的新闻列表。问题如何被解决?max token 问题:由于通过层次聚类先过滤了一把,进入 LLM 的 prompt 长度都比较小。聚不上和过度聚:在阶段 3,score 较低左边的 case 都在一个节点内,LLM 可以根据语义判断
4、是否是一个事件。优点:事件名可以自动生成,无需人工介入。准确率的提升,较早期方法左边的 case 是无法解决的,通过引入大模型进行语义判断解决。缺点:目前事件是否需要合并断比较依赖基础模型。长期计划通过微调和升级模型来进一步提升对事件是否合并的判断。知识整理-解决方案简介构建了类似数据处理 map-reduce 框架的算子,并实现了左图的流程。流程1、内容拆分,确保 prompt 不超过 max token。2、map:每组内容生成分类名。3、reduce:分类名两两合并,直到无法合并。4、map(join):将分类和单条内容生成 prompt,完成内容分类。5、结果写入文件,并根据 grou
5、p by 后的数量决定是否需要递归从 1 开始执行。n、将最终所有文件 merge 成一个结果文件。问题如何解决?绕开 max token:先将内容按照 max token 拆分,形成分类,再进行分类合并绕开。如何快速处理大量内容:将任务抽象成 map-reduce 节点,同一 stage 节点可并发,保障并行度。如何对大模型限速:map 和 reduce 节点中任务是一个通用的 task,在该 task 的调度队列针对集群统一限速。知识整理-业务效果业务效果输入:内容标题或摘要。输出:按为大小的多层级分类。包括一级、二级等等分类名、层级数以及该分类下的内容。使用场景精细化运营场景的知识体系构
6、建(查漏补缺)。活动场景的二级分类快速搭建和冷启动。也有部分同学用于了个人资料整理。优点:低成本,0 人工介入,全流程自动。缺点:比较依赖基础模型自身对内容的理解。DataFunSummit#202302 自然语言转筛选条件业务背景及困难与挑战解决方案 微调选型纯 PE:简单,但随着深入和准确率要求,无法进一步提升。微调:投入成本高,但随着投入可提升准确率,同时可以和基础模型升级结合。解决方案造数据微调。数据构造思路阶段 1 基于原子条件构造筛选条件。累计浏览量大于 5000 的内容。阶段 2 将原子条件完成交并差构造筛选条件。2023年发布的二级贝叶斯分类为手机游戏的内容。阶段 3 将模糊语
7、句构造筛选条件。近期比较好的内容,排除掉低质创作者。阶段 4 逻辑错误筛选条件2023年表现比较好的想法,发布时间小于2022年,返回逻辑错误。问题与解决 版本 1&版本 2(阶段一)版本 1问题:输出与输入毫不相干。原因:基础模型缺乏逻辑能力。解决方法:对基础模型增加大量逻辑样本(也就是代码、数学题)并训练。版本 2问题 1:JSON 存在截断原因:max token 原因,过长截断。解决方法:调长 max token。问题 2:存在进入重复后,一致重复原因:进入某一个概率后,相同字或者词的概率始终最高。解决方法:使用 random sample 解决。问题与解决 版本 3(阶段一)本次结果
8、(完全准确 72%幻觉 17%格式错误 11%优化方向问题1:JSON 格式错误解法:构造一大量 JSON 的样本。问题2:存在额外条件解法:随机条件组合构造样本。问题3:大于小于号错误解法:将筛选条件随机生成多种大于小于的样本。问题4:且或非理解错误解法:随机组合条件生成一批且或非的样本。问题5:时间区间理解成时刻解法:将多个时间类筛选条件构造一批样本。问题6:条件部分缺失解法:随机条件组合构造样本。问题与解决 版本 4(阶段二)本次结果完全准确 95.59%幻觉 2.64%格式错误 1.77%结果:基本满足简单使用,上线。优化方向模糊问题构造构造一批例如:高质量创作者创作的优质大模型回答内
9、容,进行微调。根据用户实际使用中的 case 定向解决根据用户实际反馈的问题,生成对应的样本继续进行微调解决。业务效果结果描述输入:自然语言。输出:对应的筛选条件组合。业务效果降低了使用成本,用户使用量提升,提高了整体的工作效率。新手友好,很多新同学通过自然语言转筛选开始学会使用这一功能,降低推广成本。改变了传统的新标签、新特征推广方式,将新标签上线后对各业务方宣讲,转变为自动翻译成新标签的形式,提升了沟通效率,降低了协同成本。待优化点模糊语言:近一个优秀作者写的高质量内容。DataFunSummit#202303 自然语言数据分析业务背景解决方法 动态 prompt选型纯 prompt:无法
10、解决,一方面是 ads 表太宽了,max token 放不下。另一方面是 few shot固定的话会忽略查询语句,效果不好。微调:投入成本高,需要较多的样本才能达到比较满意的结果。动态 prompt:prompt 中的表字段和 fewshot 根据和查询语句最相近的查询生成。解决方案动态 prompt。流程初始化:将样本处理成问题、查询字段、SQL,将问题转成 embedding 存入 FAISS用户查询:将问题转成 embedding 并通过 MMR 找到类似的问题 Top10。根据 max token 生成合适的 prompt:绿色:去重后的列名。浅蓝:查询例子。深蓝:本次用户问题。业务效
11、果问题及解决方法问题 1:早期使用余弦相似,类似的样例太多,效果不好。解法:改用 MMR 通过多样性避免 prompt 输入不够。问题 2:如何尽可能将查询与数据源关联好。解法:这块的确困难,因为不同数据源直接总有些名称相似的字段。所以采用产品方案,左上角将业务名称和可用数据源做了关联。问题 3:用户输入的自然语言很泛,如何在这种情况下尽可能准确的满足用户需求?解法:由于使用的是动态 prompt,这部分问题就转化为如何丰富样例,虽然 SQL 是无法枚举的,但用户的口语习惯随着逐渐增多的样例就能变好。当前的问题准确率不足:当前由于分析场景还是很灵活多变的,简单的 case 表现还行,但一旦复杂效果就不好。后续计划对模型进行 fine tune,进一步加强在各业务场景的表现效果。DataFunSummit#202304 总结与展望总结与展望感谢观看