作者： Thuwarakesh Murallie
写给每一个正在尝试构建RAG应用的你
📦 本文是我「RAG工程实战反思系列」的第1篇，如果你也在构建基于LLM的RAG系统，建议收藏本文。文末有资料领取方式，可快速搭建实战系统框架。
📷 照片由KE ATLAS提供，来自Unsplash
我大部分时间都在构建和改进检索增强生成（RAG）应用程序。
我相信RAG可能是AI应用中最流行的应用。它无处不在，从聊天机器人到文档摘要。
我还相信，许多这样的应用程序最终未能部署，原因多种多样，其中许多不是技术性的。然而，我希望我早些知道一些技术方面的知识，这样可以创建更有效的RAG。
但这就是我们学习新事物的方式。没有比通过构建一些东西并失败更好的学习工程方法了。
通过我的失败，我学到了一些有价值的经验，可以帮助那些第一次构建RAG的人。你不需要犯我犯过的错误，这样你可以走得更快。
📩 这是我从一线项目复盘中总结出的经验。
如果你正在开发企业级RAG系统，私信【RAG指南】可获取我的项目笔记与落地方法文档合集（PDF格式）。
那么，让我们来谈谈第一个错误。
向量数据库不是硬性规定
几乎所有关于RAG的教程都使用了向量存储。如果你在搜索RAG内容，你就会明白我在说什么。
基于向量的检索无疑是RAG的一个重要成功因素。向量嵌入非常适合映射文本的语义含义。它们也能很好地处理不同大小的文本。你的查询可能是一个句子，而你的文档存储却包含整篇文章？——向量搜索可以处理它们。
然而，检索并不仅限于基于向量的检索。
RAG可以从互联网上检索信息、从关系数据集、从Neo4J中的知识图谱，或者从这三者的组合中进行检索。
在许多情况下，我发现混合方法往往提供更好的性能。
👉 我曾在企业项目中混合用 Neo4J + Postgres + 向量存储，效果远超单一方案。
有兴趣的朋友可以留言，我会整理出一份「混合RAG结构实战图」发布在下一篇里。
对于一般用途的应用，你可以有一个向量存储，但当向量存储中没有信息时，你可以搜索互联网。
对于客户聊天机器人，你可能需要授权RAG访问你的一部分客户数据库，这可以是一个关系型数据库。
一家公司的知识管理系统可能创建一个知识图谱，并从中检索信息，而不是使用向量存储。
这些都可以算作RAG。
然而，决定使用哪些数据源的过程并不简单。你需要通过不同的选项进行实验，以了解每种方法的优点。接受或拒绝某个想法的原因可以受到技术和商业考虑的影响。
例如，你可以为每个客户的资料信息创建一个文本版本，并将其向量化以进行检索。这样做在查询时效率较高，因为你只处理一个数据库。但它可能没有运行SQL查询那样准确。这是一个需要考虑的技术原因。
然而，允许LLM运行SQL查询可能导致SQL注入攻击。这是一个技术和商业上的关注点。
向量数据库对于语义检索也非常高效。然而，这并不意味着其他数据库不能处理语义检索；几乎所有其他数据库也能处理向量搜索。
优先使用微调的小模型
嵌入模型可以将任何东西转换为向量形式。你会看到较大模型的性能比较小模型更好。
然而，这并不意味着较大总是更好。
忘掉大小吧。所有模型都基于公开可用的数据集进行训练。它们能区分“apple”是水果，还是品牌。然而，如果你和你的朋友把“apple”作为密码，这个嵌入模型就无法知道了。
然而，我们创建的几乎所有应用程序都是专注于一个小众话题。
对于这些应用来说，较大模型带来的好处微乎其微。
这是另一种做法。
为你的领域数据创建一个数据集，并微调一个小型嵌入模型。
小模型足以捕捉语言的细微差别，但可能无法理解在不同上下文中具有特殊含义的词汇。
但是，如果你仔细思考，为什么你的模型需要理解木卫二是什么？
小模型更高效。它们运行快速且成本低。
为了赋予模型缺失的领域知识能力，你可以对其进行微调。
📌 我用 MiniLM + 自定义微调数据集，在一次法律问答项目中做到 80%以上相关度。
有需要自定义 embedding 微调流程的，可以后台私信【embedding流程图】获取步骤图。
检索过程可以更先进
最直接的检索过程是直接查询。
如果你使用向量数据库，你可以对用户的输入进行语义搜索。否则，你可以使用LLM生成SQL或Cipher查询。
你也可以在需要时调用HTTP端点。
但是，直接查询方法很少产生可靠的上下文。
你可以用更高级的方式查询数据源。例如，你可以尝试查询路由技术，来决定从哪个数据源获取数据。一个具有良好推理能力的LLM可以用于此目的。你还可以在一个较小的模型上进行指令调优，以节省成本并减少延迟。
另一种技术是链式请求。对于初始查询，我们可以从数据源获取信息。然后，基于获取的文档，我们可以获取后续文档。
分块是RAG中最具挑战性也是最重要的部分
当上下文包含不相关的信息时，LLM容易出错。
防止RAG中出现幻觉的最好方法就是分块。
现代LLM可能支持更长的上下文长度。例如，Gemini 2.5 Pro支持最多200万个token，这足以容纳两到三本大学级物理教科书。
但是，对于基础力学的问题，你几乎不需要量子物理的上下文信息。
如果你将这些教科书分解成更小的部分，可能每一部分只讨论一个话题，你就可以仅获取相关信息来回答问题。
编辑
递归字符分割是如何工作的——作者插图
这里的挑战在于，有许多分块技术。每种都有其优缺点。适合你领域的技术不一定适用于其他领域。
🧩 我做过8种主流分块方法的对比，欢迎评论区回复【分块对比】，我发你一张清单。
尝试重新排序
最后但同样重要的是重新排序。
已经证明，相关分块的位置是高质量LLM响应的关键因素。
然而，常规的向量搜索，甚至是数据库查询，并不会非常智能地对结果进行排序。LLM可以做到这一点。
因此，我们利用一个专门的大型语言模型（LLM）作为重新排序器，来重新排列获取的上下文，并进一步过滤出最相关的分块。
这种二级重新排序在某些应用中是有益的，但在其他应用中则不是。但你可以使用一些技术来改善重新排序的结果。
其中之一是获取大量初始结果。松散地定义初始标准会拉取一些不相关的上下文，但它增加了得到正确结果的概率。
最后的思考
构建RAG已经成为任何LLM的必备技能。即使是2M token的上下文窗口也无法挑战它。
我们开发的原型通常不会部署。这其中有一部分原因是商业决策，但也有一些技术原因是可以解决的。
这篇文章是从我构建RAG的经验中挑选出的几个小技巧。
虽然这不是一个全面的列表，但考虑到这五个方面，将确保你开发出一个能长久可靠运行的应用。
如果你之前构建过RAG，你会向这个列表中添加什么呢？
📩 如果你也正在构建RAG系统，私信【RAG手册】即可领取我自己总结的《从0到1构建RAG应用》的流程图与案例代码清单。
🚀 本文是我【AI产品全链路实战系列】之一，欢迎关注我，持续更新，从底层向量到模型部署讲到通透。
💬 评论区互动建议
- 你在构建RAG时踩过哪些坑？留言一起交流想看哪种分块策略的实测效果？我可以出个小实验有人在生产系统中实测过“二级排序+reranker”的效果吗？我们做过一次，提升很明显
