介绍了大型语言模型的新进展及 LLM 的局限性

RAG系统就是为了搞定这两个问题而生的——它是一种信息检索方法，专门用来突破直接使用LLM的瓶颈。

它的工作原理是这样：先把自然语言查询转成Embedding（向量化表示），然后用这个Embedding在一堆文档里做语义搜索，最后把搜到的文档丢给LLM生成答案。

搭建RAG系统需要搞定Index和Query两大块。Index在开发阶段做，Query在运行阶段跑。

Index

RAG系统里，检索靠的是Embedding——它给文档提供一个压缩过的语义表示，说白了就是一堆数字向量。索引的时候，每个文档会被拆成小块（chunk），然后用Embedding模型把这些小块变成向量，再把原始块和向量一并存进数据库。这里有个设计关键：怎么切文档？切多大？如果切得太碎，有些问题可能压根答不上来；如果切得太大，答案里又容易混进噪音。

不同类型的文档需要的拆分策略也不一样。比如视频内容，得先转录成文本再编码。选哪种Embedding也很讲究，因为一旦换了Embedding策略，所有chunk都得重新索引。选的时候主要看语义检索能不能正确命中答案——这取决于chunk大小、预期问题的类型、内容结构以及应用领域。

OpenAI的Embedding模型

Query

查询在运行时进行。首先把自然语言问题转成通用查询——这一步靠LLM完成，可以把历史聊天记录等额外上下文加进去。然后从新查询里算出一个Embedding，用它在向量数据库里找相关文档。相似度方法（比如余弦相似度）会检索出Top K个最相似的文档（向量数据库有倒排索引这类加速技术）。这里的K值很关键：K太小可能召回率太低，漏掉正确答案；K太大会让输入LLM的Prompt太长，计算成本飙升，甚至可能超出LLM支持的长度。

检索到的文档还会重新排序，尽量把包含答案的chunk排到前面。接着进入合并器阶段，处理这些chunk。这一步主要是为了克服LLM的两大限制：

OpenAI的一级速率限制

LLM底座的选择还有一个特别需要关注的点：推理成本。通常GPT-4作为底座效果最好，但代价很高，所以得结合实际场景折中。比如现在有些开源LLM效果也还不错、但小得多。不合适的模型还可能导致LLM不按Prompt要求生成答案，所以通常需要做评估实验来决策。

中文开放式生成评估

LLM API价格

RAG系统的最后一步是从生成的文本里提取答案。上层应用需要过滤掉提示中的噪音，遵循格式要求（比如把答案输出成选项列表），然后生成查询结果。实现RAG系统需要定制多个提示来处理提问和答案，确保返回的是领域相关的内容。用LLM从文档里实时回答问题，这为问答系统开辟了新天地。

RAG的优势

RAG有三个明显的好处，这也是它能在当前AI应用中被广泛采用的原因：

• 减少LLM幻觉
  。LLM产生的幻觉往往看起来高度连贯、合理且可信，但实际是错的。RAG通过在推理时把带有高度上下文参考数据的提示注入进去，利用LLM强大的上下文学习能力来弥补这一缺陷。

• 源数据和参考数据与交互、对话挂钩
  。引入组织、企业或行业特定数据（包括定义、术语等），RAG是一种简单直接的方式。

• 对参考数据进行分块和索引的过程基本自动化
  ，不需要人工标注数据。

RAG的挑战

RAG系统在实际落地中，有几个潜在的故障点（Failure Points）：

• FP1：缺失内容
  。当提出的问题在现有文档里找不到答案时，可能出现失败。理想情况下，RAG系统会回复“抱歉，我不知道”。但如果问题与内容沾边但缺乏具体答案，系统可能被误导而给出响应。

• FP2：错过了最相关的文档
  。文档里明明有答案，但排名不够高，没被呈现给用户。理论上所有文档都会排序并考虑，但实践中只返回Top K个文档，K是根据性能指标选的。

• FP3：不在上下文中
  。包含答案的文档已经成功检索出来，但没有被放到用于生成响应的上下文里。多个文档检索回来后，合并提取答案时容易出这个问题。

• FP4：未提取
  。答案就在提供的上下文里，但LLM就是没准确捞出来。当上下文噪音过多或信息冲突时，经常发生。

• FP5：格式错误
  。问题要求以特定格式（比如表格或列表）提取信息，但LLM忽略了指令。

• FP6：特定性错误
  。响应里有答案，但缺乏所需的具体性或过于具体，满足不了用户需求。

• FP7：不完整
  。不完整的答案不一定错，但少了些信息，即使这些信息在上下文里且能被提取出来。

经验教训和未来优化方向

Chunking and Embedding

Chunking听起来简单，但质量直接影响检索过程——尤其影响chunk的Embedding，进而影响与用户查询的相似度和匹配。目前有两种chunking方式：

• 基于启发式的方法
  （用标点符号、段落结尾等）。

• 语义分块
  （根据文本中的语义确定块的起止）。

后续研究应该深入探讨这些方法之间的权衡，以及它们对Embedding和相似性匹配等下游过程的影响。如果能有一套系统评估框架，在查询相关性和检索准确性等指标上对比不同的Chunking技术，会对这个领域大有帮助。

Embedding是另一个活跃的研究方向，包括为多媒体和多模态块（比如表格、图形、公式）生成Embedding。chunk的Embedding通常在系统开发期间或索引新文档时创建一次。查询预处理对RAG系统性能影响很大，尤其是处理否定或模糊查询时。要解决Embedding本身的局限性（匹配质量是领域相关的），还需要更多架构模式和方法的研究。

RAG vs 微调

LLM因为训练数据量大，加上发布前有微调任务，成了很好的通用模型。但这些通用模型不一定了解你领域的细节，而且知识有截止日期，不够新。微调和RAG提供了两种定制路线，各自的权衡不同。微调需要策划内部数据集来适应和训练LLM，但所有数据都会嵌入到模型中，得解决安全/隐私问题（谁可以访问什么）。另外，基础模型本身演变或你要添加新数据时，得重新微调。而RAG系统更像一个务实的方案：按需对数据分块，只拿相关的块在上下文中给LLM生成答案。这能通过新文档持续更新知识，还能控制用户能访问哪些块。不过，chunk的Embedding、检索和上下文融合的优化策略仍是活跃的研究课题。下一步工作应该系统比较微调和RAG在准确性、延迟、运营成本、鲁棒性等因素上的表现。

RAG系统的测试和监控

RAG系统的工程最佳实践还在不断摸索中。测试和测试用例生成是急需改进的领域之一。RAG系统需要和应用相关的问题和答案，但这些通常在索引非结构化文档时是没有的。最近有研究开始用LLM从多个文档生成问题。如何生成真实、与领域相关的问题和答案，仍然是个开放问题。

结论

本文介绍了构建RAG系统时遇到的挑战和对应的解决方案，特别是通过集成LLM来实现智能客服。RAG系统把检索机制和LLM的生成能力结合起来，能高效处理非结构化信息，减少开发时间和数据清洗需求。当然，实现过程中存在一些故障点，比如缺失内容、格式错误、答案不完整等。

文章还探讨了RAG系统的核心流程、优势以及面临的挑战。RAG的好处很明显：减少LLM幻觉、关联源数据和参考数据、自动化处理非结构化数据。但实际应用里，还得解决好Chunking和Embedding策略、RAG与微调的选择、以及系统的测试和监控等问题。希望这些经验和建议能为从事RAG系统开发的工程师提供有价值的参考。