这个提示词用来做什么

文档每周都在变，全量重建太贵，增量更新又怕检索到旧版本

提示词全文

你要帮我把一个 RAG 知识库的更新策略拆成可执行的分层方案，目标是「不读到过期内容」和「不每周全量重算」同时成立。

## 输入
文档来源：{类型、数量、平均长度、更新频率、是否有版本号}
当前做法：{全量重建 / 定时增量 / 手动触发；一次全量耗时与费用}
查询特征：{高频问题、是否要求引用到具体版本、能否接受几小时延迟}
合规要求：{是否必须立即反映撤稿 / 价格 / 政策变更}

## 输出
1. 文档分层：按「变更频率 × 查询热度 × 过期代价」分成 3–4 层，每层给出更新触发方式（实时 / 小时 / 日 / 周）和保留版本数。
2. 索引策略：哪些层做全量重建、哪些做增量 upsert、哪些只更新元数据；说明删除与撤稿如何传播，避免旧 chunk 残留。
3. 检索侧：为每层定义过滤条件（版本、生效时间、状态），以及「命中旧版本」时的降级话术；给出引用里必须带的时间戳或版本号。
4. 成本账：按当前文档量和查询量估算每层的 embedding、存储、重建费用，给出月度总额与峰值；指出哪一层最值得优化。
5. 验收：设计 5 条能自动跑的检查，例如「撤稿文档 1 小时内不再被召回」「同一问题引用的版本不早于生效日」。

## 纪律
- 不要把「每天全量重建」当成默认答案，先把过期代价算清楚。
- 删除必须显式处理，不能只做 upsert。
- 如果某类文档无法判断版本，直接标记为高风险，不要猜。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

价格页和产品文档不该用同一个更新频率：价格错一天是事故，产品说明晚一周只是体验问题。分层的第一步是把「过期代价」写出来，而不是先选向量库。

基本信息

  • 分类：工程
  • 标签：RAG · 增量索引 · 成本 · 版本 · 检索
  • 收录日期：2026-10-26

同类提示词