聊聊检索增强，LangChain一把梭能行吗？
背景
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这类排序类型的评价指标，比如A>B>C，模型预测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}}
When answer to user:
- If you don't know, just say that you don't know.
- If you don't 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 user's question.
Here is the chat histories between human and assistant, inside
{{histories}}
human:{{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}}
When answer to user:
- If you don't know, just say that you don't know.
- If you don't 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 user's 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