AI 产品后端 — RAG、Agent loop 服务化与人机协同AI Product Backend: RAG, Agentic Loops, Embedding Serving, Human-in-the-loop

问题场景 + 需求约束

为 50 万企业用户做一个「文档问答 + Agent 助手」后端：用户问问题，系统检索内部知识库回答；复杂任务（「把这三份合同的差异整理成表格并发邮件」）交给 agent 多步执行。这不是套个 LLM API 就完事——它同时是个检索系统、一个长任务编排系统、还要把不确定的模型输出关进可控的工程边界里。

• 规模：知识库 1 亿 chunk（约 2000 万文档切块），向量 1024 维；问答峰值 2000 QPS，agent 任务并发 5000 路。
• 延迟：问答 p95 首 token < 1.5s（检索预算 ≤ 300ms）；agent 任务可跑数秒到数分钟，但要能断点续跑。
• 正确性：答案必须有出处（可溯源到 chunk），高风险动作（发邮件、改数据）要人确认。
• 成本：LLM token 是大头，检索召回的 context 越长越贵——召回质量直接换算成钱。

高层架构

三条主线：① 问答热路径走「检索→融合→重排→流式生成」，预算紧；② Agent 路径走持久化执行引擎，能跑很久、能中断恢复；③ 离线 Ingest 把文档变成可检索的向量+倒排，与在线解耦。下面拆四个关键技术点。

关键技术点

① RAG 检索质量 — 召回烂，模型再强也救不回来

一句话 trade-off：朴素切块嵌入便宜但召回差，contextual + hybrid + rerank 召回好但贵且慢。

【原理】RAG 的瓶颈几乎从来不是生成，而是检索召回——模型只能基于你喂给它的 chunk 回答，没召回到的内容等于不存在。朴素做法把文档按 512 token 切块、各自嵌入，问题是切块丢了上下文：一段写「该方案延迟降低 40%」，但「该方案」指谁、在哪份文档，孤立 chunk 里看不出来，语义检索就召不准。Anthropic 的 Contextual Retrieval 在每个 chunk 前拼一段 LLM 生成的「这段在讲什么」上下文摘要再嵌入，并叠加 BM25 关键词检索做 hybrid。

# 在线检索：hybrid 召回 + 重排（伪代码）
q_vec = embed(query)                      # query 向量化
dense = vdb.ann_search(q_vec, k=100)      # 语义召回 top-100
sparse = bm25.search(query, k=100)        # 关键词召回 top-100
fused = rrf(dense, sparse)                # 倒数排名融合，去重
top = cross_encoder.rerank(query, fused)[:8]  # 精排留 8 个最相关
context = "\n\n".join(c.text for c in top)
answer = llm.stream(prompt(query, context))   # 带出处流式生成

② Agent Loop 服务化 — 把「跑很久还会崩」的循环变成可恢复的工作流

一句话 trade-off：内存态 loop 简单但进程一挂全丢，持久化执行可恢复但要把每步状态落盘。

【原理】Agent 是个循环：调模型 → 模型要求调工具 → 执行工具 → 把结果喂回 → 再调模型，直到完成。问题在于这循环可能跑几分钟、几十步，期间任何一步都可能：进程被部署重启、工具超时、模型 503。如果状态只在内存里，崩一次整个任务从头再来——而每一步都烧了真金白银的 token。解法是持久化执行（durable execution）：把每一步的输入输出当成事件落盘，崩溃后从最后一个成功 step 重放恢复，已完成的工具调用不重跑（靠幂等键）。这正是 Temporal / AWS Step Functions 这类引擎的核心价值。

# 持久化 agent 循环（durable workflow 伪代码）
def agent_workflow(task):
    history = [user_msg(task)]
    for step in range(MAX_STEPS):             # 防失控的硬上限
        resp = activity.call_llm(history)     # 落盘；崩溃重放不重算
        if resp.is_final:
            return resp.text
        for call in resp.tool_calls:
            # 幂等键 = (workflow_id, step, tool, args_hash)
            result = activity.run_tool(call, idem_key=key(step, call))
            history.append(tool_result(call, result))
    raise StepLimitExceeded   # 触发降级/转人工

③ Embedding 服务设计 — 模型版本与索引版本必须绑死

一句话 trade-off：在线实时嵌入延迟低但贵，批量嵌入吞吐高但有延迟；最大的坑是换模型 = 整库重嵌入。

【原理】Embedding 服务有两类流量：在线（query 向量化，要快，可缓存）和离线（ingest 批量嵌入 1 亿 chunk，要吞吐）。两者该分开部署：在线服务小批量低延迟，离线服务大 batch 打满 GPU。关键约束是同一个向量空间——query 和 doc 必须用同一个 embedding 模型嵌入，否则向量没法比较。所以一旦升级 embedding 模型，整个索引必须用新模型重建，且重建期间新旧索引要并存、灰度切换，不能中途混用（混用会让相似度彻底失真）。

# 离线 ingest：批量嵌入 + 双索引灰度（伪代码）
for batch in chunks.stream(size=256):         # 大 batch 打满 GPU
    vecs = embed_offline(batch, model="v3")   # 与在线同一模型族
    new_index.upsert(batch.ids, vecs, meta={"model":"v3"})
# 换模型时：v3 索引后台建好 → 校验召回指标 → 原子切流量 → 删 v2
# 在线 query 端：
@cache(ttl="1h")                              # 热门 query 向量缓存
def embed_query(q): return embed_online(q, model=current_index_model())

④ 人机协同 — 把高风险动作关进审批门

一句话 trade-off：同步阻塞等人简单但占着连接/线程，异步挂起可扩展但要持久化整个 agent 状态。

【原理】模型会犯错，所以不可逆的高风险动作（发邮件、转账、删数据、改生产配置）不能让 agent 自己拍板。模式是 human-in-the-loop：agent 走到高风险工具时不直接执行，而是暂停，把「我打算做 X」推到审批队列，等人批准再继续。难点是「等人」可能等几小时甚至几天——你不能让一个线程/连接傻等。所以它必须建立在技术点 ② 的持久化执行之上：agent 状态落盘、释放所有资源、收到审批回调时从暂停点恢复。

# 高风险工具 → 暂停等审批（durable 伪代码）
def run_tool(call):
    if call.tool in HIGH_RISK:
        approval_id = approvals.create(call)        # 推审批队列
        decision = workflow.wait_for_signal(         # 持久化挂起，可等数天
            approval_id, timeout="3d")
        if decision != "approved":
            return refused(call)                     # 拒绝则不执行
    return execute(call)                             # 批准/低风险才真正执行

扩展与优化

• 语义缓存：相似 query 复用答案（向量近邻命中即返回），高频 FAQ 直接省掉整条检索+生成链路，省钱省延迟。注意失效——知识库更新要让缓存过期。
• 检索分片：1 亿向量单机扛不住，按租户/topic 分片，query 路由到相关分片，避免全库扫描（见 Day 4「分片」）。
• 多级模型路由：简单问题走小模型、复杂任务走大模型，按难度分流降成本（见 Day 32「LLM 服务架构」）。
• 增量 reindex：文档更新走 CDC，只重嵌入变化的 chunk，而非全库重建。
• 评测闭环：建一个固定的「问题→期望出处」黄金集，每次改检索/换模型都跑回归，用召回率/答案正确率守住质量，别凭感觉调参。

常见陷阱 + 面试追问

• 「召回差却怪模型幻觉」：80% 的 RAG 烂答案是没召回到对的 chunk，不是模型瞎编。先量召回率（retrieval recall），再谈生成。
• 「query 和 doc 用了不同 embedding 模型」：相似度变噪声、召回全错且系统不报警——前面讲过的隐形杀手。
• 「agent 状态只在内存」：部署/扩缩容一发生，所有在跑的任务从头再来，token 白烧。长任务必须持久化。
• 「agent 无限循环」：没设 step 上限，模型反复调工具不收敛，烧爆预算。必须有硬上限 + 降级到人工。
• 「高风险动作不可逆还让 agent 自动执行」：发错邮件、删错数据无法回滚。不可逆动作一律 human-in-the-loop。
• 面试追问：「检索预算只有 300ms，hybrid+rerank 跑不完怎么办？」→ 并行召回 dense/sparse、rerank 只精排 top-N、cross-encoder 用蒸馏小模型、热门 query 走语义缓存。

深入资源

• Anthropic — Building Effective Agents：workflow vs agent 的区分、何时该用 agent、人类 checkpoint 等实践。
• Anthropic — Contextual Retrieval：contextual embedding + BM25 + rerank 把检索失败率降约 49%/67%。
• Lewis et al. 2020, Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（NeurIPS）：RAG 范式原始论文。
• 《Designing Data-Intensive Applications》(Kleppmann)：幂等、状态机、可恢复执行的底层原理，对应 agent 持久化执行。
• 本系列 Day 31（混合检索与重排序）、Day 32（LLM 服务）、Day 39（工作流引擎）——本期是这三者在 AI 产品上的合流。

深入思考