实用提示：如果您的代理嵌入模型即将停止使用该怎么办？
《实用笔记》操作指南：如果您的代理嵌入模型即将停止使用该怎么办？——为采用该模式的团队提供的合同、检查清单及可直接插入的代码模板。
可将此内容视为《如果您的智能体嵌入模型即将过时会怎样？》一文中观点的面向操作员的优化版本：清晰的阶段划分、有序的代码模块，以及能在交接过程中保留的恢复说明。 将“概览”阶段视为可量化的界面使用效果最佳。在扩大范围之前，先记录一份理想的操作日志、一个故障案例以及回滚说明。 在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
Backfill
↓
Validate
↓
Canary
↓
Cut over
↓
Soak
↓
Clean up
问题所在
在“问题分析”阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，以便操作人员无需查看整个流程即可进行审计。 当下一步是代码执行或工具调用时，优先使用具有架构验证的结构化输出，而非自由形式的文本。
1. 历史数据
在“1 历史数据”阶段，修改代码之前需明确输入内容、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 当下一步操作为代码执行或工具调用时，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文本。
2. 实时数据
在“2 Live数据阶段”，在修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 相较于冗长的脚本，更应采用小型、可测试的单元。当某个步骤出现故障时，故障原因应能明确指向某个具体责任方，而非整个复杂的流程。 如果后续步骤是代码调用或工具调用，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文本。 在“2 Live数据阶段”，在修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境过渡到共享环境时出现意外费用。
3. 生产环境流量
在处理三个生产环境流量阶段时，首先写下相关契约：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 缓存系统中稳定的指令和工具架构。重复发送相同的开头信息是导致资源浪费的常见原因。
Historical data → distributed backfill
Live changes → async dual-write
Production traffic → canary + guardrails
首要设计原则：为嵌入内容添加版本控制
在处理“第一个设计规则”阶段时，首先写下相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和故障恢复流程。重试机制、人工审核环节以及错误消息处理都是产品本身的一部分，而非后续的优化工作。 缓存系统中稳定的指令和工具结构。重复发送相同的报文头是导致资源浪费的常见原因。
record
├── namespace
├── knowledge-base version
├── embed_version
└── embedding
CREATE TABLE semantic_cache (
id BIGSERIAL,
embed_version TEXT NOT NULL,
namespace TEXT NOT NULL,
query_hash BYTEA NOT NULL,
embedding vector(...) NOT NULL,
response JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
last_hit_at TIMESTAMPTZ NOT NULL DEFAULT now(),
hit_count INT NOT NULL DEFAULT 0,
expires_at TIMESTAMPTZ NOT NULL,
PRIMARY KEY (embed_version, id)
) PARTITION BY LIST (embed_version);
CREATE TABLE semantic_cache_v1
PARTITION OF semantic_cache
FOR VALUES IN ('gemini-embedding-001');
CREATE TABLE semantic_cache_v2
PARTITION OF semantic_cache
FOR VALUES IN ('text-embedding-3-large');
semantic_cache
│
┌───────────┴───────────┐
│ │
embed_version=V1 embed_version=V2
│ │
V1 vectors V2 vectors
第0阶段 — 填充V2表示形式
在处理阶段0的回填工作时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持透明可追溯。 建议使用小型、可测试的单元而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 缓存系统中稳定的指令和工具结构。重复发送相同的开头信息是导致资源浪费的常见原因。 在处理阶段0的回填工作时，首先需明确合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这样的清单能确保后续的代码修改保持透明可追溯。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
SELECT * FROM semantic_cache;
0.1 创建V2分区
将“0 1 创建阶段”视为可测量的界面来使用效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放，这样操作人员无需查看整个系统结构即可进行审计。 为每轮及每次会话设定预算额度。智能工具往往会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。
V1 partition
│
│ still serving
▼
V2 partition
│
│ being populated
▼
migration control table
0.2 将语料库划分为可管理的范围
将“0 2 Split the stage”视为可度量的流程时效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。同时记录正常流程与恢复流程的细节。重试机制、人工审核环节以及错误处理都是产品本身的一部分，而非后续需要补充的内容。为每轮对话和每次会话设定token预算。智能工具会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。
┌─────────────────────────────────────────┐
│ Migration control table │
├──────────────┬─────────────┬────────────┤
│ Range │ Status │ Worker │
├──────────────┼─────────────┼────────────┤
│ 1 - 50K │ complete │ worker-1 │
│ 50K - 100K │ processing │ worker-2 │
│ 100K - 150K │ pending │ worker-3 │
│ 150K - 200K │ pending │ worker-4 │
└──────────────┴─────────────┴────────────┘
SELECT ...
FOR UPDATE SKIP LOCKED;
0.3 使用键集分页进行获取
将“0 3 Fetch with stage”视为可度量的工作面时效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出现故障时，故障应指向单一责任模块，而非复杂的流程链。 为每轮操作和每次会话设定令牌预算。智能工具会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。 将“0 3 Fetch with stage”视为可度量的工作面时效果最佳。在扩大范围之前，先记录一份理想的执行日志、一个故障案例以及回滚说明。 在功能结果旁同时记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。
SELECT ...
FROM semantic_cache_v1
WHERE id > :last_id
AND id <= :range_end
ORDER BY id
LIMIT :batch_size;
Migration range
≈ scheduling/checkpoint boundary
Embedding batch
≈ model/provider throughput boundary
0.4 通过专用池生成嵌入向量
在“0.4 生成嵌入向量”阶段，应在修改代码之前明确输入内容、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放，以便操作人员无需查看整个流程即可进行审核。 当下一步操作为代码编写或工具调用时，优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文本。
Embedding capacity
│
┌──────────────┴──────────────┐
│ │
online traffic migration traffic
│ │
▼ ▼
production path dedicated pool
0.5 缓冲并控制写入频率
对于0.5缓冲区及处理阶段，在修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程与异常恢复路径。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的功能。 当下一步操作为代码编写或工具调用时，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文字描述。
existing records
│
▼
embedding batches
│
▼
buffer
│
▼
throttled writes
│
▼
V2 partition
0.6 验证每个已完成的范围
在0 6阶段，修改代码之前需验证每个步骤，明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 相较于冗长的脚本，更应采用小型、可测试的单元。当某个步骤失败时，故障原因应能明确指向单一责任方，而非复杂的流程链。 如果后续步骤是代码调用或工具调用，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文字描述。 在0 6阶段，修改代码之前需验证每个步骤，明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境转向共享环境时出现意外费用。
write range
│
▼
validate
│
┌──┴────┐
PASS FAIL
│ │
▼ ▼
checkpoint retry
complete │
▼
persistent failure
│
▼
halt + alert
0.7 构建 V2 索引
在处理“0 7 构建”阶段时，首先明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改不会出错。 将配置信息与应用程序代码分开。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 缓存稳定的系统指令和工具架构。重复发送相同的开头信息是导致资源浪费的常见原因。
V1
├── existing data
└── existing index
V2
├── migrated data
└── new index
第一阶段 —— 生产环境部署前验证 V2
在开展第一阶段“验证V2”工作时，首先需明确合同规范：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合要求。同时要将正常流程与故障恢复流程都记录下来。重试机制、人工审核环节以及错误消息处理都是产品本身的一部分，而非后续需要补充的功能。
row_count(V1) == row_count(V2)
retrieval_quality(V2) < retrieval_quality(V1)
Golden-set query
│
├──────────────► V1 retrieval
│
└──────────────► V2 retrieval
│
▼
quality comparison
Golden-set evaluation
│
┌───┴───┐
PASS FAIL
│ │
▼ ▼
Canary Stop
tune
第二阶段——新路径的灰度测试
在开展第二阶段测试时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合预期。 建议使用小型、可测试的单元，而非冗长的脚本。当某个步骤出现故障时，故障应指向单一责任模块，而非复杂的流程链。 缓存系统中稳定的指令和工具结构。重复发送相同的开头信息是导致资源浪费的常见原因。 在开展第二阶段测试时，首先需明确相关规范：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改始终符合预期。 在记录功能结果的同时，还需标注执行时间以及令牌或查询的成本。提前了解成本情况，可避免在系统从演示环境过渡到共享环境时出现意外费用。
1% → 10% → 50% → 100%
2.1 请求路径
在将请求阶段视为可度量的对象时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。 应将配置与应用程序代码分开。环境文件、密钥存储和功能标志应集中存放于一处，这样操作人员无需查看整个系统结构即可进行审计。 为每轮对话和每次会话设定预算令牌限制。智能工具往往会大量消耗上下文资源，设置上限可避免演示过程突然产生额外费用。
Incoming query
│
▼
L1 cache
│
┌──┴───┐
HIT MISS
│ │
▼ ▼
return V2 embedding
│
▼
V2 retrieval
│
▼
quality check
┌──┴───┐
strong weak
│ │
▼ ▼
RAG fallback V1
│ │
└──┬────┘
▼
response
版本感知检索
将“版本感知检索”阶段视为可度量的指标时，其效果最佳。在扩大范围之前，先记录一个成功的案例、一个失败案例以及回滚说明。同时记录正常流程与恢复流程的细节。重试机制、人工审核环节以及错误处理都属于产品功能的一部分，而非后续需要补充的内容。需为每轮对话和每次会话设定token预算。智能工具往往会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。
namespace
+
knowledge-base version
+
embedding version
namespace = customer-A
kb_version = 42
embed_version = V2
2.2 质量管控标准
将“2×2质量防护栏”阶段视为可度量的对象来使用效果最佳。在扩大范围之前，先记录一份理想案例、一个故障实例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某一步骤出现故障时，故障应指向单一责任主体，而非复杂的流程链。 为每轮及每次会话设定预算额度。智能工具会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。 将“2×2质量防护栏”阶段视为可度量的对象来使用效果最佳。在扩大范围之前，先记录一份理想案例、一个故障实例以及回滚说明。 在功能结果旁同时记录执行时间以及Token或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。
系统健康状况
在系统健康检查阶段，应在修改代码之前明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审计。 当下一步操作为代码执行或工具调用时，应优先使用具有架构验证的结构化输出，而非自由形式的文本描述。
数据检索质量
在检索质量阶段，修改代码之前需明确输入内容、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续需要补充的功能。 当下一步操作为代码编写或工具调用时，应优先使用具有架构验证的结构化输出，而非自由形式的文本。
迁移健康状况
在迁移健康检查阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 相较于冗长的脚本，更应采用小型、可测试的单元。当某个步骤失败时，故障原因应能明确指向某个具体责任方，而非整个复杂的流程。 如果后续步骤是代码调用或工具使用，应优先选择具有结构化格式且经过模式验证的输出，而非自由形式的文本。 在迁移健康检查阶段，修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测其中的隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境过渡到共享环境时出现意外费用。
1%
│
▼
guardrail
│ PASS
▼
10%
│
▼
guardrail
│ PASS
▼
50%
│
▼
guardrail
│ PASS
▼
100%
2.3 回滚必须是配置变更
在处理“回滚必须是配置变更”这一阶段时，首先需明确相关要求：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改符合规范。 应将配置信息与应用程序代码分开存放。环境文件、密钥存储以及功能开关应集中管理，以便操作人员无需查看整个系统结构即可进行审计。 需缓存系统中稳定的指令和工具架构。重复发送相同的开头信息是导致资源浪费的常见原因。
stop traffic
restore data
redeploy services
rebuild indexes
hope
active embed_version = V2
│
▼
config change
│
▼
active embed_version = V1
回填过程中的竞争问题：实时更新该如何处理？
在处理“回填期间的竞赛”阶段时，首先写下合同条款：所需的输入参数、成功信号以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程和恢复流程。重试机制、人工审核环节以及死信处理都是产品本身的组成部分，而非后续的优化工作。 缓存稳定的系统指令和工具架构。重复发送相同的报文头是导致资源浪费的常见原因。
10:00 worker reads record A
10:01 record A is updated
10:02 worker writes V2 generated from the older content
application write
│
┌───────┴───────┐
│ │
▼ ▼
V1 write async queue
│
▼
V2 write
第三阶段 —— 反转读取路径
在完成第三阶段的“翻转阶段”工作时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 建议使用小型、可测试的单元，而非庞大的脚本。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 缓存系统中稳定的指令和工具结构。重复发送相同的开头信息是导致资源浪费的常见原因。 在完成第三阶段的“翻转阶段”工作时，首先需明确相关约定：所需的输入参数、成功信号以及部分失败时的处理方式。这份清单能确保后续的代码修改保持一致性。 在功能结果旁记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外费用。
Before:
reads → V1
After:reads → V2
第四阶段 — 翻转后的稳定测试
在第四阶段“翻转后浸泡”步骤中，若将其视为可测量的表面来处理效果最佳。在扩大范围之前，先记录一份成功的案例、一个失败案例以及回滚说明。 将配置置于应用程序代码之外。环境文件、密钥存储和功能标志应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 为每轮及每次会话设定预算令牌限制。智能工具往往会大量消耗上下文资源，设置上限可避免演示过程突然产生额外费用。
第五阶段 — 最终验证与清理
将第五阶段的最终验证视为可度量的指标来处理效果最佳。在扩大范围之前，先记录一份完美的测试用例、一个故障案例以及回滚说明。同时记录正常流程和恢复流程的文档。重试机制、人工审核环节以及错误处理都是产品本身的一部分，而非后续需要补充的内容。为每轮对话和每次会话设定预算额度。智能工具会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。
1. 停止V1的双重写入
将“1 Stop V1双写阶段”视为可度量的工作面时，其效果最佳。在扩大范围之前，先记录一份理想的处理结果、一个故障案例以及回滚说明。 优先选择小型且可测试的单元，而非庞大的脚本。当某个步骤出现故障时，故障应指向单一责任主体，而非复杂的流程链。 为每轮操作和每次会话设定预算额度。智能工具往往会大量消耗上下文资源，设置上限可避免演示过程变成意外的费用账单。 将“1 Stop V1双写阶段”视为可度量的工作面时，其效果最佳。在扩大范围之前，先记录一份理想的处理结果、一个故障案例以及回滚说明。 在功能结果旁同时记录处理时间以及Token或查询成本。提前了解成本情况，可避免在从演示环境过渡到共享环境时出现意外账单。
2. 执行最终验证
在第二个运行阶段的最终验证中，应在修改代码之前明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 配置信息应置于应用程序代码之外。环境文件、密钥存储以及功能标志应集中存放于一个位置，以便操作人员无需查看整个系统结构即可进行审核。 当后续步骤为代码调用或工具调用时，应优先使用具有架构验证的结构化输出，而非自由形式的文本。
V2
│
▼
final validation
│
├── FAIL → stop cleanup
│
└── PASS
│
▼
continue cleanup
3. 删除 V1 表示形式
对于“删除V1版本”这一阶段，在修改代码之前需明确输入参数、该步骤的负责人以及结束标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 需同时记录正常流程和异常恢复流程。重试机制、人工审核环节以及错误处理都是产品本身的组成部分，而非后续需要补充的内容。 当下一步操作为代码编写或工具调用时，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文字描述。
Backfill
↓
Validate
↓
Canary
↓
100% V2
↓
Soak
↓
Final validation
↓
Delete V1
完整的生命周期
在“完整生命周期”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 相较于冗长的脚本，更应采用小型、可测试的单元。当某一步骤失败时，故障原因应能明确指向某个具体责任方，而非整个复杂的流程。 如果后续步骤是代码调用或工具调用，应优先使用具有结构化格式且经过模式验证的输出，而非自由形式的文字描述。 在“完整生命周期”阶段，修改代码之前需明确输入参数、该步骤的负责人以及终止标准。操作人员应能够从已知的检查点重新运行该步骤，而无需猜测隐藏状态。 除了功能结果外，还需记录执行时间以及令牌或查询成本。提前了解成本情况，可避免在流程从演示环境过渡到共享环境时出现意外费用。
EMBEDDING MIGRATION
│
▼
Create V2 storage
│
▼
Backfill V2
work stealing + retries
│
▼
Range validation
│
▼
Build V2 indexes
│
▼
Golden-set evaluation
│
┌──────┴──────┐
FAIL PASS
│ │
▼ ▼
stop/tune Canary
1% → 10% → 50%
│
▼
Guardrails
│
▼
100% V2
│
▼
Read flip
│
▼
V2 soak
│
▼
Final validation
│
▼
Drop V1
Live production writes
│
▼
V1 write
│
└──── async dual-write → V2
Migration safety
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Data Quality Traffic
safety safety safety
│ │ │
checkpoints golden set canary
retries guardrails fallback
validation evaluation rollback
可推广的教训
在处理“可推广的教训”这一阶段时，首先需列出相关约定：所需输入、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 应将配置信息置于应用程序代码之外。环境文件、密钥存储以及功能开关应集中存放于一个位置，这样操作人员无需查看整个系统结构即可进行审计。 需缓存稳定的系统指令和工具架构。重复发送相同的前置信息是导致资源浪费的常见原因。
1. 将嵌入版本视为核心概念
在完成“1. 构建嵌入版本”阶段时，首先需明确相关约定：所需的输入参数、成功信号，以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改保持一致性。 同时记录正常流程与异常恢复流程。重试机制、人工审核环节以及死信处理都是产品功能的一部分，而非后续需要补充的内容。 缓存系统中稳定的指令和工具结构。重复发送相同的开头信息是导致资源浪费的常见原因。
2. 以数据库工程师的方式补全数据
在将“回填”分为多个阶段进行处理时，首先需明确合同条款：所需的输入参数、成功标志以及部分失败时的处理方式。这样的检查清单能确保后续的代码修改始终符合要求。 相比庞大的脚本，应优先选择小型且可测试的单元。当某个步骤失败时，故障应指向单一责任模块，而非复杂的流程链。 缓存系统中稳定的指令和工具结构。重复发送相同的开头信息是导致资源浪费的常见原因。
3. 将数据迁移与流量迁移分开
V2 exists
≠
V2 is trusted
≠
V2 is serving production
4. 将数据检索质量视为正确性的组成部分
Data correctness
+
Retrieval quality
+
Production health
5. 保留旧路径作为安全网
6. 让回滚操作变得繁琐
change configuration
change code + redeploy + restore state
7. 最后删除内容
核心要点
model identity
+
vector storage
+
traffic routing
Partition
↓
Backfill
↓
Validate
↓
Canary
↓
Cut over
↓
Soak
↓
Clean up