近日，关于RAG（检索增强生成）的讨论热度持续攀升。此前有文章指出，不少RAG项目的实际体验并不理想，检索质量常常难以令人满意。更值得关注的是，早在今年3月，就连Perplexity AI的CEO也曾公开表达过对RAG向量相似性检索质量的担忧。本文正是针对这一痛点提供一些优化思路，并以Shortwa ve——一家AI邮件助手公司的设计案例作为核心参照。难得有公司愿意将其产品的详细技术机制公之于众。此外，在01部分还会回答两个常见困惑：“微调和RAG到底选哪个？”以及“有了支持超长上下文窗口的LLM，是否还需要RAG？”
01
目前，支持超长上下文窗口的LLM（如拥有10M tokens的Gemini 1.5）已经问世，很多人认为RAG已无必要——直接将几百个文档丢给LLM不就可以了吗？然而，有三个关键问题需要先厘清：
- 相关性：即便上传大量文档，仍需判断哪些文档与用户问题最相关，否则答案容易偏离主题。
- 性能影响：海量文档对模型读取和处理的性能影响有多大？模型能否高效地针对具体问题生成精准回答？
- 算力成本：随着文档数量增加，算力成本也会显著攀升，这也是为何许多LLM至今仍无法支持过大的上下文窗口。例如，GPT-4在处理30k汉字内容时，偶尔就会出现宕机情况。
一个有趣的类比是：尽管我们的RAM内存足够大，但许多操作仍需在硬盘上进行读写传输，而不是全部存储在RAM中。
那么，RAG和微调到底该如何选择？根据arXiv上两篇论文（2401.08406和2312.05934）的研究，RAG在生成质量上往往优于传统语言模型微调，尤其是在需要外部知识回答的场景下。RAG不仅以更低的算力成本实现了高效性能，还具备灵活应对信息检索准确性问题的能力——当检索到的信息不准确时，只需调整或替换索引，无需重新训练整个模型。此外，RAG的模块化设计允许不同组织使用专属知识库，避免了将所有数据混合进一个黑箱模型，透明度和可定制性更高。
02
目前，RAG系统在知识库具备高相关性、高密度以及丰富细节信息时表现最佳。为确保RAG的高效性，需要对初始检索器、重新排序机制或类似EffectiveGPT的评估器进行严格的质量评估，以下三个标准尤为关键：
- 相关性（Relevance）——最核心的标准。使用Mean Reciprocal Rank（MRR）来衡量系统的相关度排名，确保与问题最相关的内容排在最前面。
- 知识密度（Density）：在相关性相同的情况下，优先参考知识密度高的文档，例如由专家撰写的、内容更精炼的材料。
- 细节（Details）：尤其在涉及工具调用时，对知识库或工具进行详细描述，能帮助LLM更好地理解每个知识库的用途，比如处理SQL数据库这类需要精确调用的场景。
需要警惕的是：当前基于向量的语义相似性搜索，在准确性上可能还不如传统的关键词搜索（如BM25）。因此，类似Sourcegraph的CTO建议将语义搜索与关键词搜索结合，以提升RAG检索的整体质量。
现实可行的提升方案，可以参考AI邮件助手Shortwa ve的AI Search机制：
- 问题重写（Query Reformation）：对用户原始查询进行优化，消除歧义、补充上下文，使其更清晰、更适合检索系统。
- 关键信息提取（Feature Extraction）：从问题中提取时间、地点、姓名等关键特征，帮助定义检索范围并提高匹配准确性。
- Recency Bias Extractor：一种识别和提升与当前时间点最相关信息的工具。根据查询中的时间特征，对更近期的内容给予更高优先级，适用于强调“近因效应”的场景。
- 关键词与嵌入结合的初步检索（Keyword + Embedding Initial Retrieval）：先用关键词搜索精准匹配，确保高相关性；再辅以向量搜索处理同义词、多模态信息以及语法错误的查询。这样即使关键词不完全匹配，也能捕捉更广泛的语义关系。
- 启发式重新排序（Heuristic Re-ranking）：利用从问题中提取的特征（如时间、姓名）在重新排序时给予最高权重（boost），对次相关的内容给予惩罚，从而突出最相关的答案。
关键词匹配度越高的素材获得最高的boost，效果如下曲线所示：
- 利用MS Marco MiniLM进行Cross-Encoder Re-ranking：MiniLM模型在本地运行，根据改写后的查询和上一步排名靠前的文档，进行更精细的匹配评分。由于计算量较大，只对排名靠前的文档进行此操作。
- 输出最终排序结果：Cross-Encoder的评分反馈到启发式排序中，对高分内容boost、低分内容penalize，最终生成精确的相关性排序结果，提供给LLM。
简要总结上述机制：高相关性、高密度、丰富细节的知识库是基础；对用户问题进行优化改写；提取问题关键特征；用关键词搜索先精准匹配；再配合一个或多个重新排序机制，才能实现高质量检索。
03
从Shortwa ve的例子可以看出，一个成熟的AI产品大致是基于LLM，根据用户场景需求开发设计特定的AI工具，这些工具需要基于各种开源模型、Prompt和自定义机制进行封装。比如下面的摘要功能只是用Prompt封装，而AI Search则涉及复杂的场景细化流程。
当需要调用这些工具时，首先需进行工具与用户问题的匹配。
