企业官网建设流程全解析

RAG这个缩写，这几年的实际项目里已经快被说滥了。它的全称叫检索增强生成，说白了就是在大模型出结果之前，先从一个外部知识库里把相关材料捞出来，再把材料和大模型的生成能力拼在一起。如果你正在做一个需要回答私有知识库问题的产品，或者想让模型更少胡编乱造，那RAG基本上是你绕不开的一条路。这篇概览，我从实际问题、整体流程、检索质量、代码实现、生产排障这几个角度，把我这几轮项目里沉淀下来的东西完整写一遍。适合正准备在系统里引入RAG、或者已经被检索质量折磨了一阵子的开发者参考。

1. 为什么需要RAG：大模型落地的那道坎

1.1 大模型的天生短板

不管底层模型能力多强，它本质上就是一个“靠训练数据喂出来的概率系统”。你问它一个训练数据里没有的细节，它只能硬编一个看着合理的答案，这是幻觉的来源之一。另一个问题是知识时效性：模型训练完之后，新发生的事情它一概不知道。如果企业内部知识库每个月都在更新，纯靠模型回答，结果就等于一本永远不更新的百科全书。

有人会想，那我每隔一段时间把模型重新训练一遍不就行了？现实是，重训一个大模型的成本高到绝大多数团队承受不了。而RAG的思路完全是另一个方向：把模型当作“推理引擎”，把知识放在外部存储里，用的时候临时去取。这相当于给模型配了一个实时更新的资料库，不再指望它把全世界都记在脑子里。

1.2 RAG与微调的本质定位

微调是对模型参数本身做手术，让模型学会某种风格、某种输出格式，或者某个特定领域的表达习惯。它适合“改变模型的说话方式”，不适合“补充某个具体事实”。比如你想让模型的回答从严谨工程师风格变成一个亲和客服风格，微调是合适的。但如果你想让模型准确记住上个月刚发布的设备规格参数，就算微调完，它也可能把型号和参数记串了。

RAG则把“事实记忆”这件事从模型身上剥离了。宏观上看，它是一个由三块组成的系统：先把知识切块、向量化、存起来；问题来的时候从库里检索出最相关的几段；把这些片段拼进提示词，让模型基于这些内容做总结和推理。这样模型不再靠猜回答，而是靠引用回答。我在实际项目里见过一个很典型的案例，同一套模型，没接RAG之前在私有领域问题上大概有六成答案掺了胡编的内容，接上RAG之后错误率立刻降到很低。要注意，也不是说RAG和微调二选一，生产环境里两者经常组合着用：RAG管事实，微调管风格。

2. 高屋建瓴：RAG的整体流程与组件拆解

2.1 离线准备：文档接入与索引构建

这里说的离线，是指用户真正提问之前需要做好的准备工作。首先是文档接入，你手里的材料可能是PDF、Word、Markdown、HTML，甚至是一堆数据库记录。接入过后就得考虑切块，这一步比大多数人想像的更重要。

为什么要切块？因为大模型输入长度有限，而且检索返回的单元要足够聚拢。如果把几百页的PDF当一整块塞进去，语义被稀释得太厉害，召回质量会直线下降。反过来，切得太碎，一块只有几十个字，检索回来的片段里缺乏上下文，生成端也难拼出完整答案。这个尺寸的取舍，我一般建议从256到1024个token之间起步，具体要看文档类型和问答粒度。

索引构建最后一步是向量化存储。把每个文本块用嵌入模型映射成高维向量，存进向量数据库。这里有两个关键点：一是嵌入模型的选择会直接影响检索效果的边界，二是向量数据库需要支持后续的元数据过滤和混合检索，不能只看向量远近。

2.2 在线推理：检索与生成的衔接

在线阶段，用户的query来了，要干的事情是：把query用同一套嵌入模型转成向量，在库里做相似度搜索，捞回top-K个文本块，然后把这些文本块和原始问题一起塞给生成模型。

这里有一个容易被忽视的细节：query的向量化和文档切块的向量化，必须使用同一个嵌入模型。很多人前期测试效果不错，后面换了接入模型忘了同步更新文档向量，导致两边向量空间不一致，检索结果会变得莫名其妙。我在项目里就踩过这个坑，升级了嵌入模型但没重新向量化全部文档，结果检索相关性当场崩了一半。

检索和生成之间的衔接还有一层：prompt构造。不是把检索到的段落直接堆在后面就完事。我推荐的稳定策略是，先给模型一个角色设定，再明确告诉它“以下是从知识库检索到的资料，如果有用就基于资料回答，如果没有相关资料就直接说明不知道，不要自行编造”。这一句“不要自行编造”在实测里非常管用，能把幻觉概率压下去不少。

3. 决定检索质量的关键细节

3.1 分块：尺寸、重叠与边界

分块策略几乎是所有RAG项目前期最容易反复改动的地方。我在实践里总结了一套自己的判断方法。

• 面向段落分。优先按文档的固有结构切，比如Markdown的一级目录、二级目录，PDF里的小节，天然语义边界最可靠。
• 设置重叠窗口。切掉的地方往往正好把一句话拦腰截断，导致检索时语义不完整。我一般在切块时设置50到100个字符的重叠，让前后块都保留一部分上下文。
• 按token数而不是字符数控制尺寸。中文和英文在字符维度上不对等，按token切才能保证嵌入模型处理的单元一致。举个实际例子：我之前处理一批中文操作手册，按字符串800字切，结果一条嵌入请求经常超长被截断；改成按300个token切之后，截断问题基本消失。

分块边界上还有一个小技巧：如果文档里带有表格、代码块，尽量单独划出去切。表格被拦腰切开，嵌入后的语义往往丢失严重。代码块按函数或段块切，比按固定长度切要实用得多。

3.2 嵌入模型与向量数据库的选型

嵌入模型决定了“语义相似”的上限。我经常打一个比方：向量数据库只负责比距离，但“距离近代表相关”这个假设成不成立，全看嵌入模型好不好使。

选嵌入模型时，我重点看三个指标：一是该模型在中文、英文或你的业务领域数据上的检索评测表现，二是向量维度带来的存储和计算成本，三是它对文档长度的支持上限。很多文档一长，嵌入模型会把尾部信息丢掉，直接影响召回。如果文档普遍较长，要么换支持更长上下文的嵌入模型，要么强制分块尺寸不超过它的上限。

向量数据库这边，不同产品之间的核心差异在于：能否原生支持向量+标量过滤的混合查询，能否承受更新和删除索引时的压力，高并发下查询延迟稳定不稳定。轻量场景和重量级生产场景要选不同取向的东西。我自己的经验是，一开始不要花时间纠结数据库的品牌，先用一个方案把链路跑通，重点观察索引构建时间和查询延迟两个数值。等检索质量调得差不多了，再回头考虑迁移或者扩展都来得及。

3.3 混合检索与重排序

纯向量检索最大的问题是，它对精确词匹配不敏感。比如用户问“工资怎么算”，而文档里写的是“薪酬计算规则”，语义可能解得了；但如果用户问“Android 14 的更新日志”，文档里全是关于“安卓 14”的表述，向量检索的效果就因训练数据而异了。这时候需要混合检索。

混合检索是把向量检索和传统关键词检索的结果并在一起，再做合并排名。关键词检索能吃住精确匹配，向量检索能理解同义改写，两者结合后覆盖度明显提升。合并排名最简单的方案是加权融合，比如给向量得分70%权重，给关键词得分30%，但这个比例是玄学，得用自己的测试集调。更稳的方法是再加一个重排序模型，把两路召回的结果统一交给重排序模型重新打分，取前几名。重排序的代价是增加了一点延迟，但换来的是最终进入prompt的片段质量高很多。

我实际做过一次对比：纯向量检索top5正确命中2个；加了关键词混合检索后命中3个；再加重排模型后命中4个。这个提升在问答效果上是肉眼可见的。

4. 用代码走通一个最小可用RAG流程

4.1 环境准备与技术栈选择

这里我用伪代码演示核心流程，你不用死抠某个依赖库的名字，只要把思路迁移到你已有的技术栈里就行。通常一个RAG原型需要这几件东西：文档加载器、文本分块器、嵌入模型、向量存储、大模型接口。

# 伪代码：以最小依赖展示RAG的骨架结构 # 实际实现时请替换为你自己的模块和服务 from your_loader import load_pdf, load_markdown from your_splitter import markdown_splitter, token_size_splitter from your_embedding import embed_texts, embed_query from your_vectorstore import VectorStore from your_llm import chat_complete from your_reranker import rerank # 可选 documents = load_pdf("manual.pdf") chunks = [] for doc in documents: for sec in markdown_splitter(doc): if len(sec) > 300: for sub in token_size_splitter(sec, size=300, overlap=30): chunks.append(sub) else: chunks.append(sec)

这段代码里值得解释的是分块逻辑。我先把文档按markdown结构切到二级目录，再把超过300个token的大块二次切分，并设置30个token的重叠。这样结构性强的部分不会被拆散，而超长的部分也能控制尺寸。实测下来，这种“结构优先、长度兜底”的策略，比单一用固定长度切分要稳。

4.2 索引构建：从文本到可检索的向量

索引构建的核心就是遍历切块，调嵌入接口拿到向量，再写入向量存储。这一步看似简单，真正要注意的是异常处理和增量更新。

vector_store = VectorStore() metadata_attr = ["source", "page", "section"] for idx, chunk in enumerate(chunks): try: vec = embed_texts([chunk])[0] vector_store.add( id=f"chunk_{idx}", vector=vec, text=chunk, metadata={ "source": "manual.pdf", "page": chunk.page, "section": chunk.section, }, ) except Exception as e: # 不要因为单条失败导致全量重建中断 log_failed_chunk(chunk, e)

生产环境里，我给每条记录保留了来源、页码、章节三个元数据字段。它们看起来不起眼，但在后面排查“为什么检索到这条内容”时，几乎是唯一的线索。而且有了页码，生成端可以顺带返回引用来源，让用户能点回原文核验。这个功能在企业内部知识库场景里价值极高，能显著提升信任度。

增量更新同样重要。文档库不是静态的，每天可能都有新增。我用一个简单策略：记录每个文档的处理摘要，文档内容变化时只对变化部分重新切块、向量化。全量重建听着简单，但文档一上十万级，成本和时间都很吓人。

4.3 检索与生成：让答案有据可依

在线检索时，先把用户query向量化，再从向量存储里取两类结果：向量相似度top结果和关键词匹配结果。合并去重后再考虑是否重排，最后把最相关的几个片段塞进prompt。

def answer_with_rag(query: str) -> str: # 1. query嵌入 q_vec = embed_query(query) # 2. 双路召回 vector_top = vector_store.search(q_vec, top_k=10) keyword_top = vector_store.search_keyword(query, top_k=10) # 3. 合并去重 merged = merge_by_id(vector_top, keyword_top) # 4. 可选重排 reranked = rerank(query, merged, top_n=3) if use_reranker else merged[:3] # 5. 构建提示词 context_blocks = "\n\n".join( f"[片段{i+1} from {item.metadata['source']} 第{item.metadata['page']}页]\n{item.text}" for i, item in enumerate(reranked) ) prompt = f"""请根据下面提供的资料回答问题。 如果资料里没有相关信息，请直接说明“知识库中未找到”，不要编造。 资料： {context_blocks} 问题：{query} 答案：""" # 6. 生成 reply = chat_complete(prompt) return reply

这里我给每个片段加上了来源标注，不只是为了格式好看。实测里，加上“来源+页码”之后，模型会更倾向于把答案绑定在资料表述上，胡编的概率肉眼可见地下降。这算是prompt工程里一个低成本高收益的技巧。

另一个细节是top_k的取值。top_k太小容易漏，太大则会把不相关内容塞进上下文，反而干扰生成。我先用10召回再精排到3，是一个相对稳的组合。如果你的场景问题很具体，精排到1或2也可以，但问题偏开放的时候，3个片段上下文会更够用。

4.4 关键参数调优思路

跑通上面这套骨架不难，难的是参数调优。我把最常见的调节点整理出来给个方向。

• 分块尺寸：偏大适合长文总结类型，偏小适合抽取具体事实。以300到512个token为起点，用你自己的问题集测试。
• 召回数量top_k：偏大提升召回率但干扰生成，偏小降低延迟但容易漏。配合重排模型时，召回可以放到10，最终精排取3。
• 混合检索权重：向量和关键词的配比取决于语料。语料里专有名词多，关键词权重可以提高；语料以自然语言描述为主，向量权重可以提高。
• 重排是否启用：延迟敏感场景可以先不开。对回答质量要求高、尤其答案要严谨的场景，强烈建议开启。

这些参数没有普适最优解，都是在你自己的数据上测出来的。我一般会准备几十条典型问题，把答案质量做人工打标，然后针对性地调参数。每调一次，跑一遍测试集，比凭感觉调要靠谱得多。

5. 生产环境常见问题与排查思路

5.1 检索结果与问题无关

这是RAG项目里最常遇到的故障。很多人第一反应是“向量数据库有问题”，但实测下来，排在前面的是分块不合理、嵌入模型不合适、query表达方式太差。

排查路径我按顺序列出来：

1. 看检索到的片段本身，人工判断是不是相关。如果不相关，先用关键词检索试一遍，确认文档里确实存在相关内容。
2. 如果关键词能命中但向量检索不出来，大概率是嵌入模型对你这领域的专业词汇理解不够。
3. 如果向量检索能命中但排在后面的内容不适合当答案，多半是分块结构太碎，关键信息被拆散到多个块里了。
4. 检查用户query是否有口语化缩写。比如全称和缩写混用，建议在query入口做一个术语归一化步骤。

我印象很深的一个case：某次排查发现“芯片封装”永远检索不到，但文档里大段大段都在讲封装工艺。后来发现嵌入模型把“封装”这个词理解偏了。换成在检索层加一个同义词扩展之后，问题立刻解决。

5.2 生成内容仍然出现幻觉

检索到了正确片段，模型却答非所问，甚至编出新信息，一般有四个原因。

第一，prompt约束不够硬。我见过不少直接把片段拼到“以下为参考资料”后面的prompt，模型参考得并不严格。必须在prompt里写明“只能依据资料回答，资料不足时承认不知道”。

第二，片段顺序和上下文拼接方式不对。模型对整块拼接的信息源边界感不强，容易把不同片段里的信息混在一起推断。给每个片段标上序号和来源，并在prompt里说明它们可能来自不同文档，可以减少这类混搭幻觉。

第三，top_k太多，模型被不相关内容带偏。有一次我为了“召回全”把top_k调到了10，结果模型在生成时参考了某个不相关的片段，编出了一个看似合理但完全错误的答案。

第四，生成温度设置过高。温度高适合创意写作，不适合知识问答。把温度调到0到0.3之间，回答会更倾向于贴着资料走。

5.3 延迟和成本问题

RAG在线链路的延迟大头通常在两个地方：检索和生成。检索延迟主要来自向量数据库查询、混合检索合并、重排模型推理。生成延迟来自输入token变长，因为多了一堆检索片段进去。

我的优化经验是：

• 向量检索加索引加速，这是最基本的。
• 混合检索的关键词部分用轻量索引，不要让它变成性能瓶颈。
• 重排模型选择参数量小、推理快的版本，或者只在问题敏感度高的场景启用。
• prompt里的检索片段不要无脑塞满。精排到2到3个片段，生成质量和延迟能取得一个不错的平衡。
• 给相似度得分设一个阈值，低于阈值的片段宁可不用，也不要硬塞。省token也降噪音。

成本方面，可以加一层结果缓存。两个用户问同样的问题，或者高度相似的问题，直接复用结果。缓存命中率上去之后，成本降得非常明显。

5.4 怎么科学评估一套RAG系统

“感觉效果还行”是很多RAG项目初期的评价方式，但到了要上线的时候，必须有可量化的指标。我自己的做法是构建一个评估问题集，每个问题带上标准答案或至少带上“应该出现在哪些文档”的标注。

评估维度分两层：

• 检索层：看召回率。也就是标准答案相关的片段，有没有被检索到。指标可以用命中率或者MRR。
• 生成层：看答案质量。可以用LLM打分，也可以人工打标。打分维度至少包括：有用性、忠实度、相关性。

这里重点说“忠实度”，它指的是生成的答案有没有依据检索到的资料。一个只相关的答案但没有忠实于资料，说明prompt约束或参数可能有问题。我在评估里发现一个很有意思的现象：检索质量明明还不错，但答案忠实度低，最后查下来是生成温度太高，把模型从“摘录资料”带到了“自由发挥”。

6. 一点亲身实操体会

做过几轮RAG项目之后，我的最大感悟是：大部分早期失望都来自把RAG想得太简单，以为“文档塞进去就能答”，实际效果却是检索质量、prompt设计、参数设置、问题改写每一环都得伺候到位。

我自己保留的固定动作有三个。

第一，先建立评估集，再调系统。没有评估集就动手调参，等于闭眼开车。哪怕评估集只有三十条问题，也能让后续改动有对照。

第二，原始文档的预处理远比想象中的值钱。清理水印、把表格转成结构化文本、统一编码格式、去除页眉页脚，这些杂活做好之后，检索质量能明显上一个台阶。

第三，给RAG加一个“问题改写”的预处理层。用户提问往往很短很口语，比如“这个怎么弄”，直接检索效果很差。我一般先用一个轻量模型把问题改写成适合检索的完整句式，再进去做检索，收益非常稳定。

如果你正准备搭一套RAG，我的建议是先不纠结复杂架构，老老实实把最小闭环跑通：加载、分块、嵌入、检索、生成。跑通之后，用评估集看看短板在哪，再针对性补检索质量或者优化prompt。这一轮一轮调下来，你会发现RAG其实是个越调越顺的系统，调参带来的收益也远比换个更大的模型要明显。

最后再分享一个小技巧：日志里一定要记录每次用户query检索到的片段ID和最终答案，隔一段时间回头复盘。这些日志不仅用于排障，还是你优化分块策略和评估集最重要的数据来源。我见过太多团队上线后不盯日志，等到投诉来了才发现检索早就歪了。把这层日志盯住，你的RAG系统稳定性会比大多数团队高一个档次。