谈目前 知识库问答系统的最佳实践 【2023.9】
0、前言
之前也写过几篇关于知识库问答系统的文章：
LLM-native应用中复杂慢速策略的UI交互设计 【2023Q3】， 主要从复杂策略的UI交互逻辑上讨论。
《【2023.7】我可能遥望到了 第一代LLM知识库问答系统 的墓碑——再谈知识库问答系统》，主要是从商业上的讨论。
《【2023.4】思考如何设计 可靠的长文档问答系统》，该文内容已经完全过时，由本文进行替代。
本文主要讨论更高质量的知识库问答系统的策略算法的构建思路。
我知道很多团队希望找到一个像菜谱一样可以完全照搬的详尽实现方案，但这并非本文的写作目标。高质量的知识库问答系统的构建需要有算法策略视角的人，而本文只是对于这类人群的一个提醒，而不是具体的实现。没有算法策略视角的人，看了本文也做不出来对应的方案，本文并非免费的午餐。
本文的主要观点并非新内容，之前就提到过，并且New Bing Chat也是大家很熟悉的产品。本文的核心观点在于展示：我认为其他方案都不是最佳实践，只有New Bing Chat的方案才是最佳实践。
1、回顾最基本方案
目前已经有个众所周知的知识库问答方案，其思路简述如下：将文档切分为若干chunk，对于每个chunk使用embedding模型进行概要并插入到向量索引中，对于用户query也是用embedding进行计算并从向量索引中召回少量头部匹配chunk，将召回的片段作为上下文组装prompt让LLM直接进行回答。
这个方案很多团队都能够独立实现，但效果上很难让用户买账。从算法策略上来说，主要有如下问题：
【P1】输入文档的格式不一定适合切分chunk或者LLM问答。（现状40分）
【P2】embedding模型的能力较差。（开源模型现状20分，闭源模型稍好但也没超过60分）
【P3】LLM模型的问答能力（开源模型能做到60分）
【P4】结果缺乏信息来源支撑（0分）
【P1】问题中最典型的例子是PDF、PPT、Excel格式的文件。本质来说就是这些格式中的原始信息组织方式并不是类似markdown的结构化文本。想要使用LLM进行有效处理，需要重新对其中内容进行语义块的识别和结构分析。
目前大家都已经认知到PDF版式解析的重要性，而PPT的语义解析可能是一个尚未被普遍认知到的卡点。
【P2】embedding模型并不是一个合格的召回方案，只是因为它的使用门槛较低，所以目前被大量使用。
目前来看召回策略是需要正经当作一个语义搜索系统来设计和建造的。说到搜索系统的时候，很多人觉得就是上一个Elasticsearch（简称ES）就行了。但ES只是一个关键字的硬性检索系统，光靠ES并不能满足该场景语义召回的需求。甚至我觉得ES都不是该环节中的主要部分。ES主要只是提供了倒排索引和布尔查询表达式的计算逻辑而已。
【P3】LLM模型的回答能力相对还好，但仍然可能出现幻觉问题，并可能受到prompt hacking的影响。
【P4】目前我认为，对于一个认真的知识库问答系统来说，来源标识是必要的功能，它可以有效地降低用户对于幻觉的疑虑，并方便用户找到信息来源进行进一步的核实。
2、最佳实践——New Bing Chat
New Bing Chat虽然是个很早就推出的产品，但由于它的产品交互方式、实现方式等都与开源的知识库问答系统差异过大，经常会让人怀疑这不是一个类型的产品。New Bing Chat和知识库问答系统这两个领域到底有多大重叠这个问题让我思考了很久。
然后我得到了一组让很多人意外的结论：
【C1】New Bing Chat就是一个知识库问答系统（只不过是针对公开互联网爬取的数据库的）
【C2】知识库问答系统完全可以按照New Bing Chat的方式来实现
【C3】New Bing Chat是知识库产品的最佳实践，无论是从算法还是从产品交互的角度来看。知识库问答系统【就应该】按照New Bing Chat的方式来实现。
请注意，我以上三个论断非常强硬，排除了所有其他可能的情况。
2.1、产品交互逻辑分析
先从较为简单的产品交互逻辑进行分析，由于New Bing Chat的交互设计思路非常具有代表性，所以我专门写了一篇文章，将其推广到所有大延迟、复杂策略的产品上。这里请直接看该文 LLM-native应用中复杂慢速策略的UI交互设计 【2023Q3】。下面列出了New Bing Chat在单轮问答中的主要流程：
【S1】根据用户输入判断是否需要进行搜索召回，如果不需要，则直接使用LLM进行回答。
【S2】需要搜索时，使用LLM产生搜索检索query，并将其【显示给用户】
【S3】使用检索query进行搜索，并评估搜索的内容
【S4】如果第一次搜索结果没有达到预期，则再次生成搜索检索query，并将其【显示给用户】
【S5】根据搜索结果使用LLM流式生成回答
【S6】在流式生成回答过程中，对于每句（以逗号计算）话进行来源标记，也是流式的推送给用户UI。来源表现为下划线、引用上标、引用来源。
【S7】系统回复完后，会提供一些该场景下常用问题的快速输入功能给用户。
我并未在该文中讨论【S6】，那就是针对【P4】问题的来源标识。
虽然来源标识看似不是必须的功能，但它提供了如下好处：
对于能够明确来源的信息，直接标识其来源，暗示用户这句话并非幻觉。（当然来源标记策略本身也有可能犯错，但错误率并不高）
没有识别出来源的内容会明显的与有来源的内容区分开来，暗示用户更加仔细的对其内容进行鉴别。
知识库中的所有材料并非是同等可信的，但知识库问答系统很难获得足够的信息对此进行判断。但可以引导追求准确性的用户去查看原始文档，让其对文档的来源、时效性等进行判断。这是一个很不错的产品功能上的权衡。
既然系统做不好某些方面，那么就把这方面的判断还是交给用户，而不是完全不做区分，任由低质量或者幻觉的内容拉低整体回答的平均质量。
【S7】是一个容易被忽视的功能。但实际上用户输入文字是有明显的成本的，用户很少愿意输入100个汉字的内容。完全依赖用户输入内容会导致：用户减少使用，或者用户只输入少量模糊的问题。而帮助用户快速输入问题可以降低用户的使用门槛，并把用户的后续输入引导到更准确、系统更可控的方向。
2.2、实现方案分析
由于New Bing Chat并没有公开的文档描述他们的内部实现，所以本节的内容都是我根据其产品形态和个人的算法经验进行的推测。我对于这些推测还是较有把握的。
回顾前面的流程，从算法策略上来说有几个子环节：
【A1】根据用户的对话构造搜索query
【A2】根据搜索query召回文档，并定位到对应的部分。这部分New bing应该复用了Bing搜索原有的能力，起点就很高。
【A3】判断第一轮召回的内容是否足够，是否应该再补充召回，并产生相应的关键词。
【A4】根据召回的内容流式地生成回答。
【A5】在流式回答的旁路，对于已经生成的句子进行来源绑定，也流式地返回结果。
除此之外，还有：
【B1】解析爬虫获取的网页和文档
【B2】从文档中构建【各种类型】的召回用索引
【A1】这点在New Bing Chat刚推出时大家还看不明白，但现在已经很明显了，就是OpenAI的Function calling 功能的应用。
【A5】来源绑定并没有太多模型可以参考。其实现方式估计是：按逗号为边界对于每个【半句】与召回的各个来源进行匹配，每个待匹配的半句可以与0~多个来源进行匹配。这个半句与单个来源的匹配模型很可能是定制的。
【A2】【B2】召回的策略其实远没有简单的调用一个通用的embedding这么简单。搜索领域中的双塔类架构的DL模型虽然也能产出一个类似embedding的结果，但doc和query的embedding模型都是根据已有业务数据进行训练的，也是不同的，而非简单的使用开源的embedding模型或者通用embedding API。
召回的方式可以各种各样，完全看算法策略的实现者各显神通。以下列举一些常见的，供大家参考：
基于DL模型的embedding召回
基于query关键词的硬匹配召回（类似ES的能力）
将文档中的所有代词（或编号引用等）都做指代消歧后，再使用其他方式构建索引。
基于文档结构和其他信息，对于每个文本段落都进行主题标记等附加信息标识，并以此与文本端内容同时进行召回。
3、扩展其他功能
3.1、多模态内容
在这种对话的UI上，我们可以增加非文本的内容的发送，例如返回图片、其他模态等。
3.2、调用其他功能
在有了function calling功能之后，系统其实可以更容易的调用其他内部API、数据库或者其他功能和数据源。这些都可以逐步增加到整个系统中，让系统成为广义知识库的一部分。
需要说明的是，有些功能的实现并非能够完全指望LLM的function calling能力。例如说，需要查询数据库时，我们理论上可以让LLM直接构造SQL进行function calling，但可能其准确度较低，可能需要多步的请求构造，例如：先提取查询内容，然后使用专门的过程构建SQL，再去调用数据库。
3.3、权限风险
当我们在系统上接入各种API后，需要注意的是权限限制问题。用户通过该系统应该只能够访问TA能够访问的数据，拦截掉他对没有权限的数据和功能的访问。
这方面是很容易被忽视的。
交流与合作
如果希望和我交流讨论，或参与相关的讨论群，或者建立合作，请私信联系，见 联系方式。
希望留言可以到知乎对应文章下留言。
本文于2023.9.14首发于微信公众号与知乎。
知乎链接 https://zhuanlan.zhihu.com/p/656222720