本文详细介绍了如何搭建一个基于LangChain的RAG系统，用于处理企业内部文档问答。文章重点讲解了系统架构设计，包括问题改写、混合召回（Dense Retrieval + BM25 + Cross-Encoder reranking）、严格回答与结构化输出、缓存优化以及RAGAS评估方法。同时，作者分享了实际开发中踩过的坑及解决方案，并强调了检索前改写、混合召回、精排、评估和观测对于提升RAG系统稳定性的重要性。代码库已开源，适合想要学习大模型应用的开发者参考。
1、系统架构
先看整体架构图：
这个架构里最核心的设计点是：
- 把“检索前问题改写”和“最终回答”拆成两个阶段
- 把“召回”和“精排”拆开
- 把“在线问答”和“离线评估”拆开
这样好处是每一层都能单独调优，而不是把问题全甩给 LLM。
2、为什么要先改写问题再检索
很多 RAG 教程的第一版都忽略了一个现实问题：用户的第二句、第三句往往不是完整问题。
比如：
Q1: 退款金额高于 200 元怎么办？ Q2: 那它需要谁二次确认？第二句里的“它”对人是清楚的，但对向量检索并不友好。
所以我在检索前专门加了一步“问题改写”，把追问补全成独立 Query。
关键代码在 app/rag_chain.py：
standalone_question = self._rewrite_question(llm, chat_history, question) source_documents = self.vector_index.search( session_id=session.session_id, query=standalone_question, top_k=self.settings.top_k, )这一步不是为了让回答更好看，而是为了让“查资料”这一步查得更准。
3、为什么我最后做成了混合召回
一开始如果只用向量召回，系统在“语义相近”的问题上表现不错，但只要问题里出现：
- 专有名词
- 金额阈值
- 规则号
- 明确关键词
效果就不稳定了。
比如“退款金额高于 200 元”这种问题，BM25 的关键词特征其实很强。
所以我后来把召回层改成了两路：
- Dense Retrieval：处理语义近似
- BM25 Retrieval：处理关键词和精确条件
关键代码在 app/vector_store.py：
dense_results = self._dense_search(session_id, query, candidate_k) keyword_results = self._keyword_search(session_id, query, candidate_k) merged_results = self._merge_results(dense_results, keyword_results, candidate_k) return self._rerank_results(query, merged_results, top_k)这一步非常值，因为业务文档问答往往既需要语义理解，也需要精确匹配。
4、为什么还要再加 Cross-Encoder reranking
混合召回之后，我发现候选片段“能召回”，不代表“顺序就对”。
尤其在这些场景里，候选 Top-K 往往会混进一些看起来相关、但其实不是答案核心证据的段落：
- 同主题但不同角色权限
- 同样提到退款，但处理条件不同
- 同一个文档里相邻段落都含关键词
所以我又在召回之后加了一层 Cross-Encoder reranking：
return self.reranker.rerank(query, candidates, top_k)它和普通 embedding 检索最大的区别是：
- embedding 是“各自编码后再比较”
- cross-encoder 是“把 query 和 chunk 一起送进模型，直接判断相关性”
它更贵，但更准，所以特别适合放在第二阶段精排。
5、严格回答和结构化输出
业务问答系统最怕的不是“答不上来”，而是“答错了还很自信”。
所以 Prompt 我做了两个硬约束：
- 必须严格基于上下文回答
- 不知道就明确说“我不知道”
同时我没有让模型自由输出，而是用了 Pydantic 结构化输出：
class StructuredAnswer(BaseModel): answer: str grounded: bool citations: List[Citation] = Field(default_factory=list)这有两个好处：
- 前端展示稳定，不用猜模型输出格式
- 引用关系可以被程序校验，减少“胡乱引用”
6、缓存优化：我为什么接了 InMemoryCache
在调 Prompt、反复跑相同问题、反复回归 Benchmark 的时候，最浪费时间的其实是重复调用模型。
所以我加了一层 LangChain InMemoryCache：
from langchain_core.caches import InMemoryCache from langchain_core.globals import set_llm_cache set_llm_cache(InMemoryCache())不过这里有一个非常容易误解的点：InMemoryCache 不是 embedding-based 的 semantic cache，它是“完全相同 Prompt 命中”的 LLM Cache。
我后来又加了一层简单观测，记录 hits / misses / writes / entries，方便直接在 Web 页面上看缓存状态。
7、RAGAS 评估怎么接
RAG 只靠肉眼看几轮问答，基本是调不稳的。
所以我最后给项目加了一组内置 Benchmark，用 RAGAS 跑这 5 个指标：
- faithfulness
- answer_relevancy
- context_recall
- context_precision
- answer_correctness
核心思路是：
- 先准备一组带参考答案的业务问题
- 用当前 RAG 系统实际跑出答案和检索上下文
- 再把 question / answer / contexts / ground_truth 喂给 RAGAS
关键代码在 app/evaluation.py：
result = evaluate( Dataset.from_list(dataset_rows), metrics=[ faithfulness, answer_relevancy, context_recall, context_precision, answer_correctness, ], llm=LangchainLLMWrapper(self.rag_service._build_llm()), embeddings=LangchainEmbeddingsWrapper(EmbeddingAdapter(self.embedding_service)), raise_exceptions=False, )页面里我把 RAGAS 总分和逐题分数都展示了出来，这样一调参数，马上就能看是“召回退化了”还是“生成跑偏了”。
8、我踩过的几个坑
坑 1：RAGAS 装上了，但 Python 3.8 导入直接炸
我一开始装的是 ragas 0.2.x，结果虽然能安装成功，但导入时直接 SyntaxError。
原因不是代码写错，而是新版本内部用了 3.9+ 的语法，而我的本地环境还是 Python 3.8。
解决方式：
- 不硬升整个项目 Python 版本
- 把 ragas 锁到 0.1.21
- 在 README 里明确写出版本原因
这比“为了一个评估库把整套环境推倒重来”稳得多。
坑 2：把 InMemoryCache 当成语义缓存
很多人一看到“cache”就会默认以为是“相似问题也能命中”。
其实 LangChain 的 InMemoryCache 不是这个意思，它只缓存完全相同的请求。
解决方式：
- 代码里照需求接入 InMemoryCache
- 页面和 README 里明确写“这是精确命中缓存，不是 semantic embedding cache”
技术上正确，比营销式命名更重要。
坑 3：评估时污染了聊天历史
如果直接拿当前会话去跑 Benchmark，ConversationBufferMemory 会越来越脏，后面的评估样本会受到前面问题影响。
解决方式：
- 评估时复用当前 session 的文档
- 但为每个测试问题创建隔离的 memory
这样评估仍然用的是同一套知识库和检索配置，但不会互相串台。
坑 4：只做 Dense Retrieval，金额阈值类问题经常漂
在业务规则文档里，“高于 200 元”“连续三次失败”“24 小时内”这类信息非常重要。
只做语义检索，往往会把主题相关但条件不完全匹配的片段排到前面。
解决方式：
- 加 BM25 做关键词召回
- 再加 Cross-Encoder 做精排
这是我这套系统里提升最明显的一次改造。
9、如果让我再做一次，我会优先继续补什么
如果你已经把第一版 RAG 跑通了，我建议优先补下面三项：
- 混合召回
- Reranking
- Benchmark + 回归评估
因为真正让 RAG 变“工程化”的，不是多写几个 Prompt，而是：
- 能不能稳定命中对的证据
- 能不能持续评估而不是凭感觉调参
10、最后
这套项目我已经把 Web 界面、缓存观测、RAGAS Benchmark、引用溯源都接起来了。
如果你也在做中文业务知识库 RAG，我的建议是：不要把问题都归结为“模型不够强”，很多时候真正缺的是：
- 检索前改写
- 混合召回
- 精排
- 评估
- 观测
把这几层补齐，RAG 的稳定性会比单纯换模型明显得多。
代码库见 Github：
https://github.com/wilsonIs/langchain-business-rag如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
大模型入门到实战全套学习大礼包
1、大模型系统化学习路线
作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！
2、大模型学习书籍&文档
学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。
3、AI大模型最新行业报告
2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。
4、大模型项目实战&配套源码
学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。
5、大模型大厂面试真题
面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。
适用人群
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
