管理网站建设哪家公司好,旅游网站开发与设计论文,白石龙做网站,哈国际现货交易平台背景
ChatGPT诞生之初#xff0c;大家仿佛从中看到了未来#xff1a;可以拿着大语言模型#xff08;LLM#xff09;这把锤子#xff0c;锤遍业务上的钉子。其中最被看好的场景#xff0c;莫过于搜索#xff0c;不仅是微软、谷歌、百度这样的大公司将LLM用到自己的搜索业…背景
ChatGPT诞生之初大家仿佛从中看到了未来可以拿着大语言模型LLM这把锤子锤遍业务上的钉子。其中最被看好的场景莫过于搜索不仅是微软、谷歌、百度这样的大公司将LLM用到自己的搜索业务中Github上也有很多知识库、文档问答相关的优秀开源项目究其本质是通过检索相关知识来增强LLM的回答效果。
搭建一个检索增强pipeline其实很简单“embedding模型向量检索LLM”这一套组合拳就足够而且LangChain中都已经封装好了简单写几行代码调用就能收工下班但如果认真去分析最终回复的效果就会发现这个pipeline只完成了工作的冰山一角而本文会展开聊聊冰山之下的秘密。
分片检索回答
首先需要对整体的流程进行概述 文本分片。不同格式的原始数据需要转成文本。因为文本在后续的操作中会拼接到prompt中所以对于过长的文本需要进行分片控制在一定的长度之内。 文本检索。离线阶段可以将文档片段都进行embedding将embedding向量存储到向量数据库中在线阶段将用户query的embedding向量在向量数据库中进行检索返回TopK的相关文档。 LLM回答。将TopK的相关文档组织成prompt请求LLM得到最终的回答。
这三个步骤环环相扣每一个环节的错误都会层层传递到后续的环节。下面会分别介绍这三个环节中可能会碰到的挑战。 图来源于[3]”分片“对应图中第1、2步”检索“对应第3、4步”回答“对应第5步
文本分片
文本数据抽取
且不论多模态数据单单是文本数据的存储格式常见的就有TXT、Word、PDF、Latex、CSV、Excel、HTML、Markdown……不同格式的数据要转成纯文本需要话费不少功夫即使是Langchain-Loaders[1]已经提供了多种格式的文本提取接口但对于复杂格式的文件提取效果依然不太理想如PDF。这时候就需要投入更多精力来进行数据清洗否则会直接影响到最终的效果。
语义完整性
Langchain-Doc Transformers[2]中介绍了按照长度、指定符号句号、换行符这些简单的规则进行文本分片的方法但用这些方法得到的分片很多情况下会有语义不完整的问题比如 文档格式转换如PDF无法识别段落出问题 整体语义蕴含在长文本中 当文档编写者不遵守语法胡乱断句换行 ……
为了保证语义的完整性可以尝试以下方案 使用模型比如Bert进行分片而不是简单的依靠规则切分。 对文档进行摘要这样可以大幅缩短文档的篇幅保证语义的完整性。 使用LLM根据文档构造多个QA pair由于LLM可接受的prompt长度会大于文本片段的长度通过这种方法得到QA pair能够将距离较远的信息有结构地组织到一起控制在可接受的长度内。
文本检索
过滤无关文本片段
如果只是取检索结果的TopK拼接到后续LLM的Prompt中那TopK中难免会有和用户问题不相关的结果所以需要进行过滤尽量保证给的LLM的都是相关的文本片段。
常用的过滤方式就是根据相关性分数过滤了可以选择一个阈值丢弃相关性低于该阈值的文档。这么做的前提需要Embedding模型最好满足以下要求 Embedding模型返回的向量最好是归一化后的这样使用内积或欧氏距离表示相关性时取值都在固定范围内容易选择阈值。 Embedding模型最好做过**校准(Calibration)**。校准这一操作在CTR预估中很常见主要是因为训练时一般采用pairwise同时也主要会使用AUC、NDCG这类排序类型的评价指标比如ABC模型预测ABC的分数为[0.1, 0.2, 0.3]或[0.7, 0.8, 0.9]在评价指标上是一样的但这样不利于选取合适的阈值来过滤无关文本所以需要加上校准这一步骤。
多轮问答下的检索Query
假设用户前后的两个问题是”颐和园在哪里“、”门票多少钱“。但如果单看第二个问题无法知道用户想问的是哪里的门票。所以如果只用最新的query来检索会造成上下文依赖丢失的问题。
针对这个问题可以尝试以下解法 增加一个模型比如Bert用户判断当前的query和历史的query是否有上下文依赖关系维护一个依赖关系链如果有则将依赖链上的query拼接起来用于文本检索否则只需将最新的query用于检索即可。 让LLM根据近几轮的问答生成检索query发挥LLM的通用性。
LLM回答
Prompt
用什么样的Prompt才能让LLM输出满意的结果呢首先来看一个常用来做检索增强的Prompt
Use the following context as your learned knowledge, inside context/context XML tags.
context
{{context}}
/context
When answer to user:
- If you dont know, just say that you dont know.
- If you dont know when you are not sure, ask for clarification.
Avoid mentioning that you obtained the information from the context.
And answer according to the language of the users question.Here is the chat histories between human and assistant, inside histories/histories XML tags.
histories
{{histories}}
/historieshuman:{{question}}
ai:以上这个Prompt将相关文档、历史对话、用户问题都放进去了看着是个很强的baseline。但如果你用的LLM不是强如ChatGPT而只是6B、13B规模的开源模型你会发现这个Prompt的效果不够稳定经常出现Badcase。
我认为它最致命的缺点是没有采用对话的形式。之前在介绍ChatGPT的三步走方案时提到了在第二、三步时训练数据的格式是对话的形式所以如果将Prompt能够保持对话的形式效果应该能更好下面是一个示例。关于Chatgpt是如何组织对话的可以参考以往的这篇文章。
[{role:system,content:
Use the following context as your learned knowledge, inside context/context XML tags.
context
{{context}}
/context
When answer to user:
- If you dont know, just say that you dont know.
- If you dont know when you are not sure, ask for clarification.
Avoid mentioning that you obtained the information from the context.
And answer according to the language of the users question.},{role:user,content:histories_user_1},{role:assistant,content:histories_assistant_1},...{role:user,content:question},
]礼貌拒答
即使有了检索增强也不见得LLM能答上所有问题相反我们更希望LLM在没有把握的时候选择有礼貌地拒答所谓有礼貌在很多场景中是和”人设“相关的比如落地的场景是企业助手、电商客服等。想要实现人设和拒答的效果主要的工作是在调优Prompt上。Prompt工程这活儿感觉只能起到锦上添花的作用效果想要更上一层楼还是得使用更强的LLM。
写在最后
创新到普及之间技术到产品之间可用到好用之间存在着一道隐秘的GAP。篇幅有限以上的一些经验无法覆盖到方方面面欢迎大家一起来讨论
Reference
[1] Langchain-Loaders
[2] Langchain-Doc Transformers
[3] Langchain-Question Answering
