用增量同步减少 RAG 知识库重建开销

RAG 接上向量库之后，还要解决一个容易被低估的问题：文档已经更新，回答却仍在引用旧内容。原文介绍的 Serviette 想用持续监听和增量处理，缩短这段信息滞后的时间，同时减少重复生成向量的开销。

它的思路值得看，但「实时同步」距离「答案正确」还有一段路。作者给出了成本、检索延迟和分块实验，也混入了缺少条件说明的数据库结论与缓存承诺。读这篇，最有用的是分清它解决了哪一层问题。

文档更新后，为什么不必重跑整条流水线

传统批处理式 RAG 会经历文件更新、重新切块、生成 embedding、写入向量库。更新频繁时，等待窗口会持续制造过期上下文。

按原文描述，Serviette 是一个基于 FastAPI 的 RAG 服务，位于文档源和向量库之间。它监听本地目录、Google Drive、Sharepoint 或 S3，只处理发生变化的块，更新期间服务继续运行。

增量同步解决的是知识更新的速度问题。

原文给出的最小启动流程如下，用于配置文档目录、模型密钥和向量库：

pip install pathway[all]

export PATHWAY_DATA_DIR="./documents"
export OPENAI_API_KEY="your-key"
export VECTOR_STORE="qdrant"

python -m serviette.main

要看的是 VECTOR_STORE="qdrant"：这只是选择后端，不能据此认定数据库也完成了部署。原文没有交代 Qdrant 的连接配置和持久化设置。

作者称服务会在 localhost:8000 启动，数秒内发现 ./documents 中的 PDF，使用 text-embedding-3-small 生成向量。它还提供兼容 /v1/chat/completions 的接口，将检索接入对话请求。不过，安装与启动细节没有对应版本，不能直接视为完整的生产部署说明。

真正累积的费用，可能在每次提问时

作者用一份 50 页、约 30K tokens 的技术文档算账：每块 512 tokens，重叠 128 tokens，共计 72 块，embedding 输入为 36,864 tokens。按每百万 tokens 0.02 美元计算，初次向量化约花 0.00074 美元。

提问时取回 top-k 为 5 的结果，会向提示词加入 2,560 tokens。按原文采用的 GPT-4o 输入价格，每百万 tokens 2.50 美元，这部分每次花 0.0064 美元；每天 10K 次查询，就是 64 美元。

这些是原文的计价口径，不能当作当前报价；64 美元也只涵盖检索上下文的输入费用，没有包含问题、系统提示词、输出和基础设施。

作者进一步提出缓存重复上下文，称缓存读取可节省 90% 的 token 成本。在针对稳定的 10 份文档进行的 500 次查询中，他们报告输入费用从 3.20 美元降到 0.48 美元，降幅为 85%。

这里需要拆开看。原文通过 B-Lost 网关调用 client.chat.completions.create，在 extra_body 中传入 rag_context 和 cache_context=True。这些字段不能视为 OpenAI 通用标准参数。文章也没有展示缓存键、前缀组织和失效机制，因此「只让更新块对应的缓存失效」仍缺少实现证据。

向量更新和提示词缓存，是两个需要分别验证的环节。

分块与数据库，都会影响实时检索的效果

Serviette 声称支持八种后端：Qdrant、Weaviate、Milvus、Elasticsearch、LanceDB、Pinecone、Chroma 和 pgvector。接口统一能减少接入工作，运维差异却不会消失。

作者用相同的 5K 文档，比较本地 Qdrant 与托管 Pinecone：前者检索 p95 低于 45ms，后者闲置 10 分钟后的首次查询达到 1.2 秒。这个结果提示我们测试突发流量和冷启动，但本地与托管环境不同，不能据此宣布某个产品普遍更快。

分块同样关键。原文称默认使用 LangChain 的 RecursiveCharacterTextSplitter，窗口为 512 tokens，重叠为 128 tokens。处理带 YAML 示例的 API 文档时，作者换成下面的配置，希望减少代码块被截断：

from pathway.xpacks.llm.splitters import TokenCountSplitter

splitter = TokenCountSplitter(
    min_tokens=256,
    max_tokens=768,
    encoding_name="cl100k_base"
)

要看的是 min_tokens 和 max_tokens：它们体现了长度范围约束，代码本身没有展示识别 YAML 或语义边界的逻辑。作者把它称为「语义分块」，证据并不充分。

他们报告，在人工评估 top-5 相关性时，检索误报减少了 18%。这是特定语料上的实测陈述，原文没有提供样本量、标注标准和完整对照配置。

我的判断

我认可把增量处理作为频繁更新知识库的默认方向。更新一个局部段落就重跑整库，往往会浪费计算，也会拉长新内容可被检索的时间。

但同步成功，不等于跨文档内容已经一致。

例如 auth.md 改了认证方式，quickstart.md 仍保留旧示例，增量系统可能继续检索到后者。这里的问题是源文档互相矛盾。原文认为传统全量重建可以通过依赖分析发现它，但全量重建本身并不自带依赖分析；没有额外规则，把旧示例重新向量化也不会让它自动正确。

因此，「增量更新加周期性全量校验」可以作为方案，但校验必须明确检查版本、引用或内容冲突。作者用 2 秒同步对比 5 分钟重建窗口，更像方案取舍的说明，缺少可复现实验条件。

数据库判断也应保留边界。「Qdrant 在 100K 以下文档最快」「pgvector 超过 500K 向量就需要分区」，都缺少硬件、索引和查询配置。文档数与向量数也不是同一种规模指标。这些可以作为排查方向，暂时不足以指导选型。

能拿来做什么

• 给团队 API 文档搭 RAG 时，可以先选一份频繁修改的文档，记录修改到新内容可被检索的时间，并检查旧块是否已经删除。
• 在 Node 或现有聊天服务接入 /v1/chat/completions 时，应核实流式响应、错误处理和网关扩展字段，避免只凭「兼容」就直接替换接口。
• 为知识库维护一组固定问题，加入 YAML 示例完整性、top-5 相关性和跨文档版本一致性检查，让分块调整有可比较的依据。
• 按实际输入 token 拆分费用，再评估提示词缓存；同时测试稳定语料和频繁更新语料，确认节省金额与缓存失效是否符合预期。