工具边界与
生产级 RAG

完成本课后，你应该能设计两条可信链

核心结论：一套生产级问答系统既要证明数据来源可靠，也要证明外部动作真实、合规地发生。

模型说“我查过了”，但系统没有任何调用记录

核心结论：模型描述自己执行过工具，不代表工具真的被调用；没有审计记录的动作在生产上等于没有发生。

生产回答必须通过两条可信链

核心结论：Tool Loop 证明“动作真的执行”，RAG Pipeline 证明“答案真的有依据”。

Tool Call 是执行建议，不是执行结果

核心结论：LLM 输出的 tool name 和 arguments 只是非可信输入，必须像外部 API 请求一样验证。

每个工具至少定义六个边界

不能让模型“自导自演”工具结果

核心结论：模型既提出调用又编造执行结果，会绕过权限、业务规则和审计。

proposal → validate
→ execute in code
→ append tool result
→ model summarizes

标准 Tool Loop 是一个受控往返

核心结论：每一轮都要重新检查停止条件和调用预算，不能让模型无限调用。

Safe Tool Loop：退款资格核查

核心结论：基础项目用最少代码展示“模型建议、注册表验证、代码执行、结果回填”。

“查过了”必须能展开成证据链

BAD  > Refund is approved. I checked the order.

GOOD > proposed_calls: [order_status, refund_eligibility]
audit: [validated, executed_by:code]
can_promise_refund: true
answer: Submit the refund request.

失败不是一律重试，而是分类处理

RAG 的目标不是“搜到文档”，而是让结论有依据

核心结论：召回只是候选证据生成；只有相关、权威、时效正确且能支持结论的片段才能进入回答。

Top-1 相似，不代表足以回答

核心结论：语义相似度衡量“像不像”，不衡量文档是否权威、是否过期、是否完整支持问题。

生产检索是一条漏斗，不是一次向量查询

引用不是装饰，而是答案的约束结构

RAG 不知道时，系统必须允许它说不知道

核心结论：强迫模型始终给出答案，会把检索失败伪装成确定结论。

{
 "evidence_status": "partial",
 "answer": "需要核查订单状态",
 "citations": ["runbook-01"],
 "needs_handoff": true
}

Production Tool Loop + RAG Pipeline

核心结论：进阶项目把工具注册表、查询改写、混合信号、重排、引用和人工转接放进一条可测试链路。

同时验证动作正确和证据正确

工具与知识库都要做最小权限

一次回答要能还原完整决策过程

先证明系统会拒绝，再证明系统会回答

上线前，检查八个关键问题