企业官网建设流程全解析

真正把RAG跑通之后，我才意识到它之所以成为大模型落地的主流方案，核心原因就四个字：“成本可控”。模型参数动辄几百亿，靠微调去更新知识库，一次训练烧掉的钱和时间都让人肉疼；而RAG把外部知识挂在检索器上，改文档不改模型，效果却立竿见影。这篇笔记我按自己踩坑的顺序来写，从概念拆解到最小实现，再到评估和优化，整个过程坚持“能跑通才叫懂”，希望看完你也能搭出一个属于自己的问答系统。

1. 为什么大家都在用RAG，它到底解决了什么问题

1.1 大模型与生俱来的三个短板

先说一个最直观的场景：你把一份公司内部的产品手册扔给ChatGPT，问它某个配置参数是什么意思，它十有八九答不上来，或者直接编一个。原因不复杂，大模型的训练语料是固定的，知识截止日期摆在那里，内部资料它根本没见过。这个现象背后对应的是大模型的三个原生短板。

第一是知识过时。模型训练一次要几个月，等它上线时，世界已经变了。你问它最新的软件版本特性，它只能用旧知识硬凑。第二是幻觉问题。模型本质是概率生成，遇到不知道的内容时会用“合理但不正确”的话来填补空白，这在需要精确事实的场景里是致命的。第三是缺乏领域数据。通用模型不可能覆盖每个行业的私有知识，你让它分析某套系统的报错日志，它连日志格式都不认识，更别说给出有效建议。

在这三个短板面前，传统做法是微调（Fine-tuning），用领域数据去调整模型权重。但微调有它的麻烦：训练需要GPU资源、需要高质量标注数据、每次知识更新都要重新训练。更重要的是，微调改变的是模型的“行为模式”，而不是让它“记住事实”。你不能指望靠微调让模型精确记住一百个客户的合同条款，因为模型擅长的是推理和生成，不是当数据库。

1.2 RAG的核心思路：检索增强，长在模型外面的记忆

RAG（Retrieval-Augmented Generation，检索增强生成）的思路跟微调完全不同。它不碰模型本身，而是在模型外面挂一个“外挂知识库”。当用户提出问题时，系统先从知识库中检索出最相关的文档片段，把这些片段和原始问题一起拼进Prompt，让模型基于检索到的内容来组织回答。

你可以把它想象成一个开卷考试：微调是让模型把这些知识点背进脑子里，RAG是允许它翻书，但要把翻到的那几页内容写在答题纸上。开卷的好处是你可以随时更新书里的内容，也不必担心模型背错记混。

这个思路带来了几个直接的好处。知识实时可更新：知识库的文档改了，下一篇生成的回答就跟着变，不需要重训模型。回答可追溯：模型是根据检索到的具体片段回答的，你可以把引用的原文返回给用户，这解决了“AI乱说”的信任问题。权限可控：知识库可以按用户级别隔离，不同人检索到不同范围的内容，这在企业场景中很关键。

1.3 RAG、长上下文与微调怎么选

有个常见的疑问：现在模型的上下文窗口越来越大，几百K都出来了，直接把文档全塞进Prompt不就行了，为什么还要RAG？我的实测感受是，长上下文能解决问题，但有两个前提：一是成本，上下文越长，每轮对话的Token消耗越大，一次查询烧掉几十万Token，长期跑下来费用非常可观；二是精度，模型对超长上下文中信息的利用并不均匀，中间部分容易被忽略，声称为“大海捞针”，事实是针放中间经常捞不回来。

所以我的理解是这样：上下文窗口解决的是“信息能否塞得下”，RAG解决的是“信息能否找得准”。两人可以搭配使用，RAG负责把范围缩小到最相关的几段，长上下文负责对这几段做充分的推理。而微调则应用在另一个维度，当你要改变模型的风格、遵循特定指令格式、适应特定领域术语时，微调仍然不可替代。

2. 经典RAG管道拆解：索引、检索、生成三段式

2.1 索引阶段：把文档变成可搜索的向量

搞懂RAG，首先得理解它背后的数据流。整个管道可以拆成三个大阶段：索引（Indexing）、检索（Retrieval）、生成（Generation）。

索引阶段干的事情是把杂乱无章的原始文档变成结构化的向量数据库。步骤大致是：加载文档、切块（Chunking）、向量化（Embedding）、入库。听起来简单，但每一步都有不少门道。

先说切块。一篇文档可能有几千字甚至几万字，你不能把整篇都向量化成一个向量，因为检索命中是“颗粒度”的问题。问题只会针对文档中的某个细节，你要保证这个细节所在的那个块能被精确命中。如果块太大，向量包含太多无关信息，检索到的内容不精准，模型回答就容易跑偏；如果块太小，可能截断了完整语义，一句话只有半句，模型没法理解上下文。我比较常用的初始值是每块512个字符左右，块间重叠50个字符，因为语义在边界处是连续的，留一点重叠能降低截断风险。当然这只是起点，具体数值要按文档类型调，后面细说。

然后是向量化。这一步是把文本变成一串浮点数，让语义相近的文本在向量空间里距离也相近。业界常用的是OpenAI的embedding接口，但生产环境我建议用开源模型，比如BGE系列或国产的嵌入模型，部署在本地，既省接口费用，也不受网络波动影响。选型时优先看MTEB（多语言文本嵌入基准）榜单上中文表现好的模型。

向量入库后，索引阶段就算完成了。这阶段有个经常被忽视的细节：文档预处理。PDF里的表格、页眉页脚、扫描件里的乱码，若直接进切块器，检索到的可能就是一堆垃圾文本。我遇到过最典型的情况：某些PDF转出来的文本中能插入大量换行，切块切得七零八落，检索全乱了。后来统一用文档解析库做预处理，规则是“先清洗、后切块、再向量化”。

2.2 检索阶段：从向量库里捞最相关的片段

索引完成之后，用户的每个问题都会走一遍类似流水线的流程：问题向量化，然后在向量库里做相似度搜索，找出最相似的Top-K个片段。

核心的检索方式有两种：向量检索（语义检索）和关键词检索（稀疏检索）。向量检索解决“意思相近但表述不同”的问题，比如用户问“怎么提高图片加载速度”，文档里写的是“优化图像资源的传输效率”，二者没有公共词，但语义一致，向量检索能匹配上。关键词检索解决“精确术语命中”的问题，比如用户查询“HTTP 302”，文档里就是这个词，向量检索反而可能被语义相近的干扰项带跑偏。现在的主流做法是混合检索，两路召回再合并去重，效果好过单独任何一路。

这个阶段有几个关键参数要关注：

• Top-K：检索返回多少个片段。太小容易漏掉关键内容，太大则噪音增多，模型不知道该信哪个。我通常设为4到6。
• 相似度阈值：低于阈值的片段直接丢弃。这个能防止“没相关内容硬答”的情况，宁可告诉用户没找到，也别让模型瞎编。
• 重排序（Rerank）：召回阶段用效率高的轻量模型做粗筛，拿到几十个候选片段后，再用重排序模型做精排，把最匹配的放在前面。

这里多说一句重排序。很多初学者觉得RAG效果不好，问题不在生成，而在“检索回来的内容压根不对”。Top-K个片段里有用的可能就一个，被其他噪音挤掉了。重排序相当于加了一轮“精挑细选”，效果提升非常明显，代价是多花几十毫秒。

2.3 生成阶段：把检索结果和问题一起喂给大模型

检索完成之后，所有内容都拼接成一段Prompt，交给大模型去生成。这段Prompt的模板设计对回答质量影响巨大，值得单独花时间打磨。

我的常用模板结构大致是：

请只根据以下资料回答问题。如果资料中没有相关信息，请直接回答“根据现有资料无法回答”，不要编造内容。 【资料】 {拼接好的检索片段} 【问题】 {用户原始问题}

这里面有几个细节。第一，要明确要求模型“只根据资料回答”，否则它还是会被预训练知识带跑。第二，要给模型“承认不知道”的空间，明确告诉它资料中没有就直说，这能显著降低幻觉率。第三，资料之间的分隔符要清晰，避免模型把多段资料混在一起。第四，如果原始问题有指代关系，比如用户说“它的性能怎么样”，而你拼接的资料里有两份文档，模型可能搞不清“它”指谁，这时可以先用一个小模型做对话改写，把指代词补全。我在实际项目里用三步改写：判断是否需要引入外部知识，补全指代，生成检索用的关键词。效果很不错。

生成阶段还有温度参数的设置。回答事实性问题时，Temperature建议设为0或接近0，减少随机性，让模型更忠实于资料内容。如果需要发散性或创意性回答，可以适当调高到0.7左右。做问答系统时不要忽略这个参数，它对你的结果稳定性影响很大。

3. 零基础手搓一个最小RAG系统

3.1 技术选型与运行环境准备

理论说多了容易飘，我们来点实际的。我这次实现的目标很简单：给一套几十页的技术文档搭一个问答机器人，问什么答什么，答案来自文档本身。

环境清单如下：

• Python 3.10+
• 向量化模型：本地的开源Embedding模型，BGE系列的中文版或英文版，具体看你的文档语言
• 向量数据库：Chroma（轻量级，适合学习和中小规模项目）
• 大模型：通过Ollama跑本地量化模型，比如7B或14B级别的，兼顾成本与效果
• 辅助库：LangChain（编排工具，帮助串联各环节）

这里有个选型原则想强调一下。向量数据库的选择取决于数据规模，数据在百万级以内，Chroma完全够用。如果你要处理千万级以上的向量，再考虑专门的向量数据库。轻量起步，测量后按需升级，不要一上来就搭大数据集群。

3.2 文档加载与切块实操

代码的全貌是这样的。我先把实现按步骤拆开讲解，先从文档加载与切块开始。

# 文档加载与切块 from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载PDF文档 loader = PyPDFLoader("./product_manual.pdf") documents = loader.load() # 2. 文本清洗：去掉多余换行和空白字符 for doc in documents: doc.page_content = " ".join(doc.page_content.split()) # 3. 切块 text_splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=50, separators=["\n\n", "\n", "。", "；", "，", " ", ""], ) chunks = text_splitter.split_documents(documents) print(f"切块数量: {len(chunks)}")

切块器用递归字符分割器，它的逻辑不复杂：按照分隔符优先级从高到低逐级切分，尽量保持语义完整。代码里的separators参数按照“段落、换行、句号、分号、逗号”的顺序来，这样切出来的块更符合自然语言边界。

我在这个环节踩过一个坑，分享一下。某次文档里有很多代码样例和API参数表，用512的窗口切完后，很多块落到代码片段中间，语义不完整，检索命中后给模型的上下文根本读不通。后来针对这种文档，我把separators里的“空格”优先级下调，并增加了按代码块的标记（如def、class等）做二次切分的逻辑，效果好很多。切块必实测，别信默认参数。

3.3 向量化与入库：用最少的代码跑通全流程

向量化与入库，核心代码如下：

# 向量化与入库（使用开源embedding模型，完全本地化） from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma # 加载本地embedding模型 embedding_model = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5", model_kwargs={"device": "cpu"}, encode_kwargs={"normalize_embeddings": False}, ) # 创建向量库并持久化到本地 vectorstore = Chroma.from_documents( documents=chunks, embedding=embedding_model, persist_directory="./chroma_db", # 向量库持久化目录 ) print(f"已入库 {len(chunks)} 个文本块")

这里我用的Embedding模型是BGE系列的中文模型，大小只有约100MB，CPU也能流畅运行，完全离线，数据不出本地。如果文档是英文为主，换成BAAI/bge-small-en-v1.5即可。注意encode_kwargs里的normalize_embeddings要设为False，因为Chroma默认会做归一化，两边设置不一致会导致余弦相似度计算结果错误。

如果你不想用LangChain，更愿意看清内部原理，我建议你写一个最小实现。用FlagEmbedding库加载BGE模型，手动把文档分批向量化，然后直接往Chroma里插入向量。这种方式能让你明确知道每一步传入传出的是什么，踩坑也容易定位。

3.4 自定义检索逻辑：从向量到上下文

向量库建好了，检索逻辑就简单了。但我要多走一步，做一个带“阈值判断”的检索，避免无关问题也硬检索。逻辑是：拿到问题向量后，在库里搜Top-K个片段，但只保留相似度高于阈值的片段，没有片段时就返回“库中没有相关内容”。

# 自定义检索器：结合阈值判断 from typing import List def retrieve_with_threshold(query: str, top_k: int = 4, threshold: float = 0.35) -> List[str]: """ 根据问题检索相关文档片段，相似度低于阈值的结果被丢弃。 如果最终没有片段，返回空列表。 """ results = vectorstore.similarity_search_with_relevance_scores(query, k=top_k) filtered = [doc.page_content for doc, score in results if score >= threshold] return filtered # 示例 query = "产品支持哪些操作系统？" chunks_found = retrieve_with_threshold(query, top_k=4, threshold=0.45) for i, c in enumerate(chunks_found): print(f"片段{i+1}: {c[:100]}...")

阈值到底设多少，没有标准答案，跟Embedding模型的打分规律强相关。BGE模型的相似度分数普遍偏高，经常在0.5以上；有些模型则集中在0.2到0.4之间。所以阈值必须用自己的数据实测标定，先跑几个典型问题看看分数分布，再定底线。我标定过一次后才发现，最初设的0.5把有效结果全过滤了，后来调到0.35才正常。

3.5 接入本地大模型：用Ollama跑通问答闭环

最后一步是把生成的模型接进来，完整跑通问答闭环。我这里用Ollama把模型跑在本地，通过OpenAI兼容接口调用，这样即使没有公网，系统一样可用。

# 接入本地大模型，完成问答闭环 from openai import OpenAI import os client = OpenAI( base_url="http://localhost:11434/v1", # Ollama默认服务地址 api_key="ollama", # 本地服务不校验，任意值即可 ) def answer_question(query: str) -> str: # 1. 检索相关片段 chunks_found = retrieve_with_threshold(query, top_k=4, threshold=0.35) # 2. 构造上下文 if not chunks_found: context = "没有找到相关内容" else: context = "\n\n".join([f"【片段{i+1}】\n{c}" for i, c in enumerate(chunks_found)]) # 3. 构造Prompt prompt = f"""请严格根据以下资料回答问题。 如果资料中没有相关信息，直接回答“根据现有资料无法回答”，不要自行编造。 【资料】 {context} 【用户问题】 {query} """ # 4. 调用本地模型 try: response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}], temperature=0.1, # 事实问答场景，温度调低 max_tokens=512, ) return response.choices[0].message.content except Exception as e: return f"调用模型失败: {e}" # 测试 print(answer_question("产品的授权方式是怎样的？"))

到这里，一个能跑通的最简RAG系统就完成了。从加载文档到检索到生成，总共不过几十行代码，但每个环节的核心流程覆盖了。我觉得尤其适合作为学习项目把整个链路跑一遍，比自己看十篇教程都管用。

3.6 运行中的资源占用与性能调优思路

上面这套代码，跑在普通笔记本上完全没问题。Embedding阶段最耗CPU时间，几百页的文档也就几分钟。7B的量化模型推理，8GB显存或者16GB内存就能跑，回答延迟在几秒内。我实测下来的结果是：检索耗时几乎可以忽略，瓶颈完全在生成阶段。

如果你想把延迟降下来，有几个思路。第一，换更小的模型，比如3B、4B级别的，回答质量会打折扣，但速度快很多。第二，量化等级调低，Q4量化比Q8快。第三，长对话历史要截断，每次只保留最近几轮，否则模型思考时间越来越长。这些是后话，先把系统跑通，再谈优化。

4. 评估效果与优化迭代：别让RAG止步于“能跑”

4.1 为什么传统指标对RAG不够用

代码跑通之后，很多人会问一个问题：效果怎么样？答案不能靠肉眼观察几个问题下结论，需要系统的评估方法。

先说一下常见误区。用“准确率”衡量问答效果？不行，因为答案是开放式文本，没有一个标准字符串可比对。用BLEU或ROUGE这类文本生成指标？在问答场景下参考意义也不大，因为答案的表述千变万化，但底层事实是一致的。正确做法是把RAG评估拆成多个维度：检索质量、生成质量、引用质量、整体回答准确率。

开源社区现在常用的评估框架是RAGAS（RAG Assessment）。它把RAG拆成三个可量化指标：

• Faithfulness（忠实度）：生成内容是否严格基于检索到的资料，有没有超出范围瞎编；
• Answer Relevance（答案相关性）：回答是否切题，有没有答非所问；
• Context Relevance（上下文相关性）：检索到的片段是否与问题相关，有没有抓到一堆无关信息。

这三个指标分别在三个层面告诉你：生成稳不稳、对不对题、检索准不准。我自己的习惯是，先看Context Relevance，因为这个指标低的话后面全白搭。

4.2 三个最常见的问题方向与优化手段

第一类问题是检索不到。表现为：答案说“资料中没有相关内容”，但你知道文档里明明有。排查思路按层级递进：先确认切块有没有把关键内容切碎；再确认Embedding模型对领域术语的语义理解是否到位；再看检索阈值是不是设高了；最后检查是否缺少关键词检索路。一个真实的教训：某场景下用户习惯用产品旧名称提问，文档全部用新名称，向量检索怎么都匹配不上，后来加入同义词扩展才解决。这就是为什么我强调混合检索，关键词匹配在很多边界场景下比语义检索更可靠。

第二类问题是检索到了但没用上。表现为：检索片段里确实有正确答案，但模型回答时没引用。这类问题的根源多在Prompt。你需要把指令写得足够强：“只能基于资料内容回答”“资料中没有的内容不要编造”。还可以在拼接资料时给每个片段标注来源编号，要求模型在回答中引用编号，这样你能追踪它到底用了哪段内容。如果模型无视指令，多半是模型能力不足以应对长指令，换更强模型试试。

第三类问题是上下文被污染。表现为：Top-K个片段中混入大量无关内容，模型被干扰，回答中包含错误信息。解决手段有三个：调低阈值过滤噪音、增强Rerank重排序、减少Top-K数量。优先级从低到高，逐个尝试。另外要注意一个问题：当多个文档片段内容冲突时，模型往往会困惑。理想做法是先做检索结果的聚类或冲突检测，把矛盾内容暴露出来，让用户知道。当前许多系统的做法是简单拼接，效果就是模型两头摇摆，这个可以列为后续优化方向。

4.3 切块策略、Embedding选型和向量库的进阶调优

优化动作落到具体参数上，我整理一份我常用的速查表：

切块这块再展开说一点。如果你面对的是代码仓库文档，根本不适合按固定字符切分，最好按函数定义、类定义作为边界切。如果你面对的是FAQ问答对，每条问答就是一个完整块，不需要重叠。如果你面对的是长报告，小标题和目录是天然的切块锚点。切块永远跟着文档结构走，不是跟字符走。

Embedding模型这块，我的经验是：中文场景别直接用基于英文语料训练的模型，语义距离的度量会失真。BGE中文模型是社区常用的基础选择，往上走还有更大参数量的变体，按数据规模量选。换个Embedding模型时，记得索引要重建，不是换模型就生效的。

向量库这块，Chroma好上手，但如果你要处理百万级以上向量，可能要换更专业的引擎。中间还涉及索引算法，比如HNSW（分层小世界图）和IVF（倒排文件），不展开讲了，记住一点就行：索引参数（如M值、efConstruction）影响查询速度与准确率的平衡，默认参数就够先撑一阵子。

4.4 一个完整的评估样例与调优案例

举一个我自己的真实例子作为参考。某项目知识库是上百页的产品技术白皮书，最初跑出来的效果是：用户问“并发连接数上限是多少”，系统答非所问，引用了一段存储架构描述，相关信息确实存在但检索定位错了。

排查路径是这样的：先查Context Relevance，发现检索回来的5个片段里只有1个沾边，其他4个全是存储架构的铺垫内容。再查原始文档，发现“并发连接数”这个名词只出现在第87页的一个表格旁，前后段落都是容量规划。切开后的块是典型的“语义混合块”，容量规划与并发限制混在一起，Embedding距离被带偏。

当时的优化手段：第一，把切块大小从512降到384，降低混合语义的概率。第二，把表格行做了结构化提取，每行转成独立的纯文本块，这样“并发连接数：最大1024”成为独立可检索的单元。第三，加了一路关键词检索，对数字规格类查询有奇效。优化后，这个问题的检索命中率明显上升，回答也准确了。核心心得就一句话：先定位是“检索不到”还是“检索不准”，再动手调参数。凭感觉乱调参，是浪费时间又误导结果。

5. 常见问题与排坑思路，都是真金白银换来的

5.1 环境与依赖相关的高频故障

按照上面这套流程走，环境这块的坑不算多，但有几个高发的，值得提前避开。

第一个是Chroma的版本兼容问题。如果你在装完依赖后执行代码报ModuleNotFoundError，多半是版本冲突。解决方法是锁定依赖版本，LangChain不同大版本之间API变动非常频繁，from langchain_community和from langchain的导入路径在版本切换时经常变化。由于我的代码是基于较新的写法，建议优先安装最新稳定版。

第二个是Embedding模型下载失败。HuggingFace模型首次加载要联网下载权重，网络环境不佳时经常超时。解决办法是把模型下载到本地指定目录，之后离线加载。代码改成：

# 从本地目录加载Embedding模型 embedding_model = HuggingFaceEmbeddings( model_name="/path/to/local/bge-small-zh-v1.5", model_kwargs={"device": "cpu"}, )

第三个是Ollama服务连不上。代码报连接错误，先确认服务是否启动了。终端执行ollama serve，另开一个终端跑ollama list，确认模型已拉取。别忘了Ollama的Windows版开机自启偶尔失效，连接报错时第一反应是服务没起。

5.2 检索质量相关的棘手疑难

这类问题在RAG项目里占大头，我按“症状”来分类，便于你对号入座。

症状一：相似度分数普遍偏高或偏低。如果你打印相似度分数发现全是0.6以上或者全是0.1以下，不要急着调阈值，先看看Embedding模型输出向量有没有做归一化。前面我提过normalize_embeddings=False，如果模型输出的是原始向量而向量库计算时用了归一化，距离分布会异常。统一设置，问题自然消除。

症状二：检索结果里总是混入大量无关片段。这通常说明文档里有很多高频重复的名词，比如“系统”“平台”这类词，把每个块都拉高了相似度。我试过的有效手段是走TextRank提取关键句，或者做一次基于规则的关键词过滤，把包含明确术语的片段权重拉高。混合检索的额外一路通常也能改善。

症状三：相似问题返回不同答案。用户换个说法问同一个问题，结果答案不一致。原因多半是检索到的片段排序变了，Top-K相同但顺序不同，模型对顺序敏感。解决办法是检索结果按确定性的排序规则处理，甚至在Prompt里明确“按资料顺序组织答案”。对于生产环境，这个问题直接关联用户信任度。

5.3 关于“多轮对话”和“多文档”两个进阶议题

基础的单轮问答跑通后，你几乎马上会遇到两个进阶需求。

第一个是多轮对话。用户问了“产品的序列号在哪看”，接着问“那授权码呢？”——后者没有上下文时，检索器根本不知道该搜什么。解决方案是引入对话改写模块：把“那授权码呢”结合上一轮上下文改写为“产品授权码在哪查看”，再进入检索管道。实现方式可以是一个规则引擎，也可以直接用一个小模型做改写，两者我都试过，规则引擎简单但覆盖不全，小模型效果好但增加延迟，实践时按需求取舍。

第二个是多文档问答。知识库里有产品手册、FAQ、操作指南，还有往期工单记录。这些文档的风格和用途差异很大，直接把所有内容塞进同一个向量库，检索时经常串味。我的做法是给每个文档打标签，在索引时把元数据（如文档类型、更新时间、适用范围）存进Chroma的metadata字段，检索时先按条件过滤，比如只在FAQ和操作指南范围内搜，工单记录只在特定场景才参与召回。这个“按元数据过滤”的思路，在多知识库条件下价值非常大，可以大幅提升检索准确率。

5.4 性能与成本控制：从单机到生产的一些忖量

最后聊一聊从个人项目到生产环境，还有哪些坑在等着你。

单机版最明显的瓶颈是并发。你的Ollama模型默认串行处理请求，两个人同时问问题，后面的人就得排队等待。应对思路有这样几个：上GPU、换提供并发处理的服务部署方式、给用户侧做限流和排队提示。如果只是个人学习项目，不用在这个环节太较真。

向量库的规模上来后，检索延迟也会跟着涨。Chroma在几十万量级内表现尚可，再往上就建议做“分区检索”：按业务领域分多个collection，先路由到对应collection，再在其中检索。这比在一个大库里全局搜索快得多，而且结果更准。

成本这块，最大的不是代码运行开销，而是Embedding的调用成本。如果你用的是云端Embedding接口，每次上传文档和每次用户提问都要计费，一万条文档的向量化费用，累计起来不算小数目。本地化部署模型虽然前期要花点时间配置，但长期来看成本优势非常明显。

写到最后的一点体会

整个RAG学习下来，我最深的感受是：RAG不是一个模型，而是一套系统。嵌入模型、切块策略、向量库、检索逻辑、Prompt模板、生成参数，任何一环都能决定最终效果。同一个知识库，换一种切块方式，结果可能天差地别。学RAG时如果能花时间把每一环都亲手调一遍，比看多少篇文章都有价值。

还有个小技巧，值得放在最后分享：给RAG系统做测试时，不要只看“答对了没有”，要把每次检索到的片段打印出来看。答案错了，往往不是模型不会答，而是它根本没找到该看的内容。这个习惯帮我解决了大量诡异问题，也推荐你试试。