OPENING30 秒开口版
我会把可信结果设计成 Query OS 的 Grounded Answer + Replay，而不是让模型直接给结论。Text2SQL 的 final SQL 只是可验证执行产物，answer 只能基于 question、finalSql、columns、rows、assumptions、metric definitions used 和 selected evidence 生成；RAG 负责提供来源、公告、指标口径和语义证据；validate 负责 plan、AST、只读、权限、方言、limit 和 dry-run；delivery 统一交付 answer、evidence、SQL artifact、data pack、riskTags 和 runId。这样老板看到的是结论，下游报告 Agent 拿到的是可复用数据包，工程团队能按 runId 回放 selected context、plans、SQL、validation、execution 和 answer。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Grounded Answer：只基于执行结果和记录假设生成的回答。 Evidence Chain：从用户问题到 selected context、plans、SQL、来源、结果、回答的完整证据链路。 Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。 Text2SqlReplay：用 runId 串起 trace、RAG replay、plans、validation、delivery 和报告引用。 |
| 为什么这样回答 | 先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。 |
| 小白解析 | 像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。 |
| 关联知识点 | text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。 |
1 MIN一分钟口语版
展开讲，我会先把“可信”拆成五层。第一层是上下文可信，SelectedContextPack 只能包含授权后的 schema、metrics、relationships、examples 和 evidence。第二层是计划可信，SemanticPlan 和 PhysicalSqlPlan 要绑定指标口径、join path、时间窗口和 evidenceRefs。第三层是执行可信，final SQL 必须通过 plan validation、AST、readonly、ACL、limit、dry-run 和 semanticPlanMatched。第四层是回答可信，Grounded Answer 只能使用 rows、columns、SQL、assumptions 和已记录证据，不补结果集外的事实。第五层是复用可信，delivery.evidence 包含 runId、semanticVersion、policyVersion、selectedEvidenceIds、artifactRefs、riskTags 和 degradeReasons，下游报告 Agent 只引用 data pack 和 source runId。这样一个答案不只是“像真的”，而是能说明用的哪些表、哪些来源、哪个时间点的数据，以及哪些地方置信度不足。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。 Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。 Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。 runId：一次运行的诊断主键，用来串起 trace、replay、delivery 和报告引用。 |
| 为什么这样回答 | 先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。 |
| 小白解析 | 像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。 |
| 关联知识点 | text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。 |
ARCHITECTURE架构设计要点
事实层
结构化事实来自 SQL 执行结果，融资、Token、评分、解锁等字段必须能追到表和列。
来源层
RAG 召回公告、新闻、source_documents、指标定义，证明结论不是模型记忆。
治理层
SQL 通过 validate，权限、只读、字段可见、执行成本和风险标签都进入证据。
交付层
answer、evidence、artifact、data pack 和 runId 同时交付，服务人和下游 Agent。
冲突层
结构化表和来源文档冲突时，不静默选择，而是标记 conflict 和 source priority。
复用层
报告 Agent 引用 data pack，不重新拼 SQL，也不抹掉 runId。
DIAGRAM架构图
可信结果从哪里来
冲突和置信度收口
TABLE关键对象和面试讲法
| 对象 | 职责 | 面试强调 |
|---|---|---|
| runId | 全链路诊断主键 | 报告 Agent 引用数据包时必须保留。 |
| semanticPlan | 指标、实体、时间窗口、路由约束 | 证明 SQL 不是临场猜出来的。 |
| SQL artifact | SQL、列、行数、预览结果 | 证明结构化数据如何得出。 |
| selectedContext | 入模证据和选择理由 | 证明 RAG 给了哪些材料。 |
| sourceDocuments | 公告、新闻、官方来源 | 证明事实出处。 |
| riskTags | 低置信、降级、冲突、过期 | 证明系统知道不确定性。 |
| data pack | 表格、图表规格、引用来源 | 给下游报告 Agent 稳定复用。 |
REPLAY LEDGERrunId 可回放对象
| 回放对象 | 必须保存什么 | 能回答的质疑 |
|---|---|---|
| trace | 节点状态、输入输出摘要、latency、degradeReasons、riskTags | 这次运行到底走到哪一步，是否发生降级。 |
| RagReplay | query rewrite、lexical/dense/graph 候选、RRF、rerank、selectedEvidenceIds | 关键证据有没有找回，为什么没进入 selected context。 |
| semanticPlan | entities、metrics、filters、timeRange、joinPaths、routePlan、semanticVersion | SQL 是否来自正确业务口径，而不是模型临场猜。 |
| SQL artifact | SQL、tables、columns、row count、preview、execution summary、costEstimate | 结构化结论怎么查出来，是否查错表或结果异常。 |
| validationSummary | AST parsed、readonly、permission decision、dryRunStatus、reasonCode、correctable | 有没有越权、危险 SQL、方言失败或语义不匹配。 |
| delivery.evidence | sourceRefs、artifactRefs、policyVersion、selectedTables、selectedColumns、riskTags、degradeReasons | 报告 Agent 半年后引用这段结论，还能不能追溯到当时事实。 |
面试里要把 runId 说成事实锚点，而不是日志编号。没有 source runId，下游报告 Agent 的段落、图表和数据包出错时无法归因。
INTERVIEW MAP面试表达地图
- 先定义可信不是模型自信，而是数据、来源、校验、回放四层可信。
- 再讲对象runId、evidence、artifact、semanticVersion、riskTags。
- 落到场景融资、Token 解锁、热度评分、项目基本面都要有来源。
- 强调冲突结构化表和来源文档冲突时要显式暴露。
- 收束复用下游报告 Agent 只复用 data pack，不绕过系统 Agent。
SUBAGENTS面试官、候选人和红队
本章写作前已实际启动多 subagent：面试官 subagent 负责连续追问生产压力，候选人 subagent 负责把答案压成现场能讲出口的表达，资料审阅 + 红队 subagent 负责指出哪些地方容易写虚，并补充安全、评测、runId、下游报告 Agent 的攻击面。
本章追问重点：所有回答都要落到 RootData 类 Web3 主项目、Agent Bot、Text2SQL、RAG、runId/evidence/artifact/data pack 和下游报告 Agent 复用。
Q&A20 组高强度追问
面试官：你说结果可信，怎么证明不是模型编的？第二层追问：给我看一次 runId 能回放哪些东西。
我：我会从 runId 回放讲。一个 runId 能看到 QuerySlots 是什么，SelectedContextPack 里有哪些授权表列、指标、关系和 evidence，SemanticPlan/PhysicalSqlPlan 怎么约束 SQL，ValidationReport 里 plan/AST/ACL/dry-run 是否通过，artifact 里 final SQL、columns、rows 和预览结果是什么，delivery.evidence 里有哪些 riskTags、semanticVersion、policyVersion 和 source refs。只要这些证据对不上，或者 answer 超出了 rows/columns/evidence，我就不会把它当成高可信。
runId、trace、replay 与回放：可信结果章主讲 runId 可回放，架构、流程、时效和可观测章只从各自链路补充。
理解与记忆 · 背后工程点
背后工程点：可信结果的核心是证据对象可对齐，而不是回答文本流畅。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：SQL 执行成功就代表业务正确吗？
我：不代表。SQL 成功只能说明语法和执行通过，还要看 semantic-plan 里的指标口径、join path、时间窗口、权限范围是否正确。比如“融资强”如果口径错成融资次数而不是金额和投资人质量，SQL 再成功也是错答案。
理解与记忆 · 背后工程点
背后工程点：要区分可执行正确和业务语义正确。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：如果 SQL 查到了融资数据，但 RAG 没有找到公告来源，你怎么展示？
我：我会把结构化结果正常展示，但在 evidence 里标记 source evidence incomplete，降低置信度，并提示部分融资事件缺少公告来源。报告 Agent 复用时也会看到 riskTags，不能把它写成完全确认的事实。
理解与记忆 · 背后工程点
背后工程点：缺来源不是静默通过，而是进入风险标签和交付说明。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：融资金额、投资机构、Token 解锁这些字段证据级别怎么分？
我：我会按来源权重分层：官方公告、链上或交易所公开数据优先，权威媒体和数据供应商次之，社区提交或未验证内容只能做候选。结构化字段要保留 sourceDocumentId 和 collectedAt，回答时能引用最强证据。
理解与记忆 · 背后工程点
背后工程点：高风险字段需要 source priority 和来源留痕。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：老板问“AI x Crypto 最近融资强的未 TGE 项目”，你如何证明排序依据？
我：我会在 artifact 中保留排序列，比如 funding_amount_30d、lead_investor_tier、heat_growth_7d、token_status，并在 evidence 里说明默认时间窗口和 semanticVersion。排序不是模型主观判断，而是由指标口径和 SQL 结果共同决定。
理解与记忆 · 背后工程点
背后工程点：排序依据必须结构化，否则结论容易变成主观推荐。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：delivery.evidence 里必须有什么，才能给报告 Agent 引用？
我：至少要有 runId、selectedEvidenceIds、selectedTables、selectedColumns、semanticVersion、retrievalStatus、riskTags、degradeReasons 和 artifactRefs。报告 Agent 拿到这些才知道数据能不能引用、怎么引用、风险在哪里。
证据链、data pack 与报告可追溯：可信结果章主讲 evidence/data pack 合同，其他章只补充报告 Agent 消费与复用场景。
理解与记忆 · 背后工程点
背后工程点：给下游 Agent 的不是一段文本，而是可追踪合同。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：如果下游报告 Agent 复用了你的数据包，怎么保证报告可追溯？
我：data pack 里必须包含 source runId、生成时间、semanticVersion、SQL artifact、evidence refs 和数据快照摘要。报告里的图表或段落引用这份数据时，也要保留 runId，这样可以反查原始系统 Agent 运行。
证据链、data pack 与报告可追溯：可信结果章主讲 evidence/data pack 合同，其他章只补充报告 Agent 消费与复用场景。
理解与记忆 · 背后工程点
背后工程点：报告可追溯依赖 runId 传递，而不是报告文本自己声明。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：RAG 证据和结构化表数据冲突，系统听谁的？
我：不会简单听某一边。我会按 source priority、更新时间、字段可信级别判断，并把冲突放进 conflictHint。比如表里融资金额是旧值，官方公告更新了金额，就提示冲突并优先官方来源，同时触发数据修复。
数据冲突、来源优先级与时效性：时效一致章主讲多源冲突和 source priority，RAG 与可信结果章只补充证据侧处理。
- 12-freshness-source-consistency · q01
- 03-rag-optimization · q06
- 03-rag-optimization · q17
- 07-trustworthy-results-evidence-chain · q18
- 12-freshness-source-consistency · q05
- 12-freshness-source-consistency · q11
- 12-freshness-source-consistency · q13
- 12-freshness-source-consistency · q14
- 12-freshness-source-consistency · q18
理解与记忆 · 背后工程点
背后工程点：冲突处理要显式化，不能让模型私下选择。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：结果置信度是模型自己打分吗？
我：不是单纯模型打分。置信度来自 selected context 是否覆盖 gold evidence、plans 是否有 evidenceRefs、SQL validation 是否通过、execution result 是否完整、source priority 和 freshness 是否可靠、answer 是否忠于 rows/columns，以及是否有降级或冲突。模型可以参与解释，但不能单独决定可信等级。
理解与记忆 · 背后工程点
背后工程点：置信度应由系统信号合成。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：如何避免模型把背景材料说成事实来源？
我：RAG context 会标注 docType、source、verified 状态和引用范围。answer 阶段只能引用 selected evidence 里的事实，背景材料只能作为解释，不允许升级成事实来源。
理解与记忆 · 背后工程点
背后工程点：需要区分背景知识和可引用证据。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：空结果怎么可信地解释？
我：空结果也要有证据。系统要说明用了哪些筛选条件、哪些表、哪个时间窗口，判断是确实没有匹配、权限不可见，还是数据缺失。不能直接说“没有项目”，要说明“不在当前权限和当前数据版本下找到”。
空结果解释、评测与排查：可信结果章主讲空结果怎么可信解释，评测和可观测章分别处理验证与排查。
理解与记忆 · 背后工程点
背后工程点：空结果要区分真实为空、权限过滤和数据缺失。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：如果索引版本缺失或 replay 不完整，还能交付吗？
我：可以交付降级结果，但不能标成高可信。delivery.evidence 会标记 replay.ready=false 或 indexVersion missing，报告 Agent 只能把它当临时分析，不适合进入正式报告。
runId、trace、replay 与回放：可信结果章主讲 runId 可回放，架构、流程、时效和可观测章只从各自链路补充。
理解与记忆 · 背后工程点
背后工程点：观测证据不完整会影响交付等级。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：图谱关系能不能直接作为事实？
我：不能。Graph lane 返回的是关系路径线索，比如共同投资路径，最终还要回到 funding_participants、organizations 和来源文档。图路径没有原文或结构化证据支撑时，只能做候选，不做事实结论。
理解与记忆 · 背后工程点
背后工程点：GraphRAG 的关系必须被事实证据支撑。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：自然语言答案和 SQL artifact 不一致怎么办？
我：以 artifact 和执行结果为准，answer 要重新生成或标记 formatting failure。这个问题通常出在 answer 阶段，不应该回滚 SQL 结果，而是用 runId 定位格式化或总结错误。
理解与记忆 · 背后工程点
背后工程点：答案文本是交付层，不能覆盖事实层。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：你怎么防止报告 Agent 改写证据后失真？
我：报告 Agent 只能拿 data pack、chart spec、引用列表和可写作摘要，不能修改底层 evidence。最终报告如果生成新结论，需要重新调用系统 Agent 或标注为报告侧推断。
证据链、data pack 与报告可追溯：可信结果章主讲 evidence/data pack 合同，其他章只补充报告 Agent 消费与复用场景。
理解与记忆 · 背后工程点
背后工程点：系统 Agent 和报告 Agent 的责任要分开。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：可信链路会不会让回答变慢？
我：会有开销，所以我会按问题复杂度分层。简单查数只保留必要 evidence，复杂投研和报告 data pack 才完整保留来源、图谱、回放和 chart spec。可信不是无限堆证据，而是按风险配置证据深度。
理解与记忆 · 背后工程点
背后工程点：可信度和延迟要分级权衡。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：如果用户只要一句结论，还需要 evidence 吗？
我：需要，只是默认折叠。老板端可以先看结论，点击展开看到来源和 SQL artifact；报告 Agent 调用接口则必须拿完整 evidence。人机界面可以简洁，底层合同不能省。
理解与记忆 · 背后工程点
背后工程点：展示可以轻，交付合同要完整。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：你怎么设计 evidence stale？
我：我会用 source publishedAt、collectedAt、indexVersion activatedAt、score snapshot time 和 cache TTL 判断。超过时效或与结构化更新时间不一致，就打 stale evidence 标签，并触发索引刷新或人工复核。
数据冲突、来源优先级与时效性：时效一致章主讲多源冲突和 source priority，RAG 与可信结果章只补充证据侧处理。
- 12-freshness-source-consistency · q01
- 03-rag-optimization · q06
- 03-rag-optimization · q17
- 07-trustworthy-results-evidence-chain · q08
- 12-freshness-source-consistency · q05
- 12-freshness-source-consistency · q11
- 12-freshness-source-consistency · q13
- 12-freshness-source-consistency · q14
- 12-freshness-source-consistency · q18
理解与记忆 · 背后工程点
背后工程点：过期证据是可信链路的一部分。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：线上用户质疑答案，你的排查顺序是什么？
我：先拿 runId 看 status 和 delivery，再看 trace 最后节点；如果 SQL 成功，看 artifact 和 semanticPlan；如果证据不足，看 RAG replay；如果权限问题，看 permission filtering 和 validate 结果。
理解与记忆 · 背后工程点
背后工程点：排查顺序要按证据层级推进。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
面试官：一句话总结可信结果设计。
我：我的设计是让每个结论都能回到 selected context、semantic/physical plan、final SQL、columns、rows、metric definitions、来源文档、权限校验和 runId，而不是让模型凭语气说服用户。可信不是“回答得像专家”，而是可验证、可引用、可回放。
理解与记忆 · 背后工程点
背后工程点：面试结尾要把可信收束成工程原则。
专业术语：Evidence Chain：从用户问题到 SQL、来源、结果、回答的完整证据链路。
Delivery Evidence：最终交付里给人和下游 Agent 复查的检索、语义、风险和来源摘要。
Artifact：SQL、列、行数、预览结果、图表规格或数据包等可复用产物。
为什么这样回答：先定义可信边界，再讲对象和回放，能把回答从“我相信模型”拉回工程证据。
小白解析：像写研究报告一样，不能只给结论，还要留下引用、表格、计算过程和版本号。以后别人质疑时，可以顺着编号找回当时用过的材料。
关联知识点：text2sql 文档强调 delivery.answer、delivery.evidence、artifactRefs、run.trace.v2 和 RAG replay。learn-RAG 也强调先证明关键证据被找回，再讨论生成质量。
PRINCIPLE本章背诵原则
- 可信不是模型自信，而是 selected context、plans、SQL、rows、evidence 可回放。
- SQL 成功不等于业务正确，语义计划、指标口径和 answer faithfulness 也要可验证。
- 答案必须 grounded，只能基于 final SQL、columns、rows、assumptions 和 evidence。
- 下游报告 Agent 复用的是 data pack 和 source runId，不是无来源文本。
- 冲突、过期、降级都是 evidence 和 replay 的一部分。