企业官网建设流程全解析

• 教程
• 文档

本文基于 Datawhale 开源项目 easy-vibe 的 RAG 原理文档，系统讲解检索增强生成（Retrieval-Augmented Generation）的核心思想、三阶段工作流程、文本分块与检索技术选型、架构演进路线以及 RAG 与微调的取舍。读完本文，你将掌握 RAG 从原理到落地的完整知识框架，并能结合项目仓库中的配套教程（RAG 入门教程、Embedding 与向量检索原理）完成从"能回答问题"到"稳定、可控、可追溯地回答问题"的进阶。

0. 全景图：大模型为什么需要"查资料"

想象你是一位博学的教授，读过无数书籍。但如果有人问你"昨天公司的销售数据是多少"，你肯定答不上来——因为这些信息不在你读过的书里。大语言模型面临的就是同样的困境：

• 知识有截止日期：大模型的训练数据截止到某个时间点，之后发生的事它不知道；
• 缺乏私有知识：你公司的内部文档、产品手册、客户数据，模型从未见过；
• 容易产生幻觉：当模型不确定答案时，它倾向于"编造"一个看起来合理的回答。

RAG 的解决方案非常直观：在让模型回答之前，先帮它找到相关的参考资料。就像开卷考试——你不需要记住所有知识，只需要知道去哪里找、怎么找。

RAG = 检索（Retrieval）+ 增强（Augmented）+ 生成（Generation）

下面这张示意图直观对比了"无 RAG"与"有 RAG"的差别：同样的用户问题，无 RAG 时模型因缺乏外部知识只能给出模糊回应；有 RAG 时，系统先完成文档索引、检索相关片段，再把"问题 + 证据"组合成 Prompt 交给 LLM，从而生成有依据的回答。

更进一步看，单纯"把资料塞进长上下文"也不是企业级答案。在 RAG 入门教程 中明确指出，"能给出一个回答"和"在真实业务环境中持续、稳定、可控地给出正确答案"是两件完全不同的事，长上下文方案至少会暴露三类典型问题：

1. 成本与效率问题：推理成本与上下文长度强正相关，8K Token 与 200K Token 的价格、延迟完全不在一个量级；且绝大多数任务仅需少量高相关信息，把全量文档塞入上下文会造成严重的算力浪费；
2. 注意力与聚焦问题：上下文超过一定阈值后，模型出现"注意力衰减"（更依赖后端文本、忽略前端关键信息）和"信息干扰"（被无关、重复甚至冲突的信息带偏）；
3. 知识更新与可控性问题：知识变更时重新训练或微调投入高、周期长；且从"黑盒化的参数"中难以定位回答依据，合规审计与风控解释面临困难。

从企业需求出发，RAG 主要解决时效性（直接读取最新制度文件与业务库）、专业性（基于权威资料作答）、幻觉问题（要求回答尽量基于检索片段并给出出处）、可解释与可审计（每条回答可回溯到具体条款与案例）、算力成本与资源效率（按需检索，知识存放在外部向量库）五类现实问题。

1. RAG 基础流程：索引、检索、生成

RAG 的工作流程可以分为两个阶段：离线索引和在线查询。离线阶段就像图书馆的编目工作——把所有书籍分类、编号、上架，方便日后查找；在线阶段则是读者来图书馆查资料的过程——根据问题找到相关书籍，然后综合信息给出回答。

三个核心阶段：

1. 索引阶段（Indexing）：将原始文档加载、清洗、分块，然后通过嵌入模型转化为向量，存入向量数据库。这是一次性的准备工作；
2. 检索阶段（Retrieval）：用户提问时，将问题也转化为向量，在向量数据库中搜索最相似的文档片段；
3. 生成阶段（Generation）：将检索到的文档片段和用户问题一起拼接为 Prompt，交给大模型生成最终回答。

在 RAG 入门教程 中，用"苹果知识库"案例完整演示了这一闭环：知识库含三个片段——苹果公司 1976 年创立（公司）、苹果是富含维生素 C 的水果（水果）、2007 年推出 iPhone（公司）。当用户问"苹果公司是什么时候创立的"，系统将问题向量化后与知识库中所有文档向量计算余弦相似度（与文档 A 相似度 0.97、与文档 C 相似度 0.88、与文档 B 相似度 0.12），按 Top-K（K=2）召回最相关的两个片段，再拼入如下结构化 Prompt 交给 LLM：

【系统指令 (System Prompt)】 你是一个专业的问答助手。请严格根据用户提供的"参考信息"来回答问题。 如果参考信息中包含问题答案，请直接基于该信息进行回答。 如果参考信息中不包含问题答案，请明确告知用户"根据现有资料无法回答该问题"，切勿自行编造信息。 请在回答中注明依据的信息点。 【参考信息 (Retrieved Context)】 苹果公司于1976年4月1日由史蒂夫·乔布斯、史蒂夫·沃兹尼亚克和罗纳德·韦恩创立，总部位于加利福尼亚州库比蒂诺。 苹果公司在2007年推出了第一款iPhone，彻底改变了智能手机行业。 【用户问题 (User Query)】 苹果公司是什么时候创立的？

LLM 遵循系统指令，将"参考信息"视为唯一可信来源作答："根据提供的参考信息，苹果公司于 1976 年 4 月 1 日创立。【依据：信息1】"。当用户问与知识库无关的问题（如"今天天气怎么样"）时，检索相似度普遍极低（均低于 0.2），实际系统常结合"最低相似度阈值"直接返回空召回，模型则会明确回答"根据现有资料无法回答"，从机制上抑制了幻觉。这种"系统指令设定角色与规则 + 检索证据提供作答素材 + 用户问题明确任务目标"的结构化输入，正是 RAG 引导大模型输出稳定、可靠答案的关键。

2. 文本分块：把大象装进冰箱

文本分块是 RAG 中最容易被忽视、却对效果影响最大的环节。为什么需要分块？因为大模型的上下文窗口有限，我们不可能把整本书塞进去。更重要的是，分块的质量直接决定了检索的质量——如果整本书是一个"块"，检索到了也没用，你还是得翻遍全书；如果按章节甚至段落分块，就能精准定位到你需要的内容。

分块策略的选择：

• 固定大小分块：按字符数或 token 数切分，简单粗暴但可能切断语义；
• 递归分块：先按段落分，段落太长再按句子分，保持语义完整性；
• 语义分块：用嵌入模型判断语义边界，相似度突变处切分；
• 文档结构分块：利用 Markdown 标题、HTML 标签等结构信息分块。

没有"最好"的分块策略，只有最适合你数据的策略。一般建议从递归分块开始，chunk 大小 200-500 tokens，overlap（重叠）10%-20%。

分块效果可以量化验证。在 RAG 入门教程 的"Late Chunking"一节中给出了一个典型反例：一份 200 页的保险合同里，"免赔额"定义在第 5 页、具体适用条件在第 30 页，传统固定长度切分（如每 512 tokens 一块）会把相关信息分散到 40 多个独立文本块，实验数据显示这种割裂会导致语义相似度从 0.85 暴跌至 0.71。而"先编后切"的 Late Chunking（先用支持 8192 tokens 的长上下文嵌入模型生成每个 token 的向量，再按块做平均池化）能让块向量携带跨段落的指代关系，使相似度从 0.71 提升至 0.83。这印证了一个规律：文档长度与分块策略的收益呈正相关。

3. 检索技术：找到最相关的内容

分块完成后，下一个关键问题是：用户提了一个问题，怎么从成千上万个文档片段中找到最相关的那几个？这就像在一个巨大的图书馆里找书——你可以按书名关键词搜索（关键词检索），也可以描述你想要的内容让图书管理员帮你找（语义检索），最好的方式是两者结合（混合检索）。

重排序（Reranking）：检索到候选文档后，通常还需要一步"重排序"。初始检索追求召回率（尽量不遗漏），重排序追求精确率（把最相关的排到最前面）。常用重排序模型有 Cohere Rerank、BGE Reranker 等，它们使用交叉编码器对 query-document 对进行精细打分。

向量检索的底层机制可以进一步参考仓库中的 Embedding 与向量检索原理：嵌入模型把文本映射为稠密、低维的语义向量（典型维度 768-1536），语义相近的文本在向量空间中彼此靠近；衡量相似度首选余弦相似度（比较方向、不受向量模长影响，取值范围 [-1, 1]），也可用欧氏距离（衡量端点直线距离）。当向量规模达到百万级时，逐一暴力比对（Flat）已不可行，需要通过 ANN 近似最近邻索引加速——IVF 先把向量空间聚类分桶、查询时只搜邻近桶；HNSW 构建多层可导航小世界图、从粗到细逐层定位；PQ 则把高维向量压缩成短码以换取内存节省。向量数据库（如 Pinecone、Milvus、Chroma、FAISS）正是为这种"存储高维向量 + 毫秒级相似度检索"场景而生的存储引擎。

4. 架构演进：从简单到智能

RAG 技术在短短两年内经历了三代演进，每一代都在解决上一代的痛点。

三代 RAG 架构对比：

• Naive RAG（2023）：最基础的"索引 → 检索 → 生成"流程，实现简单但效果有限。问题包括：检索质量不稳定、无法处理复杂查询、容易引入噪音上下文；
• Advanced RAG（2024）：在 Naive RAG 基础上增加了查询改写、混合检索、重排序、上下文压缩等优化环节，显著提升检索精度和生成质量；
• Modular RAG（2025）：将 RAG 拆解为可插拔的模块，支持路由判断、自适应检索、自我反思等高级能力，可根据查询类型动态选择最优处理流程。

从技术起源看，RAG 并非诞生于大模型时代：RAG 入门教程 追溯了 2017 年 DrQA 框架首次将检索机制与语言模型结合、2020 年 Dense Passage Retrieval（DPR）用神经网络取代 TF-IDF/BM25 词频检索、2021 年 RAG 被正式提出并系统化的发展脉络。

Naive RAG的典型流程是"三步走"：文档预处理与索引（固定长度切分 + 嵌入向量化 + 写入向量库）→ 基于相似度的 Top-K 检索 → 简单拼接后增强生成。它的价值在于以极低门槛验证了"先查再答"确实有效，但局限同样明显：分块策略粗糙（容易截断语义段落）、检索信号单一（只依赖向量相似度）、检索结果几乎不过滤（噪音、重复、矛盾的片段原样塞进上下文）。

Advanced RAG在检索前与检索后两端做系统化精细化优化：

• 检索前（Pre-Retrieval）：索引端从固定长度切分演进到语义感知分块与分层索引（按章节、段落、句子边界切分，辅以滑动窗口和多粒度索引），并为每个文档块附加来源、时间、作者、主题等元数据；查询端对原始问题进行重写、扩展与拆分，常见手段包括：
  • Query Rewrite（查询重写）：把"咋查明天北京的天气啊"这种口语化问题规范化为"查询北京市明日全天实时天气"；
  • Multi-Query（多路查询）：围绕"如何给刚满月的宝宝拍嗝"生成"新生儿拍嗝的正确姿势""满月宝宝拍嗝避免吐奶的方法"等多个角度不同的查询，避免单一查询遗漏；
  • Sub-Query（子问题分解）：把"北京到上海的高铁，明天有哪些班次？票价多少？需要坐多久？"拆分为聚焦班次、票价、时长的独立子查询；
  • Step-back Prompting（回溯提示）：先生成更宏观的上位问题（如"影响新能源汽车品牌短期销量波动的核心因素有哪些"），再据此推导具体检索方向。
• 检索后（Post-Retrieval）：用专门的 Rerank 模型或 LLM 对候选文档二次排序；对检索结果做筛选、去重与压缩；必要时结合轻量模型微调，使 LLM 更倾向于依据检索证据作答并附带引用出处。

Modular RAG不再是一条固定流水线，而是由一组可插拔、可替换、可组合的功能模块组成，通过编排逻辑按需组合。典型模块包括：

1. 查询理解与路由模块：意图识别、问题重写、子任务拆解和路径选择——"这条错误日志代表什么问题？"路由到代码与日志知识库，"最近该行业的监管新规有哪些变化？"走互联网搜索或法规库；
2. 多源检索与融合模块：同时连接向量库、全文检索、结构化数据库与知识图谱，把多源结果合并为有序证据集；
3. 记忆与个性化模块：维护长期用户画像、短期会话记忆和领域知识缓存，让系统在长期交互中积累历史信息；
4. 任务适配与治理模块：面向不同任务加载适配器，约束输出格式、语气、风格，并结合事实核查、风险过滤和引用对齐对生成结果进行治理。

Modular RAG 还打破了"一轮检索 + 一轮生成"的单一流程：生成过程中发现信息不足时可以主动触发新的检索轮次，甚至多次往返；模型还能学习自我决策——把握较大的问题直接作答，不确定时才发起检索或调用外部工具，从而在保证质量的前提下节约资源。

5. RAG vs 微调：该选哪个

当你想让大模型掌握特定领域的知识时，通常有两条路：RAG 和微调（Fine-tuning）。它们不是互斥的，而是互补的。打个比方：微调像是让学生上培训班，把知识内化到大脑里；RAG 像是给学生发参考书，考试时可以翻阅。

实践建议：大多数场景下，先试 RAG。RAG 的优势在于不需要训练、知识可实时更新、回答可追溯来源。只有当你需要改变模型的"行为模式"（比如输出格式、语言风格、推理方式）时，才考虑微调。最强的方案往往是RAG + 微调的组合。关于微调的技术细节，可以进一步阅读仓库中的 模型微调与部署 一文。

6. 从 Demo 到企业级：模型选型与效果评测

把 RAG 从 Demo 推向企业级生产，需要在前文原理之外补齐三块拼图：模型选型、运行框架与效果评测。这在 RAG 入门教程 中有系统论述，这里提炼关键决策点。

模型选型：一个完整的企业级 RAG 系统涉及三类核心模型，各司其职。

• Embedding 模型决定召回阶段质量。选型可参考 MTEB（大规模文本嵌入评测基准，覆盖 8 大类任务、56 个数据集）作为统一评估框架，同时重点关注两个直接影响 RAG 性能的参数：维度（维度越高语义刻画越精细，适合医疗、法律等专业检索；维度越低计算与存储成本越小、检索越快，适合千万级文档的高并发场景）和上下文长度（处理短文本选 512-1024 token 即可，处理论文、报告等长文本需选 2048 token 以上，避免信息截断）。常见选项包括 OpenAI text-embedding-3、Jina Embeddings v2、BGE 系列、Qwen2-Embedding 系列等，可结合成本与实测效果选择；
• Rerank 模型对初步召回结果精排打分。可参考面向 RAG 场景的 Reranker 排行榜，评估时同时关注排序质量（如 nDCG@5/10 衡量"排得准"、Recall@5/10 衡量"找得全"）与推理延迟；实践中也可直接采用云厂商默认的 Rerank API；
• LLM负责阅读理解与答案合成，使用方式分两类：私有化部署（Qwen、Llama、GLM 等开源系列，适合注重数据隐私与成本可控的场景）和云端 API 服务（适合快速上线、弹性扩展的场景）。对话问答能力的综合评估可参考 LMArena 的盲测对战榜单，但更务实的做法是构建 20-30 个典型业务问题的小型测试集，对候选模型做端到端 RAG 评估，而非仅看单点性能。

运行框架：通常不必从零构建。低代码/可视化平台（如 Dify、Coze、RAGFlow、FastGPT）适合非技术团队快速验证；代码框架（如 LlamaIndex、LangChain）适合深度定制检索策略或集成多种数据源；实际项目也可采用"混合方案"——低代码平台快速验证可行性，代码框架实现生产级部署与优化。

效果评测：RAG 涉及检索和生成两个非确定性环节，传统软件测试方法不再适用，需要建立体系化的评测（RAG Evaluation）。

• 检索效果：Recall@K（前 K 条结果中相关文档的找回比例）、Precision@K（前 K 条结果中真正相关文档的占比）、F1（两者调和平均）衡量基础召回质量；MRR（第一个相关文档位置倒数的均值）、NDCG@K（考虑相关分级与位置衰减）、MAP（综合所有相关文档位置）衡量排序质量。工程上常用 Recall@K + MRR@K 组合——若 Recall@10 达 80% 但 MRR@10 只有 0.3，说明相关文档被找到了但排在后面，应重点优化重排序；
• 生成质量：EM（精确匹配，适合答案唯一的事实问答）、ROUGE/BLEU/METEOR（n-gram 词汇重叠）、BertScore 或向量相似度（语义级相似，容忍表述差异）；更关键的是Hallucination（幻觉率）与Faithfulness（忠实度）——让另一个 LLM 扮演"事实核查员"逐句判断生成答案能否在检索文档中找到依据；
• LLM-as-a-Judge：将问题、检索文档、系统回答、参考答案一并交给独立大模型，从问题相关性、信息完整性、事实忠实性、整体正确性四个维度综合评分；
• 评测框架与基准：RAGAS（最早的综合性评测框架之一，同时评估检索与生成）、ARES（分类器辅助评测）、RGB（关注噪声鲁棒性、负样本拒绝等细分维度）、MultiHop-RAG（多跳推理场景）等各有侧重；医疗、法律、金融等垂直领域还有 MedRAG、LegalBench-RAG 等专用框架。实践中建议从精简组合开始——检索用 Recall@K + MRR@K，生成从 EM、ROUGE-L、BertScore 中选一到两个做基线，再引入 LLM 裁判，形成"评测 → 发现问题 → 调整策略 → 再评测"的迭代循环。

总结

RAG 是当前让大模型"落地"最实用的技术之一。它的核心价值在于：让模型的回答有据可查、知识可实时更新、幻觉可有效控制。

回顾本章的关键要点：

1. RAG 解决的核心问题：大模型知识过时、缺乏私有数据、容易幻觉；
2. 三阶段流程：索引（离线准备）→ 检索（在线查找）→ 生成（综合回答）；
3. 分块是基础：分块质量直接决定检索质量，选择合适的策略至关重要；
4. 检索是关键：混合检索 + 重排序是目前效果最好的组合；
5. 架构在演进：从 Naive RAG 到 Modular RAG，系统越来越智能和灵活；
6. RAG 和微调互补：大多数场景先试 RAG，需要改变模型行为时再考虑微调。

进一步阅读

• RAG 原理（英文版） —— 本文对应的原版文档，含交互式演示组件说明
• RAG 入门教程：从原理到企业级实践 —— 苹果知识库全流程案例、三代架构详解、模型选型与评测体系、竞赛级实战方案
• Embedding 与向量检索原理 —— 向量化、相似度计算、ANN 索引与向量数据库的底层原理
• 上下文工程 —— 与 RAG 密切相关的 Prompt 组织与上下文利用策略
• 模型微调与部署 —— 微调路线与 RAG 形成互补的技术方案
• AI 智能体（AI Agents） —— 从 RAG 到 Agentic RAG 的演进方向

• 教程
• 文档