大模型在知乎舰桥平台的应用和实践

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