收益：
- 设计端到端企业 RAG 助手的组件和数据流
- 将多源数据（wiki、票证、PDF、数据库）合并到一个助手中
- 制定可扩展性、缓存和延迟的架构决策
在之前的单元中，我们一一学习了各个部分：嵌入、向量数据库、分块、检索。现在，让我们将这些结合起来，构建一个与您自己的公司数据对话的端到端助理架构。目标是让员工询问“我们的休假政策是什么？”一个人们可以提出问题的系统，答案基于真实的内部文档、引文并结合多个数据源。该单元处理整个架构、数据流和生产级别决策。
端到端组件
公司 RAG 助理由两条独立的线路组成。索引线（离线）准备数据；查询线（在线）回答了问题。
分度线组件：
- 连接器：从维基、票务系统、文件存储、数据库、电子邮件等来源提取数据的连接器。
- 规范化：将不同格式（PDF、HTML、DOCX）转换为干净的文本；页眉/页脚清洁。
- 分块 + 元数据：分块和标记（来源、日期、权威）。
- 嵌入+加载：将向量和元数据写入向量数据库。
查询管道组件：
- 查询预处理：重写、去中心化。
- 检索：混合搜索+元数据过滤+重新排名。
- 提示创建：将上下文+问题+说明放入模板中。
- 生成：来自模型+来源的接地（上下文）答案。
- 后处理：引文格式、安全检查、日志记录。
提示：将索引行与查询行物理分开。索引编制缓慢且周期性（隔夜分批运行）；询问的方式应该是轻松而直接的。混合两条线会在用户等待时强制进行繁重的处理。
可视化数据流
[INDEXING - 离线]资源 → 标准化 → 块+元数据 → 嵌入 → 矢量数据库（wiki、ticket、PDF、DB）[QUERY - 在线]用户问题 → 预处理 → 检索（混合+过滤+重新排序）→ 提示（上下文+问题+指令）→ 模型 → 答案+来源 → 用户
结合多源数据
在现实的公司中，答案并不止于一处。 “如何向客户退款？”该问题的答案可以在帮助文章（程序）、票证历史记录（真实示例）和政策 PDF（规则）中找到。助手应该将所有这些都放在一个池中进行搜索。
关键点：将资源组合到单个向量存储中时，每个分片必须携带“source_tour”元数据。因此您可以全部搜索并在必要时进行过滤，例如“仅携带官方政策”。此外，不同的来源具有不同程度的可靠性：官方政策 > 帮助文章 > 员工票据。您可以在重新排名或提示中指定此优先级。
来源
内容类型
信任
更新频率
政策 PDF
官方规则
高
每月
帮助文章
程序
中高
每周
门票历史记录
真实样品
中等
连续
维基百科
混合/当前音符
变量
连续
可扩展性、缓存和延迟
生产中存在三个突出问题。延迟：当用户等待超过2秒时，体验会变差。解决方案：以流形式显示答案——随着模型的写入，答案被倾倒到屏幕上。缓存：对于常见问题和重复上下文，缓存既可以提高速度，又可以降低成本。规模：随着用户的增加，需要能够水平扩展检索和模型调用。
成本方面的经验法则：最昂贵的步骤通常是进入更大模型的代币数量。因此，通过重新排序将上下文减少到 4 个好的部分可以提高质量和成本。常见的设计是使用更小/更快的模型来进行简单的分类或路由，并使用更强大的模型来获得最终答案（例如 claude-opus-4-8）。
注意：不要将索引设置为“做一次，忘记它”。文档被更改、删除、添加。建立重新索引策略：检测已更改的文档并仅重新处理它们。过时的索引生成的答案看似最新，但实际上是错误的。
弱架构/强架构
弱（单一脚本，一切混合）：
当用户询问：阅读当时的文档，粉碎它们，嵌入它们，搜索它们，回答它们。#问题：每个问题都会重复所有索引；延迟秒数，#无源分离，无过滤，无刷新。
强大（分割管道+元数据+缓存+流）：
索引：夜间批量运行，刷新更改的文档。查询：轻量级线路——预处理→混合检索+过滤→重排序→提示→模型（流）→引用→日志。常见问题和来源都会被缓存。
三个迷你箱
情况 1 — 线路混乱，严重延迟。一家初创公司编写了一个脚本，可以重新处理每个问题的 PDF；每个答案平均需要 11 秒。当索引行分离并且数据先前传输到向量存储时，查询时间减少到 1.3 秒，并且使用流式传输，“第一个单词”出现在 400 毫秒内。
情况 2 — 资源太多，优先级错误。支持助理对保单 PDF 和旧票单给予同等重视；该模型有时会将两年前员工的错误评级作为官方规则。当 source_tour 元数据和“在发生冲突时考虑官方政策”指令添加到提示中时，错误优先级错误减少了 89%。
情况 3 — 过时的索引。人力资源助理正在处理一个已经 3 个月没有更新的索引；休假政策变了，但助理还是说以前的事。当安装每日刷新（检测更改的文件）后，当前响应率从 70% 增加到 99%。
常见错误
- 混合索引和查询行：繁重的处理是在用户等待时完成的；延迟爆炸。
- 不将源类型放入元数据：没有优先级和过滤；不受信任的来源似乎是官方的。
- 不建立刷新策略：索引变得陈旧；产生了当前出现的错误答案。
- 跳过流媒体：用户看着空白屏幕；感知到的延迟变高。
- 每一步都使用最大的模型：成本不必要地增加；将转向系统留给较小的型号。
综上所述
- 企业RAG助手由离线索引和在线查询两条独立线路组成；将他们物理分开。
- 索引 = 连接器 + 规范化 + 块/元数据 + 嵌入/上传；查询=预处理+检索+提示+生成+后处理。
- 多源数据合并到单个存储库中，但保留 source_type 元数据和信任优先级。
- 针对延迟的流式传输和缓存、上下文限制以及针对成本的模型选择至关重要。
- 如果不重新建立索引，索引就会变得陈旧；定期重新处理更改的文档。
应用任务
为你自己的团队画一个助手的架构图。 (1) 确定至少三个真实数据源，并记下每个数据源的连接器需求、更新频率和信任级别。 (2) 用方框箭头图分别绘制索引线和查询线。 (3)“在这个助手中，我可以在哪里减少延迟和成本？”针对该问题至少写出两个具体决定。 (4) 用一句话描述一下您的刷新策略：哪些资源将被重新索引以及多久重新索引一次？
清单
- [ ] 我可以使用正确的组件分别绘制索引和查询线。
- [ ] 我可以将多源数据与source_type和信任优先级结合起来。
- [ ] 我可以针对延迟做出流/缓存决策，并针对成本做出模型选择。
- [ ] 我知道为什么重新索引策略至关重要。
- [ ] 我记住，我的架构中最昂贵的步骤通常是进入更大模型的令牌。