在上一章，我们讲解了如何针对生成部分评估优化 Prompt Engineering，来提高大模型的生成质量。但生成的前提是检索，只有当我们应用的检索部分能够根据用户 query 检索到正确的答案文档时，大模型的生成结果才可能是正确的。因此，检索部分的检索精确率和召回率其实更大程度影响了应用的整体性能。但是，检索部分的优化是一个更工程也更深入的命题，我们往往需要使用到很多高级的、源于搜索的进阶技巧并探索更多实用工具，甚至手写一些工具来进行优化。因此，在本章中，我们仅大致讨论检索部分评估与优化的思路，而不深入展开代码实践。如果读者在阅读完本部分后感到意犹未尽，想要学习更多的进阶技巧来进一步优化自己的应用，欢迎阅读我们即将推出的教程第二部分《LLM 开发技巧》。
首先让我们来回顾整个 RAG 系统的功能。
针对用户输入的一个 query，系统会将其转化为向量并在向量数据库中匹配最相关的文本段，然后根据我们的设定选择 3～5 个文本段落和用户的 query 一起交给大模型，再由大模型根据检索到的文本段落回答用户 query 中提出的问题。在这一整个系统中，我们将向量数据库检索相关文本段落的部分称为检索部分，将大模型根据检索到的文本段落进行答案生成的部分称为生成部分。
因此，检索部分的核心功能是找到存在于知识库中、能够正确回答用户 query 中的提问的文本段落。因此，我们可以定义一个最直观的准确率在评估检索效果：对于 N 个给定 query，我们保证每一个 query 对应的正确答案都存在于知识库中。假设对于每一个 query，系统找到了 K 个文本片段，如果正确答案在 K 个文本片段之一，那么我们认为检索成功；如果正确答案不在 K 个文本片段之一，我们任务检索失败。那么，系统的检索准确率可以被简单地计算为：
其中，M 是成功检索的 query 数。
通过上述准确率，我们可以衡量系统的检索能力，对于系统能成功检索到的 query，我们才能进一步优化 Prompt 来提高系统性能。对于系统检索失败的 query，我们就必须改进检索系统来优化检索效果。但是注意，当我们在计算如上定义的准确率时，一定要保证我们的每一个验证 query 的正确答案都确实存在于知识库中；如果正确答案本就不存在，那我们应该将 Bad Case 归因到知识库构建部分，说明知识库构建的广度和处理精度还有待提升。
当然，这只是最简单的一种评估方式，事实上，这种评估方式存在很多不足。例如：
- 有的 query 可能需要联合多个知识片段才能做出回答，对于这种 query，我们如何评估？
- 检索到的知识片段彼此之间的顺序其实会对大模型的生成带来影响，我们是否应该将检索片段的排序纳入考虑？
- 除去检索到正确的知识片段之外，我们的系统还应尽量避免检索到错误的、误导性知识片段，否则大模型的生成结果很可能被错误片段误导。我们是否应当将检索到的错误片段纳入指标计算？
上述问题都不存在标准答案，需要针对项目实际针对的业务、评估的成本来综合考虑。
除去通过上述方法来评估检索效果外，我们还可以将检索部分建模为一个经典的搜索任务。让我们来看看经典的搜索场景。搜索场景的任务是，针对用户给定的检索 query，从给定范围的内容（一般是网页）中找到相关的内容并进行排序，尽量使排序靠前的内容能够满足用户需求。
其实我们的检索部分的任务和搜索场景非常类似，同样是针对用户 query，只不过我们相对更强调召回而非排序，以及我们检索的内容不是网页而是知识片段。因此，我们可以类似地将我们的检索任务建模为一个搜索任务，那么，我们就可以引入搜索算法中经典的评估思路（如准确率、召回率等）和优化思路（例如构建索引、重排等）来更充分地评估优化我们的检索效果。这部分就不再赘述，欢迎有兴趣的读者进行深入研究和分享。
上文陈述来评估检索效果的几种一般思路，当我们对系统的检索效果做出合理评估，找到对应的 Bad Case 之后，我们就可以将 Bad Case 拆解到多个维度来针对性优化检索部分。注意，虽然在上文评估部分，我们强调了评估检索效果的验证 query 一定要保证其正确答案存在于知识库之中，但是在此处，我们默认知识库构建也作为检索部分的一部分，因此，我们也需要在这一部分解决由于知识库构建有误带来的 Bad Case。在此，我们分享一些常见的 Bad Case 归因和可行的优化思路。
该问题一般表现为，对于一个用户 query，我们可以确定其问题一定是存在于知识库之中的，但是我们发现检索到的知识片段将正确答案分割开了，导致不能形成一个完整、合理的答案。该种问题在需要较长回答的 query 上较为常见。
该类问题的一般优化思路是，优化文本切割方式。我们在《C3 搭建知识库》中使用到的是最原始的分割方式，即根据特定字符和 chunk 大小进行分割，但该类分割方式往往不能照顾到文本语义，容易造成同一主题的强相关上下文被切分到两个 chunk 总。对于一些格式统一、组织清晰的知识文档，我们可以针对性构建更合适的分割规则；对于格式混乱、无法形成统一的分割规则的文档，我们可以考虑纳入一定的人力进行分割。我们也可以考虑训练一个专用于文本分割的模型，来实现根据语义和主题的 chunk 切分。
该问题也是存在于知识库构建的一个问题。即部分 query 提出的问题需要检索部分跨越很长的上下文来做出概括性回答，也就是需要跨越多个 chunk 来综合回答问题。但是由于模型上下文限制，我们往往很难给出足够的 chunk 数。
该类问题的一般优化思路是，优化知识库构建方式。针对可能需要此类回答的文档，我们可以增加一个步骤，通过使用 LLM 来对长文档进行概括总结，或者预设提问让 LLM 做出回答，从而将此类问题的可能答案预先填入知识库作为单独的 chunk，来一定程度解决该问题。
该问题一般表现为，对于一个用户 query，系统检索到的知识片段有很多与 query 强相关的关键词，但知识片段本身并非针对 query 做出的回答。这种情况一般源于 query 中有多个关键词，其中次要关键词的匹配效果影响了主要关键词。
该类问题的一般优化思路是，对用户 query 进行改写，这也是目前很多大模型应用的常用思路。即对于用户输入 query，我们首先通过 LLM 来将用户 query 改写成一种合理的形式，去除次要关键词以及可能出现的错字、漏字的影响。具体改写成什么形式根据具体业务而定，可以要求 LLM 对 query 进行提炼形成 Json 对象，也可以要求 LLM 对 query 进行扩写等。
该问题是较为常见的，即匹配到的强相关文本段并没有包含答案文本。该问题的核心问题在于，我们使用的向量模型和我们一开始的假设不符。在讲解 RAG 的框架时，我们有提到，RAG 起效果是有一个核心假设的，即我们假设我们匹配到的强相关文本段就是问题对应的答案文本段。但是很多向量模型其实构建的是“配对”的语义相似度而非“因果”的语义相似度，例如对于 query-“今天天气怎么样”，会认为“我想知道今天天气”的相关性比“天气不错”更高。
该类问题的一般优化思路是，优化向量模型或是构建倒排索引。我们可以选择效果更好的向量模型，或是收集部分数据，在自己的业务上微调一个更符合自己业务的向量模型。我们也可以考虑构建倒排索引，即针对知识库的每一个知识片段，构建一个能够表征该片段内容但和 query 的相对相关性更准确的索引，在检索时匹配索引和 query 的相关性而不是全文，从而提高匹配关系的准确性。
优化检索部分的思路还有很多，事实上，检索部分的优化往往是 RAG 应用开发的核心工程部分。限于篇幅原因，此处就不再赘述更多的技巧及方法，欢迎有兴趣的读者阅读我们即将推出的第二部分《LLM 开发技巧》。