企业官网建设流程全解析

看到标题里的 “Complete Guide part1” 时，我第一反应不是“这门课讲什么”，而是“为什么现在 AI、LLM、GenAI 和 RAG 这四个词能凑到同一门课里，并且还要分成 part1、part2 来讲”。如果你已经在用 LangChain、Dify 或手写过 RAG 流程，大概率也遇到过类似困惑：教程里每一步都跑通了，合在一起就是不稳定；检索结果看着相关，模型回答却完全跑偏；明明加了知识库，模型还是答非所问。这不是某个工具的问题，而是 RAG 从一开始就不是“一个库”“一个脚本”能解决的，它是一套完整系统。而这套系统最难的，恰恰不是生成，是检索、组装、评估和迭代。

这篇不是课程导读，也不是功能介绍。我想从 RAG 工程化的角度，拆一拆为什么这类内容值得系统学一遍、真正的学习分水岭在哪里，以及从 demo 到可用之间，你到底缺了哪些环节。

1. 为什么 RAG 不是“一个库”，而是一套需要调优的系统

1.1 先分清：RAG 真正解决的不是检索，而是可控生成

很多人理解 RAG，第一反应是“给 LLM 加一个知识库”，让模型回答私有数据、最新数据。这个理解没有错，但它把 RAG 的价值说小了。

RAG 真正解决的是“生成的可控性”问题。大模型在训练时被“固化”了一部分知识，这些知识有截止时间、有覆盖范围、也有胡说八道的可能。RAG 的思路是：不在模型内部硬塞知识，而是在回答的当下，先从外部检索到相关内容，再把检索结果拼进提示词，让模型基于给定材料作答。

这意味着两件事：

• 模型可以不用“记住”你的私有知识，它只需要“读懂”你给它的片段。
• 回答的依据是可替换、可追溯、可更新的，而不是埋在权重里不可解释。

所以，如果你只是把 PDF 切开、塞进向量库、然后等模型回答，那你只做了 RAG 的表层。真正的 RAG 工程，是把“检索-组装-生成-检验”这整条链路变成一套可以被度量、被调整、被迭代的系统。这门课程把 RAG 放在“AI & LLM Engineering Mastery”的框架里，而不是单独讲一个“文档问答工具”，背后其实就是这个逻辑。

1.2 为什么很多人停留在“demo 能跑”阶段

我见过不少开发者，环境装好、代码跑通、示例问答能返回结果，然后就没有然后了。原因不是懒，而是 demo 和真实系统之间隔着四道墙：

• 数据墙：示例文档是干净的，真实文档是扫描件、多栏排版、表格、图片混合体。
• 检索墙：示例 query 是和文档强相关的，真实 query 是口语化、模糊、带错别字的。
• 判断墙：示例只看最终回答，真实系统要判断“到底有没有答对”“依据是否充分”。
• 迭代墙：示例改一次就完了，真实系统每天都要面对新文档、新问题、新失败案例。

课程能讲完的，永远是通用方法和典型链路。真正拉开差距的，是你有没有能力把上面四道墙逐个拆掉。而拆掉的前提，是你完整理解 RAG 内部每一层在干什么。

2. 把 RAG 拆成七层，你才知道问题出在哪

如果一个 RAG 系统表现不好，最忌讳的是整条链路一起调整。正确做法是先定位：问题出在输入解析、分块策略、embedding、检索、重排、上下文组装，还是生成环节？为了做定位，我建议把 RAG 拆成七个层面来理解。

2.1 从文档解析到分块：输入质量决定结果上限

绝大多数 RAG 失效，问题不在模型，而在“喂进去的东西”。

文档解析不是“把 PDF 变成文本”这么简单。PDF 里的多栏排版、页眉页脚、表格、图片说明、脚注，都会污染切分结果。你切出来的文本块可能包含半个句子、两个不相关内容、或者把一个完整概念从中间切断。这些噪声对向量检索的影响是致命的，因为 embedding 模型关注的是语义，不是版面。

分块策略同样关键。分块太小，语义不完整；分块太大，向量表示被平均化，检索精度下降。这里没有标准答案，但有几个通用判断顺序：

• 先保证块内语义完整，再考虑长度。
• 优先按标题、段落、表格边界来切，而不是固定字符数。
• 相邻块之间要保留重叠，防止概念被切开。
• 如果是代码、表格、合同条款这类结构化内容，要用对应解析器，不能一刀切。

更实际的做法是：先准备 20 到 50 条真实问答，再用这些问答去检验切分结果。如果答案信息分散在多个块里，就说明切分粒度或重叠策略需要调整。这一步不做好，后面所有环节都在补救。

2.2 向量化与检索：相似度不是唯一标准

embedding 模型决定了文本在向量空间里的“位置”。同一个 query，用不同的 embedding 模型，检索结果差异可能非常大。选型时不能只看公开榜单分数，还要看你的文本领域和语言。

比如，你的知识库是中文技术文档、法律合同、还是英文论文，适合的模型不一样。不同模型的上下文长度、维度、对长文本的压缩方式也不同。这里给一个选型检查顺序：

1. 先拿 10 条你领域内的 query 做测试。
2. 对比召回结果里有多少条是真正有用的。
3. 判断模型对同义词、口语化表达、缩写是否敏感。
4. 如果检索质量不行，优先换 embedding 模型，而不是调相似度阈值。

检索阶段同样不能只看向量相似度。精确匹配、BM25 关键词检索、混合检索（hybrid search）在很多时候比纯向量检索更可靠，尤其是当 query 包含型号、编号、人名、日期这些“必须精确命中”的信息时。常见的做法是：向量检索负责语义召回，关键词检索负责精确召回，然后用重排模型（reranker）把两组结果合并排序。

重排环节非常容易被忽视。向量检索返回 Top K 后，K 个结果里可能只有 2 个真正相关。重排模型的职责就是把这 2 个往前放。很多场景里，加一个 reranker 比换 embedding 模型带来的提升更明显。

2.3 上下文组装和生成：prompt 工程在这条链路里的真实位置

检索完之后，怎么把检索结果拼进 prompt，直接决定生成质量。常见错误有两种：

• 把全部检索结果一股脑塞进 prompt，导致模型被无关内容干扰。
• 没有告诉模型“只用给定材料回答，材料里没有就直说”。

更合理的组装方式是：把检索结果按相关度排序，只保留最相关的几段，并明确标注每段内容的来源。Prompt 里要写清楚三件事：系统角色、可用材料、回答规则。回答规则至少包括“仅基于材料回答”“材料不足时明确说不知道”“不要编造来源”。

这里还想纠正一个观念：prompt 工程不是独立的魔法，它是 RAG 链路里的一个环节。只有当检索结果足够好时，prompt 才能发挥真正作用。检索返回一堆噪声，写再多提示词也救不回来。反过来，检索结果很好，但 prompt 没有约束模型只基于材料作答，模型还是会自由发挥。两个环节要一起调。

3. 用指标而不是体感来判断 RAG 好不好

3.1 检索质量指标：召回率、精确率、MRR、NDCG

判断 RAG 好坏，不能靠“感觉还挺相关”。你需要一套指标，尤其是当你已经积累了几百条测试问题时。

先明确两个基本概念：

• 精确率（Precision@K）：你检索返回的 K 条结果里，有多少条是真正相关的。
• 召回率（Recall@K）：所有相关文档里，你找回来了多少条。K 越大，召回通常越高，但精确率会下降。

除了这两个，还有两个更常用、但在实际项目里经常被误读的指标：

• MRR（Mean Reciprocal Rank）：看第一条正确答案排在第几位。如果第一条正确结果在第二位，那这条 query 的 reciprocal rank 就是 1/2。把所有 query 取平均，得到 MRR。判断“正确答案是否能被排到最前面”时，MRR 很直接。
• NDCG（Normalized Discounted Cumulative Gain）：不只是看“相关与否”，还看“相关程度”。它会按位置的先后对收益打折，排得越靠后，增益越小。适合排序结果本身有级别差异的场景。

把这四个指标放一起，你不光能看出“检索得准不准”，还能看出“正确结果排得靠不靠前”。这比肉眼翻看十来条结果要可靠得多。

3.2 生成质量评估：忠实度、相关性、完整性

检索指标只解决一半问题。另一半是“生成质量”。RAG 的生成评估，通常要分开看三个维度：

• 忠实度（Faithfulness）：模型的回答是否严格基于检索到的材料，有没有自己的“想象力”。这是 RAG 最重要的指标，它直接决定你是否能信任回答。
• 答案相关性（Answer Relevance）：回答是否在回应 query，而不是答非所问或绕圈子。
• 完整性（Completeness）：针对一个需要多步骤回答的问题，答案是否覆盖了所有必要部分。

评估方式有两种。一种是用 LLM 作为裁判，把“材料 + 答案 + 评估标准”发给一个强模型，让它打分并输出理由。另一种是人工抽检，尤其在小样本阶段，人工抽检能发现很多自动评估看不到的语义问题。实际项目里通常混合使用：自动评估跑全量，人工抽检跑关键案例。

3.3 一套可复用的评估迭代框架

这里沉淀一个比较通用的 RAG 评估流程，适合从零开始的项目：

1. 准备 30-100 条测试问题，覆盖高频问题、复杂问题、边界问题、应该回答“不知道”的问题。
2. 对每个测试问题标注标准答案，以及“回答依据应在哪些文档内”。
3. 先跑一遍当前链路，记录检索结果和生成结果。
4. 计算检索指标（Recall@K、MRR、NDCG）和生成指标（忠实度、相关性、完整性）。
5. 找出失败案例，按“检索失败”和“生成失败”分类。
6. 检索失败：调整分块、embedding、检索方式、重排。
7. 生成失败：调整上下文组装、prompt 约束、候选文档数量。
8. 每改一步，只跑一次全量评估，对比前后指标，不要把多个改动混在一起。

这个框架看起来不复杂，但它是 RAG 从“能跑”走向“可用”的分水岭。没有评估，你就不知道改动是在变好还是变坏。

4. 从课程到项目：为什么建议先跑通最小闭环，再上框架

4.1 “先手写一遍 RAG 链路”到底在练什么

现在有 LangChain、LlamaIndex、Dify、向量数据库自带 SDK 这些高层封装，很多人会问：还有必要手写 RAG 吗？我的判断是：如果你只是想快速做个 demo，用框架没问题；但如果你要做真实的 RAG 项目，最好先手写一遍最小链路，哪怕很简陋。

手写一遍的价值不是“不用框架”，而是让你理解每一层发生了什么：

• 文档加载之后，文本在哪里被切分、以什么结构存储？
• 向量化之后，元数据、来源、分块 ID 是怎么和向量关联的？
• 检索时，query 是怎么被向量化的？Top K 被取出来后，发生了什么？
• 组装 prompt 时，候选文本的截断、排序、来源标注是怎么处理的？

这些问题在用框架时很容易被屏蔽掉。框架帮你把链路串起来了，但一旦出问题，你往往不知道去哪一层排查。

我建议的最小闭环是这样的：

1. 准备一个 PDF 或 Markdown 文件。
2. 写脚本切分文本，保存成带 ID 的文档块。
3. 调用 embedding 模型，把每个块向量化，存进向量数据库。
4. 用一个 query 做向量检索，打印出 Top 5 结果。
5. 把检索结果拼进一个写好的 prompt，调用 LLM 生成回答。
6. 打印完整 prompt，看模型到底“看到”了什么。

这一步跑通后，再引入框架，你会发现框架里每个参数、每个组件都在解决你手写时遇到过的真实问题。这时候学 LangChain、Dify 就不是“记 API”，而是理解设计思路。

4.2 LangChain、Dify、LlamaIndex 这些框架的边界

框架也不是没有价值。它们真正解决的是“常见模式的复用”：

• LangChain 提供了大量 loader、splitter、retriever、memory 的标准化接口，适合拼装自定义链路。
• LlamaIndex 在文档解析和索引结构上做得更细，适合做以文档为中心的知识库。
• Dify 把 RAG 应用做成了可视化编排，适合快速验证流程，也适合给业务人员配置。

但框架也有明显的边界：

• 框架的价值在于“默认路径帮你走通”，但不保证每个默认值都适合你的场景。
• 框架升级快，API 变动频繁，跟着教程敲代码容易陷入“版本对不上”的坑。
• 框架隐藏了成本结构。一次检索调用多少次 embedding、多少个候选块进 prompt、有没有重复计算，都需要你额外关注。

所以我会把框架当成“高级工具箱”，而不是“学习入口”。先用最小闭环建立心智模型，再根据项目复杂度选择合适的框架，是更稳的路径。

4.3 长期工程化还需要补什么

从“一个能跑的知识库问答”到“一个可用的系统”，中间还缺几块拼图：

• 日志链路：每条 query 的检索结果、最终 prompt、模型输出都要记录。没有日志，你就无法复现失败案例，也无法改进。
• 缓存与成本控制：相同或相似 query 的检索结果可以缓存；候选文档数量要控制；embedding 调用要避免重复计算。
• 降级策略：向量数据库挂了怎么办？模型服务超时怎么办？有没有关键词检索兜底？
• 权限与数据隔离：多用户场景下，A 用户的知识库不能泄露给 B 用户。这个在架构设计阶段就要考虑。
• 版本管理：文档更新后，向量库怎么同步？旧的向量怎么清理？embedding 模型升级后，是否要全部重新向量化？
• 评测沉淀：把测试集、评估脚本、业务指标固化下来，纳入开发和发布流程。

这些内容，通常不会出现在“入门教程”里，但恰恰是判断一个 RAG 项目是否成熟的关键。

5. 一个针对 RAG 的排查链路

5.1 检索不到：先查输入、切分、embedding、索引、query

如果用户问的问题明明在知识库里，但检索不到相关内容，按这个顺序排查：

1. 查输入文档：PDF 是不是扫描件？有没有 OCR？文本是不是被破坏？
2. 查切分：目标内容是不是被切碎了，或者跟不相关的内容混在同一个块里？
3. 查 embedding 结果：把目标文档块和 query 分别向量化，算一下相似度，看是不是真的低。
4. 查索引和元数据过滤：是不是有权限过滤、时间过滤误伤了目标内容？
5. 查 query 本身：用户问的是“怎么退款”，但文档里写的是“退货政策”，语义术语不同，需要同义词扩展或混合检索。

5.2 检索到了但答错：先查上下文组装和 prompt

如果 Top 5 检索结果里有正确答案，但最终回答还是错的，问题通常出在生成阶段：

1. 先打印完整 prompt，确认模型到底看到了哪些内容。
2. 检查候选文本是否被截断，截断后关键信息是否丢失。
3. 检查 prompt 里的排序：正确答案是否被排到后面，被无关内容挤占。
4. 检查模型角色设定和回答规则：有没有约束“只能基于材料回答”。
5. 如果都正常，换更强的模型试一次。部分问题对推理能力要求高，小模型确实答不对。

5.3 回答慢或成本高：先查候选数量、缓存、并发

RAG 系统的“慢”通常来自三个地方：

• 检索慢：向量库数据量大、索引类型不合适、没有用 ANN 索引。
• 生成慢：候选块太多，prompt 太长，模型输出 token 数太多。
• 调用链慢：每次请求重复做 embedding、重复查库，缺少缓存。

建议先加缓存，再看 Top K 数和 max_tokens，最后才考虑换模型或换索引。

5.4 一张排查表格

排查的基本原则是：一次只改一个变量，改完跑一组测试集，用指标判断是否变好。

6. 学习顺序，才是这类课程真正值钱的地方

6.1 不要按章节顺序学，要按问题顺序学

很多课程和项目把内容拆成“基础概念-环境搭建-代码实现-项目实战”。这种顺序适合系统的知识索引，但不适合构建解决真实问题的能力。因为真实世界里，你不会先学完所有概念再动手。你通常是先遇到一个问题，然后被迫去理解相关概念。

以 RAG 为例，我更推荐按问题顺序学：

1. 先用 30 分钟跑通一个最小 RAG demo，建立感性认知。
2. 故意制造几个失败案例：改小分块、去掉重排、把 prompt 约束删掉，观察效果变化。
3. 带着失败经验去学理论：为什么切分影响检索？为什么需要混合检索？
4. 再补评估指标，用数据验证之前的直觉。
5. 最后再学框架，用框架复现手动链路。

这样的学习路径比从头到尾看一遍课程更牢靠。因为每一步都是在解决一个你已经遇到的真实问题，而不是记忆一个未来可能用到的 API。

6.2 “part1”背后的内容边界意识

回到课程标题里的 “part1”。它其实揭示了一个行业事实：GenAI 和 LLM 工程化的内容量已经大到不可能一个课程、一个章节全部讲完。

基础层面有 tokenizer、模型架构、推理优化、上下文管理；应用层面有 prompt 工程、RAG、Agent、工具调用、记忆管理；工程层面有评估、可观测性、成本控制、数据管道；再往上还有多模态、微调、蒸馏、部署、运维。

如果你把“学会 RAG”当成目标，那是一个有限目标，按上面的路径走，两三个月就能入门。如果你把“精通 LLM 工程”当成目标，那就要接受这是一个持续迭代的过程。每次学习新模块，都应该带着前面沉淀下来的问题意识和排查方法，而不是从零开始背概念。

6.3 我的最终建议：把 RAG 当成一个“系统调试”问题，而不是“模型调用”问题

回到开头的问题：为什么 RAG 教程总让人觉得“会了但没用”？因为真正决定系统质量的，不是你会不会调用模型，而是你有没有能力把输入、切分、向量、检索、重排、组装、生成、评估这八个环节拆开、调优、再组装起来。

我给想系统学习 AI 和 LLM 工程的读者的建议是：

1. 选一门覆盖完整链路的课程或项目，但不要跟着敲完就算完。
2. 准备一套自己的小规模数据集，用真实文档做 RAG。
3. 手写一遍最小链路，建立每个环节的心智模型。
4. 用评估指标驱动改进，不要靠体感迭代。
5. 再引入框架，把精力放在业务逻辑和系统健壮性上。

这样学下来的结果，不是“会用 RAG”，而是“能判断、能定位、能改进一个 RAG 系统”。后者才是这类课程把它叫做 Engineering Mastery 的原因。

RAG 本身还在快速演进。Agentic RAG、Graph RAG、自适应检索、多轮记忆融合这些方向，都会持续改变它的实现形态。但只要你有“链路拆解 + 指标迭代 + 系统排查”这套底层能力，无论 RAG 怎么变，你都能快速接住。

下次再看到一个“3 小时搞懂 RAG”的视频，不用点进去。省下那三个小时，去搭一套自己的 RAG 系统，然后逼自己回答一个问题：如果检索结果不好，我下一步动哪一层？