企业官网建设流程全解析

1. 为什么说“LLM原生回答不了实时信息”：RAG存在的根本原因

先抛一个反直觉的结论：大语言模型本身，其实什么“知识”都没有。它只是基于海量训练文本学到的统计规律，在做“接龙预测”式的生成。模型内部的参数里确实编码了大量人类知识，但有一个致命缺陷——它的知识边界在训练完成那一刻就被冻结了。

举个例子，我让模型预测某个产品的最新价格，它如果训练数据只到去年，它就只能靠“猜”，猜出来的即使语法通顺、逻辑完整，也可能是错的。更要命的是，企业内部文档、个人笔记、私有知识库这些数据，从来就不在公开训练语料里，模型连“猜”的依据都没有。

这个问题的本质是：模型的参数化记忆（parametric memory）有容量和时效的双重瓶颈。你不可能把一个公司几千页的规章制度全部塞进Prompt里，因为上下文窗口有限，成本也扛不住；你也没法指望模型“记住”那些它从未见过的私有数据。

RAG——Retrieval-Augmented Generation，检索增强生成——就是冲着这个痛点来的。它的思路很朴素：模型不需要什么都记住，它只需要知道“不懂的时候去哪里查”。把知识从模型的“脑子”里搬出来，放进一个外部检索系统，生成的时候先把相关资料捞出来，再让模型基于这些资料来回答。

这样带来的直接好处有三个：信息时效性提高了，因为外部知识库可以随时更新；私有数据可控了，因为知识可以授权管理；幻觉减少了，因为模型回答问题时有据可依。我在做某企业客服助手时，用上RAG之后，回答准确率从纯LLM的六成多直接升到了九成——这个提升幅度，靠调Prompt是绝对做不到的。

所以如果你正准备用LangChain做RAG，第一步要搞清楚的不是代码怎么写，而是理解这个架构为什么存在：它不是为了“炫技”，而是为了解决LLM的固有缺陷。搞明白这一点，后面所有的技术选型你都能找到判断依据。

2. LangChain在RAG体系里扮演的角色：一个并不复杂的编排框架

很多人一听到LangChain就觉得是个“大而全”的框架，学习成本很高。我用下来最大的感受是：它的核心价值就四个字——编排组装。LangChain不实现LLM本身，不做向量检索的核心算法，它做的事情是把RAG流水线里各个环节“粘”在一起，并且把不同厂商的模型、不同种类的向量数据库、不同格式的文档加载器，都统一成一套标准接口。

2.1 为什么需要编排层：直接手搓也不是不行

其实RAG流水线自己用原生代码也能写：一个文档读取函数、一个文本切分函数、一个Embedding接口、一个向量存储、一个LLM调用，再加一个Prompt拼接，总共几百行代码就能跑通。我最早做第一个RAG Demo时，就是直接用脚本裸写的，也没用任何框架。

那LangChain的价值在哪里？我自己的体会是：

• 生态整合省去对接成本。你要用PDF载入器、要用某个向量库、要调特定厂商的LLM接口，每个都需要单独读文档、写适配代码。LangChain把这些都封装好了，接口风格统一，换底层实现只改一两行配置。
• 组件可替换。今天用OpenAI的Embedding，明天想换成开源的本地模型；今天存FAISS，明天换Milvus。标准接口让替换成本大幅下降。
• 提供工程化参考。即使你最终决定不用LangChain，阅读它的链式设计、Prompt模板管理方式，对你自己设计架构也有很大启发。

我见到不少团队把LangChain当成“必须用”的东西，其实没必要。如果你只有一个固定场景、数据格式固定、也不打算换服务商，裸写反而更轻。但如果你在探索期、需求变化快，LangChain能帮你省掉大量重复劳动。

2.2 RAG全流程拆解：五个关键环节

从宏观视角看，一条标准的RAG流水线由五个环节组成，LangChain都有对应的组件：

这五个环节环环相扣。大多数人做RAG效果不好，最根本的问题不是生成环节，而是前三环——文档加载、文本分割、向量化。数据没处理好，检索就捞不到好料，后面LLM再强也是“巧妇难为无米之炊”。

后面我就按这个全流程，带着你从零搭建一个最小可用的RAG系统。我会用一套示例文档、一个开源Embedding模型、FAISS向量库和任一主流LLM接口，整个过程完整可复现，代码可以直接抄。

3. 从零搭建一套Minimal RAG：完整实操代码与参数说明

这一节是整篇文章最核心的部分。我不准备用太复杂的例子，而是以一个模拟项目X的知识文档为例，搭建一套最小闭环的LangChain RAG系统。所有代码我都在本地跑过，你可以照搬，也可以根据自己数据调整。

先交代一下环境版本。我使用Python 3.10，LangChain的版本经历了比较大的迭代，老版本用langchain.llms、langchain.embeddings这种路径，到了0.1版本以上改成了langchain_community、langchain_openai这种按集成方拆分的包结构。我下面的代码用新版写法，如果你还在用旧版，注意路径差异。

3.1 环境准备与依赖安装

我的建议是先用一个干净的虚拟环境，避免依赖冲突：

python -m venv rag_env source rag_env/bin/activate # Windows下执行 rag_env\Scripts\activate pip install langchain langchain-community langchain-openai langchain-text-splitters faiss-cpu python-dotenv

这里解释一下每个包的必要性：

• langchain：核心框架，包含Chain、Prompt模板、LCEL表达式语法
• langchain-community：社区维护的集成组件，包括文档加载器里的很多非官方适配
• langchain-openai：OpenAI系接口的封装，也可以用这包接兼容OpenAI协议的其他服务
• langchain-text-splitters：文本分割器，新版本从主包独立出来了，需要单独装
• faiss-cpu：FAISS向量库的CPU版本，本地验证足够用，数据量大再考虑GPU版
• python-dotenv：管理API Key，避免硬编码到代码里

安装完尽量确认一下版本不要差太多，LangChain迭代太快了，有些API经常调整。如果你装的时候已经出了新版本，API有大改，优先看对应版的官方文档。

3.2 文档加载：这一步决定了你能“看到”什么

RAG的质量上限，从文档加载就定下来了。加载器负责把不同来源的内容转换成统一的Document对象——一个文档里包含page_content（正文文本）和metadata（元数据，比如来源路径、页码、标题等）。

假设你有一批Markdown格式的产品手册，最简单的加载方式是目录加载器：

from langchain_community.document_loaders import DirectoryLoader from langchain_community.document_loaders import TextLoader # 加载指定目录下的所有.md文件 loader = DirectoryLoader( "./docs/", glob="**/*.md", loader_cls=TextLoader, loader_kwargs={"encoding": "utf-8"}, # 中文文档一定注意编码 show_progress=True, recursive=True, # 递归扫描子目录 ) documents = loader.load() print(f"共加载了 {len(documents)} 个文档") for doc in documents[:3]: print(f"来源: {doc.metadata['source']}，长度: {len(doc.page_content)} 字符")

这里有个非常容易被忽略的坑：文档加载的编码问题。中文Markdown文件如果本身是GBK编码，而Loader默认按UTF-8读，读出来就是乱码。我在第一次跑真实数据时就踩过这坑，报错不是乱码而是UnicodeDecodeError，排查了半天才想起来服务器上的文件可能是Windows编辑器保存成了GBK。

PDF、Word、HTML格式分别对应PyPDFLoader、Docx2txtLoader、BSHTMLLoader，它们通常需要先装对应的解析库：

# PDF from langchain_community.document_loaders import PyPDFLoader loader_pdf = PyPDFLoader("./docs/产品说明.pdf") # Word from langchain_community.document_loaders import Docx2txtLoader loader_docx = Docx2txtLoader("./docs/操作指南.docx") # HTML from langchain_community.document_loaders import BSHTMLLoader loader_html = BSHTMLLoader("./docs/帮助中心.html")

加载完成后，一种常见做法是把同一来源的多个碎片合并或者至少打上统一的元数据标记。比如source字段统一成相对路径，这样检索结果里可以明确告诉用户“这条信息来自哪个文档”。实际做知识库问答时，这个来源标注除了方便溯源，还能帮你分析检索质量问题——到底哪些文档频繁被命中，哪些文档从未被检索到，从而优化数据切分。

3.3 文本分割：一篇文章切成几块，直接决定检索命中率

文本分割是整个RAG流水线里，最容易被低估却又对效果影响最大的一环。分割太粗，一个 chunk 里混了多个主题，检索时按向量相似度匹配不精准；分割太细，单个 chunk 信息量不足，就算被检回来了，LLM也没有足够的上下文来组织答案。

LangChain提供了RecursiveCharacterTextSplitter，它是通用场景下的默认之选。核心思路是：用一个“候选分隔符列表”，按优先级从高到低尝试切分，尽量保持语义完整。

from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, # 每块目标长度，按字符数算 chunk_overlap=50, # 相邻块之间的重叠长度 separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""], # 按中文标点优先切 ) chunks = text_splitter.split_documents(documents) print(f"分割完成，共得到 {len(chunks)} 个文档块")

参数怎么定？我给一个经验参考：chunk_size在300-800之间都算合理区间。块太小，检索回来的内容常常信息残缺；块太大，向量表示的语义会被稀释，检索精度下降，同时塞进Prompt的token也变多。

为什么要设置chunk_overlap？想想你写文章时的段落过渡——上一段的结尾往往引出了下一段的主题。要是硬生生在“企业介绍”和“产品参数”之间切断，检索“企业规模”这个问题时，下一块只含产品参数就不容易匹配上。重叠部分像个缓冲带，能规避信息断崖。一般取chunk_size的10%-20%即可，我常用的配比就是500/50。

对于中文文本，分隔符列表里一定要加入中文标点。默认的separators是按英文习惯设计的，只含换行和空格，对中文不友好。你可以在代码里把分隔符扩展成我上面写的那个列表，其中“。”和“；”的优先级要高于空格，这样切出来的块在语义上完整得多。

3.4 向量化与存储：Embedding模型决定了“语义”算不算数

文本块本身无法直接计算相似度，需要先转成向量。这一步用的是Embedding模型，它的质量直接影响检索效果——向量空间里的“远近”是否真的对应语义上的“相关”，全靠它。

OpenAI的text-embedding-3-small质量好、调用简单，但数据要发到外部服务，对隐私敏感的项目不合适。我本地测试常用BAAI/bge-small-zh-v1.5这个开源中文模型，几秒钟就能下载完，免联网，效果也不错。

from langchain_community.embeddings import HuggingFaceEmbeddings # 使用开源的bge中文Embedding模型 embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5", encode_kwargs={"normalize_embeddings": True}, # 归一化后内积即余弦相似度 )

注意normalize_embeddings这个参数，官方建议设成True。归一化之后，向量的内积就等于余弦相似度，FAISS在做内积检索时效率更高，精度不变。

向量库我用FAISS，原因就俩字：省事。它是纯本地运行、单机部署、无需额外启动服务，对中小规模文档（几十万条以内）检索性能完全够。安装用faiss-cpu，生产环境如果量大了，再换Milvus或Qdrant也不迟，LangChain的接口在这些向量库之间切换通常只改一个类名。

from langchain_community.vectorstores import FAISS # 建库：把分割好的chunks转换并写入向量库 vectorstore = FAISS.from_documents( documents=chunks, embedding=embeddings, ) # 本地持久化，下次直接加载 vectorstore.save_local("./faiss_index") # 重新加载 vectorstore = FAISS.load_local( "./faiss_index", embeddings, allow_dangerous_deserialization=True, # 新版需要此参数 )

allow_dangerous_deserialization=True这个参数是新版才有的，因为FAISS索引文件本质是序列化对象，官方出于安全考虑默认禁止加载。你自己的实验环境传True没问题，但如果是团队共享的、不可信来源的索引文件，就要警惕了。

3.5 检索与生成：把“查到的”变成“答好的”

向量库建好之后，检索就简单了。直接调用similarity_search，传入用户问题，返回最相似的top-k文档块。

query = "项目X的系统支持高并发吗？" retrieved_docs = vectorstore.similarity_search(query, k=4)

这里k=4意味着每问一个问题，会捞出4个相关块。k太小，可能漏掉关键信息；k太大，无关内容混进来的概率上升，还会白白消耗Prompt的token预算。我实测普通问答场景k取4-6比较顺手。

真正体现LangChain编排能力的是下一步：用一个Chain把“检索-组装Prompt-调用LLM-输出”串联起来。新版LangChain主推LCEL表达式语法，用|管道符串联组件，可读性非常高：

from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 1. 定义检索器：从向量库中检索相关文档 retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) # 2. 定义Prompt模板 prompt = ChatPromptTemplate.from_messages([ ("system", """你是一个严格依据检索资料回答问题的助手。 规则： - 只回答与检索资料相关的问题，资料中没有的信息不要推测。 - 如果资料不足以回答用户问题，请明确说明"根据现有资料无法回答"。 - 回答时优先引用资料的原文措辞，保持信息准确。 - 请在回答末尾标注信息来源列表。 检索资料： {context}"""), ("human", "用户问题：{question}"), ]) # 3. 定义一个把检索结果拼接成上下文的函数 def format_docs(docs): return "\n\n".join(f"[来源: {d.metadata.get('source', '未知')}]\n{d.page_content}" for d in docs) # 4. 用LCEL把组件串联成链 rag_chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0) | StrOutputParser() ) # 5. 调用链 result = rag_chain.invoke("项目X的系统支持高并发吗？") print(result)

这段代码里{"context": retriever | format_docs, "question": RunnablePassthrough()}是关键。retriever | format_docs表示先执行检索，再把检索结果传给format_docs拼成上下文字符串；RunnablePassthrough()的作用是把用户原始问题原样透传到Prompt里。

为什么LLM的temperature要设为0？因为RAG场景下我们要的是“依据资料准确回答”，不是“发挥创造力”。temperature越高模型越自由，越容易脑补出资料里没有的事实。0的设定下，模型几乎只从给定的context里组织语言，幻觉风险大大降低。这个参数是RAG应用里最容易被忽视却影响很大的细节。

跑通之后，你的第一个LangChain RAG系统就成型了。你可以拿几篇自己的文档测试，问几个问题看看效果。这时候大概率会发现：有回答得很好的问题，也有答非所问甚至瞎编的时候。别急着怀疑代码，下面的实测踩坑才是真正的重头戏。

4. 实测踩坑记录：为什么“检索到了”却“回答不好”

我的第一个RAG Demo跑通时，问了三个问题，两个答得不错，一个完全答偏。当时我第一反应是“LLM不行”，后来排查了一圈，发现问题全不在LLM，而是出在检索链条上。我把这些坑一一拆开讲，每一个都是真实项目里会发生的情况。

4.1 检索内容不相关：最常见的翻车现场

现象：问“项目X的数据备份策略是什么”，检回来的四个chunk里有两个根本没提“备份”，而是讲“部署架构”；LLM只能硬着头皮答，答得就偏了。

根因在哪？让chunk之间语义太“糊”。如果原文档里“部署架构”这一节长达几千字，切分后多个chunk的向量都高度相似，检索前四名里就挤进来好几个。这不是Embedding模型的错，而是文档里该主题的内容占比太大，稀释了问题的特异性。

解决办法有三个方向，按效果排序：

第一，精细切分。按文档的章节结构切，而不是机械按固定字符数切。Markdown文档可以通过MarkdownHeaderTextSplitter按标题层级分割，这样每个chunk天然对应一个完整小节，主题聚焦。

第二，增加检索结果数量再重排。把k从4提到20，先捞回足够多的候选，再用CrossEncoder重排序模型把真正相关的排到最前，取前4个进入Prompt。这种方式比单纯调k效果好得多，后面我详细讲。

第三，问题改写扩充。有些问题表达含糊，检索容易跑偏。可以先用LLM把用户问题改写成一个更详细的检索查询，再做向量检索。也有的做法是把原始问题和改写后的查询都拿去检索，合并结果后去重。

4.2 上下文窗口挤压：chunk太多反而帮倒忙

现象：我把k设成8，想着多给点资料总没错，结果LLM输出越来越冗长，还开始“跑题”——因为8个chunk拼出来的context太长，有些chunk主题并不相关，模型被干扰了。

当时我问一个具体型号的参数，正确答案就在第三个chunk里，但前面两个不相关chunk把Prompt开头的位置占了，模型生成时更注意前后文位置靠前的信息。这有点像你看一篇文章，开头几段留下的印象最深——LLM也有类似的“注意力偏置”。

**这块的教训很直接：不是资料越多越好，关键信息在Prompt里的位置很重要。**我后来的做法是，固定k=4-5，然后通过重排序把最相关的chunk排到最前面。这样既保证上下文不臃肿，又让模型优先看到核心依据。

4.3 答案“一本正经地胡说八道”：幻觉从何而来

你可能会想：资料都检索到了，LLM照着念不就行了，怎么还会编？实测中我发现，幻觉主要来自三种情况：

第一种是检索结果里只有部分答案。比如资料里写了“支持每日全量备份”，但没写“支持增量备份”，用户问“支持增量备份吗”，模型会倾向于根据常规知识脑补“支持”，而不是老实说“未见明确描述”。这是Prompt规则约束不足导致的——你如果只写“根据资料回答”，模型自由度就太高。

解法是在Prompt里明确“无中生有”的处罚规则。我用的措辞是：“检索资料中没有明确提到的信息，一律不要回答，统一回复：现有资料未涉及该问题。”实测这个简单改动就把幻觉概率降了一大截。

第二种是结论型的“合理推断”。资料上说“系统支持水平扩展”，模型就推断“因此可以支撑千万级用户”——这一步推断看起来合理，实际上资料里根本没有千万级这个数字。对这种“推导型幻觉”，目前最有效的还是在Prompt里加“禁止推理补全，只能转述资料原文”，以及设置低temperature。

第三种是检索到的资料本身不完整。比如某页PDF只截到了表格半截，数字不全。这种情况靠Prompt措辞已经无解，必须回到源头把文档质量问题解决掉。这也是我一直强调“数据优先”的原因。

4.4 开源Embedding的中文表现：一个需要对齐的预期

刚开始我用的Embedding是text-embedding-ada-002（英文模型），处理中文文档时，检索效果堪称灾难——明明语义相关的两句话，向量距离却很远。后来换成bge-small-zh-v1.5，情况立刻改善，但也没有好到“完美”的程度。

原因不难理解：向量模型是“语义压缩器”，它的能力上限取决于训练语料的覆盖程度。中文商业领域文档的专用术语、产品名、缩写，开源模型往往训练得不够充分。你在跑通Demo后，如果发现某些专业词汇检索总是不准，可能不是代码的问题，而是Embedding模型的语义覆盖有盲区。

换模型是直接解法：中文场景可以试bge-m3、text-embedding-3-large（多语言版），英文技术文档也可以试text-embedding-3-small。对比办法很简单：把同一批检索问题分别用不同Embedding模型跑一遍，看召回的chunk是不是你要的那几个，用脚投票，别信参数指标。

5. 进阶调优思路：让RAG从“能用”到“好用”

跑通Demo只能算开始，真正上线给人用，还差着好几步工程优化。这一节分享我压箱底的几个进阶玩法，都是我实际用过的组合。

5.1 混合检索：向量+关键词互补

向量检索擅长“语义相关”，但有一个明显弱点：对精确匹配不敏感。比如文档里全是“CRM系统”这个写法，你搜“crm软件”，向量检索一般能找到；但如果你搜“CRM”（全大写），向量模型可能觉得和“crm”差不多，但关键词检索能精确命中。反过来，关键词检索的死穴是同义词和语义改写——你说“如何卸载”，文档里写的是“如何移除”，关键词就彻底失灵。

所以混合检索的思路是：向量检索和BM25关键词检索各跑一遍，合并结果再去重排序。LangChain里可以用EnsembleRetriever把两者组合：

from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever bm25_retriever = BM25Retriever.from_documents(chunks, k=4) vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) ensemble_retriever = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.4, 0.6], # 关键词和语义的权重配比 )

权重配比没有标准答案，建议先平权重跑起来，再根据你数据的特征微调。如果文档里专业术语多、缩写多，关键词权重可以调高一点；如果文档里口语化表达多、语义改写频繁，向量权重应该更高。

5.2 重排序：检索的最后一道质检

混合检索拿到候选集之后，质量往往参差不齐。可以做一道“精筛”——用重排序模型（Reranker）对候选集逐条计算“与问题的相关度分数”，按分数降序取top-n进入Prompt。这和Embedding检索的区别在于：重排序模型是“带着问题去看文档对”，它不是把两边各转成向量再比远近，而是把问题和文档拼在一起过一遍交互式模型，相关性判断更准，代价是速度慢、成本高——所以它只做“精排”，不做“粗筛”。

HuggingFace上有很多现成的中文重排序模型，比如BAAI/bge-reranker-base。用LangChain接入也很简单，我常用的写法是：

from langchain.retrievers import ContextualCompressionRetriever from langchain_community.document_compressors import CrossEncoderReranker from langchain_community.cross_encoders import HuggingFaceCrossEncoder reranker = HuggingFaceCrossEncoder(model_name="BAAI/bge-reranker-base") compressor = CrossEncoderReranker(model=reranker, top_n=4) compression_retriever = ContextualCompressionRetriever( base_compressor=compressor, base_retriever=ensemble_retriever, )

top_n=4表示经过重排序后只保留最相关的4个chunk进入Prompt。实测这个组合比单一向量检索的回答准确率提高了十多个百分点。代价是每次检索多一次模型推理，延迟大约增加几十到几百毫秒，看你用的重排序模型大小。对这种“用一点延迟换大幅准确率”的取舍，我的倾向是值得的——用户对多等半秒的容忍度，远高于对答非所问的容忍度。

5.3 多路召回与问题改写：小技巧，大收益

RAG检索失败的一大原因是用户问题太短太含糊。比如用户问“多少钱”，如果知识库里的文档写的是“定价方案”，向量检索可能匹配不到。最简单的处理是加一个“问题理解”前置步骤：把原始问题喂给LLM，让它扩写成更明确的检索语句。

LangChain里可以用一个子链实现：

rewrite_prompt = ChatPromptTemplate.from_template( """请将用户的模糊问题改写成适合检索的清晰查询。 原始问题：{question} 改写要求：补全关键实体，明确检索的核心主题，保持简洁。 改写结果：""" ) rewrite_chain = rewrite_prompt | ChatOpenAI(model="gpt-4o-mini", temperature=0)

用户问“多少钱”，改写后可能是“项目X企业版的定价方案和收费标准”。这样检索时命中率会高很多。建议把改写后的query和原始query分别检索一次，合并结果。

还有一个容易被忽略的优化是元数据过滤。如果知识库里有多个产品线的文档，检索时可以先用元数据（比如产品线、文档类型、时间范围）把候选集缩小。这样既提高了效率，也避免了“问A产品答B产品”的串线问题。LangChain的MultiQueryRetriever、SelfQueryRetriever都是干这类事情的，前者用LLM生成多个不同表述的查询，后者根据文档元数据自动构造过滤条件，值得你深入了解。

5.4 关于“向量库选型”的一点个人看法

很多教程一上来就推荐Milvus、Weaviate之类的生产级向量库，我觉得对绝大多数刚入门的人是个负担。FAISS本地跑够用，数据量到了百万级再考虑分布式向量库也不迟。原因很简单：RAG的瓶颈通常不在向量检索的吞吐，而在数据质量和检索策略。先搞定数据切分、Embedding选择、重排序这些“软功夫”，向量库只是存储介质，换起来最省事。

如果你确实要上生产环境，我的建议排序是：Qdrant（部署简单）、Milvus（功能全但重）、Elasticsearch（团队如果本来就有ES，加个向量插件就行）。选型核心看团队运维能力和数据规模，别盲目跟风。

写在后面：从“跑通Demo”到“上生产”的几道坎

最后分享几个我反复踩过、不忍心看你再踩的坑。

第一道坎是数据清洗。知识库文档里如果有乱码、重复段落、空章节，直接扔进切分器，垃圾进垃圾出。我有一回检索“退款政策”，结果捞回来一个“退款政策”标题下内容是空的chunk，LLM拿着空内容一本正经地编了一百多字政策说明。后来我在加载环节前加了两个预处理：去掉HTML标签残留、合并连续空行。

第二道坎是评估体系。RAG的效果没法靠“感觉”判断。我建议每个项目都准备三五十条问答作为测试集，每次改动后用同一套测试集跑一遍，对比检索命中率和回答准确率。没有评估，你所有的“优化”都是盲人摸象，你根本不知道哪个改动是真正有效还是自我安慰。

第三道坎是成本控制。RAG跑起来有两个成本大头：Embedding调用和LLM生成。如果查询量很大，可以把Embedding模型换成开源本地版，省掉每百万token的按量计费；如果context太长，可以控制chunk数量和大小，降低LLM的token消耗。成本控制属于“后置优化”，但别等账单炸了才想起这回事。

我自己的习惯是，LangChain版本升级后先跑一遍回归测试——这个框架迭代是真的快，今天能跑的代码，半年后可能就有新写法了。给项目留好测试集，哪天API变了，你能快速知道问题出在哪了。

RAG这个方向，内容的厚度远超一篇基础文能覆盖的。把基础的流水线跑通、把上面的坑挨个踩明白，你就已经超过了大多数停留在“看完教程觉得会了”的人。剩下的，就是拿着自己的真实数据，去折磨你的RAG系统——它越脆弱，你学到的东西越多。