当资料不再只是批次：用 Pathway 建立可持续更新的即时 RAG 管线

我认为，RAG 系统真正难的地方，通常不是把一个模型接到向量资料库，而是让资料在第二天、第二周、甚至每一分钟改变时，答案仍然跟得上。许多团队第一次做 RAG，会先完成一条很漂亮的离线流程：读取 PDF、切割文字、产生 embedding、写入向量资料库，最后让聊天机器人查询。Demo 当然可以成功，但一旦产品文件、客服知识、库存资料或权限状态开始变动，更新索引就变成另一套容易失控的批次工作。

Pathway 值得注意的地方，在于它不是单纯再包一层向量资料库，而是把 stream processing、real time analytics、LLM pipelines 与 RAG 放到同一个 Python ETL framework 里。这个定位带来的核心想法很简单：不要把「资料更新」当成 RAG 之外的维运补丁，而是把资料来源、转换、索引与查询视为一张会持续运算的资料流图。当上游资料改变，下游结果便可以依赖关系重新计算。

这篇文章不把 Pathway 当成万能的 RAG 解答。我会从它解决的问题开始，走过一个可验证的上手路径，再谈它的架构取舍、适用场景与不适合的地方。我的判断是：如果你的 RAG 需要接住持续变动的来源，Pathway 比单次汇入工具更值得评估；如果你的需求只是每晚重建一次小型索引，它可能反而增加不必要的复杂度。

先讲结论：Pathway 解的是「索引之后还会变」

一条传统的离线 RAG 管线大致如下：

1. 定期扫描资料来源。

1. 找出新增或修改的文件。

1. 重新切割内容并产生 embedding。

1. 更新向量资料库。

1. 重新整理快取与查询服务。

问题不在这五步本身，而在每一步之间都需要自行处理状态、重试、重复事件、删除事件与依赖关系。当资料来源从一个资料夹增加到云端储存、资料库、讯息伫列或多个 API，批次脚本很快就会变成一个没有明确资料模型的排程系统。

Pathway 的思路是以表格与资料流运算来描述这些步骤。资料来源被读成持续更新的 table，清洗、切割、转换与索引是对这些 table 的运算。这让「新增一份文件」和「修改一份文件」不必被写成两条完全不同的流程，而是同一张资料流图在新输入下产生新的结果。

这里有一个重要的界线：即时更新不等于每个 token 都能毫秒级完成，也不等于所有来源都自动具备完美的变更追踪。真正的延迟会受到来源 connector、档案大小、embedding 服务、模型推论、向量索引与部署资源影响。因此，Pathway 的价值比较接近「把增量资料处理的语意放进框架」，而不是承诺一个脱离环境的固定延迟数字。

它的核心模型：把 RAG 看成一张持续运算的图

我会用四个层次理解 Pathway。

第一层：输入来源

来源可以是持续变动的档案、资料表、事件流或其他 connector。对 RAG 来说，这一层决定系统能不能正确观察新增、修改与删除。若来源只提供一次性的汇出档，后面的管线再即时，也只能在下一次汇出后才看到变化。

第二层：资料转换

原始资料通常不能直接送进 embedding 模型。你需要处理编码、栏位标准化、文件切割、metadata、权限标记与版本资讯。这些转换最好保持可测试、可重跑，并且把来源识别码一路带到最后，否则查到内容时很难回溯原始文件。

第三层：LLM 与索引运算

在这一层，管线可以接 embedding、摘要、分类或其他 LLM 运算，再把结果写进向量索引。Pathway 官方定位包含 LLM pipelines 与 RAG，但这不代表你可以忽略模型本身的限制。Embedding 模型换版、chunk size 改变或 metadata schema 改变，都可能让既有索引需要重新评估。

第四层：查询与服务

使用者问题进入后，需要完成 query embedding、相似度搜寻、metadata filter、上下文组装与回答生成。这条查询路径和资料更新路径可以互相配合，但不应混为一谈。资料更新速度快，不表示回答一定正确；回答品质仍取决于召回、权限、提示词、模型与引用策略。

这种分层方式也提醒我们：Pathway 主要帮忙处理资料流与管线协作，并不会替你决定什么内容可以被回答、如何执行租户隔离、怎么做 prompt injection 防护，或如何为高风险答案建立人工审核。

如何开始：先做一个能验证更新的最小管线

我建议不要一开始就把企业所有来源接进来。先建立一个最小实验，验证三件事：资料能否被读取、内容变更是否能传到索引、查询是否能拿到可追溯的上下文。

1. 准备环境与依赖

Pathway 是 Python framework。实际部署前，先依官方文件确认支援的 Python 版本、资料来源 connector、模型供应商与向量索引方式。专案本身的 README 提供安装与 quickstart 入口；正式环境则应使用 uv、容器或团队既有的依赖管理方式固定版本，避免本机能跑、部署环境却因依赖漂移而失败。

最小安装可从 Python 套件开始：

pip install pathway

这行指令只代表安装套件，不代表 RAG 已经完成。接着你需要准备一个小型资料来源，例如包含数份 Markdown 或纯文字文件的目录，并在文件中保留标题、来源 URI、修改时间与权限等 metadata。

2. 先验证来源与更新事件

第一个可验证任务不是问模型问题，而是确认资料变更确实被管线看见。启动最小资料流后，先放入一份文件，观察输出是否出现；接着修改文件内容，再确认下游资料是否只更新受影响的纪录。最后移除文件，检查索引或输出是否有对应的删除语意。

这个测试很重要，因为很多「即时 RAG」其实只验证了新增，没有验证修改与删除。若删除事件无法传递，系统就可能继续引用早已撤下的政策；若修改事件被当成新增，则会出现重复片段与旧版本竞争。

3. 再接上 embedding 与查询

来源事件稳定后，再加入文件切割与 embedding。切割策略不要只用固定字数：程式码、表格、规章条款与 FAQ 的结构不同，应至少比较段落切割、标题感知切割与 metadata filter 对召回品质的影响。

查询结果也要能回到来源。每个 chunk 至少保留文件识别码、来源连结、版本或修改时间，并在回答中提供引用。没有追溯资讯的 RAG，即使答案看起来流畅，也很难让使用者判断它是否使用了最新内容。

4. 把观测性放在第一版

对即时管线，我会在第一版就记录事件时间、处理延迟、失败重试、embedding 请求耗时、索引更新时间与查询召回结果。若只记录最后的回答文字，你看不到问题究竟发生在 connector、切割、模型、索引还是权限过滤。

最低限度的验证清单可以是：

新增文件是否在预期时间内可被查询。
修改文件后，旧片段是否不再被召回。
删除文件后，回答是否停止引用它。
同一事件重送时，是否造成重复资料。
embedding 或 LLM 暂时失败时，是否能重试且不破坏既有索引。
权限栏位是否一路传到召回与回答阶段。

Pathway 真正有价值的地方

1. 更新逻辑和资料逻辑放在一起

批次脚本常把「同步」当成外部排程，把「索引」当成另一个服务。Pathway 让资料来源、转换与下游输出以同一个资料流模型描述，团队比较容易看清楚一笔资料如何一路流动。这对需要持续接资料的知识库、监控摘要与文件问答尤其有帮助。

2. Python 入口降低实验门槛

对已经使用 Python 做资料工程或 LLM 应用的团队，直接在熟悉的语言中组合来源、转换与模型呼叫，比重新学一套完全不同的 DSL 容易开始。这不代表 Python 自动解决生产环境的并发、资源与部署问题，但它能让概念验证更靠近最后的程式码。

3. 同一套思路可延伸到非 RAG 场景

Pathway 的定位不只包含文件问答，也包含串流处理与即时分析。这表示同一套增量计算思路，可以用在资料清洗、事件聚合、监控、推荐前处理或需要持续更新的 LLM workflow。对不想把每个 AI 功能都包成一次性脚本的团队，这种一致性是长期价值。

限制与常见误区

第一个误区是把框架当成资料品质保证。Pathway 能帮你组织资料流，但来源资料是否完整、时间戳是否可信、文件删除是否真的可观察，仍然是你的责任。上游没有提供可靠变更资讯时，框架只能采用扫描或重算等替代策略。

第二个误区是只用 Demo 的召回效果评估系统。RAG 上线后，最常见的问题不是「完全找不到」，而是找到旧版本、越权内容、相似但不适用的段落，或在资料更新期间同时看到新旧版本。因此，评估集要包含修改、删除、权限变更与相互矛盾的文件。

第三个误区是忽略成本。每次文件变更都可能触发切割、embedding、索引与快取更新。高频资料来源若没有去重、批次合并、背压与失败重试策略，云端 API 成本和运算资源会随事件量上升。即时不应被理解成「所有工作都立刻做」，而是要根据业务新鲜度设计合理的处理窗口。

第四个误区是没有处理安全边界。文件内容可能包含恶意 prompt、伪造的系统讯息或不应暴露的资料。RAG 应用需要把文件当成不可信资料，对来源、租户、权限与引用做明确控制，并且在回答层加入拒答与人工覆核策略。框架的资料流能力不能取代安全设计。

谁适合先试，谁不必急着换

我会优先推荐以下团队做小规模试点：

文件、政策、FAQ 或产品资料每天都在变动。
已经有 Python 资料工程能力，希望把批次同步逐步改成增量管线。
需要把多个资料来源整理成可追溯的 LLM 上下文。
愿意先建立事件、索引与回答品质的观测指标，而不是只看 Demo。

以下情况则不必急着采用：

资料量很小、每天重建一次索引已经足够。
团队没有维护长时间执行服务、connector 与模型 API 的能力。
需求主要是一次性文件转换，而不是持续更新的资料流。
目前连资料权限、来源识别与删除语意都还没有定义。

我的建议是先用一个低风险、可回滚的资料集做试点，并把离线批次版本保留作为基准线。只有当 Pathway 的增量更新真的降低延迟、减少同步脚本或改善资料新鲜度，才值得把更多来源搬上去。

最后的判断

Pathway 最值得看的不是「它也能做 RAG」，而是它把 RAG 背后常被忽略的资料生命周期拉到前景：来源如何变动、转换如何重算、索引如何同步、删除如何传递，以及查询如何取得可追溯上下文。这个视角比单纯比较向量资料库功能更接近实际产品问题。

如果你的系统需要持续吸收变动中的资料，Pathway 提供了一条值得验证的 Python 路径：先用最小资料流验证新增、修改、删除，再接 embedding、索引、查询与观测性。反过来说，如果需求只是低频、静态、小规模的文件问答，成熟的批次工具可能更简单，也更容易维护。

我会把 Pathway 的导入判断浓缩成一句话：当「最新资料」是产品需求，而不是 Demo 加分项时，才值得用持续运算的方式重新设计 RAG。

参考资料