企业知识架构与 Data Agent ​

这条链路强调：相关内容被搜到并不等于答案正确，企业知识必须先经过权限、权威性和时效治理，再以证据进入 Agent。

定位：这是七篇正式文档中的第 02 篇。
目标：把“企业知识怎样成为 Agent 可用、可信、可治理的 Evidence（证据）”和“Data Agent（数据智能体）怎样把业务问题变成可信的数据分析链路”连成一套体系。
核心主线：

text

Source of Truth
→ Knowledge Production
→ Authority / Freshness / ACL
→ Retrieval / Routing
→ Evidence
→ Context
→ Agent Reasoning
→ Data / Tool Execution
→ Verification

本篇不是 RAG（Retrieval-Augmented Generation，检索增强生成）教程，也不是 NL2SQL（Natural Language to SQL，自然语言转 SQL）教程。真正要回答的是：企业事实从哪里来、为什么可信、谁有权看、怎样检索、冲突怎么办、怎样验证，以及 Data Agent 为什么远不只是“让模型写 SQL”。

口述原则：继续沿用 00 的高分回答方法。概念题先划 Authority / Lifecycle / Ownership（权威性 / 生命周期 / 归属）；故障题先建立 Root Cause Tree（根因树）；方案题先展开 Option Space（解空间）再做选择；系统设计题先讲 Guarantee（保证）再画组件；项目题严格区分“真实做过 / 正在建设 / 下一阶段架构判断”。

一、先建立整篇主线 ​

1.1 第一性问题：为什么企业 Agent 不能只靠“大模型 + RAG” ​

一个 Demo（演示原型）很容易做成：

Document（文档）
→ Chunk（知识分块）
→ Embedding（向量表示）
→ Vector Search（向量检索）
→ LLM（Large Language Model，大语言模型）

但企业系统很快会遇到：

哪个来源才是正式口径？
这条知识现在还有效吗？
当前用户有权看吗？
两个来源冲突听谁的？
删除后旧 Chunk 还会不会被搜到？
实时数据应该 Search 还是直接 Query？
模型引用的证据能不能复现？

所以真正的 Knowledge Architecture（知识架构）解决的不是：

“怎么把文档搜出来。”

而是：

企业有哪些可以被 Agent 使用的事实；这些事实是谁生产、谁负责、当前是否有效、谁可以访问，以及最终怎样形成可验证 Evidence。

Data Agent 又把这件事进一步放大。

因为企业数据问题往往同时需要：

业务语义
+ 数据源
+ 实时数据
+ 权限
+ 查询
+ 分析
+ 证据

这也是为什么：

Data Agent ≠ Text-to-SQL。

1.2 本篇三个稳定边界 ​

边界一：Relevance 相关性 ≠ Correctness 正确性 ​

Search 找到最相似内容，只回答：

“像不像用户的问题？”

不能回答：

“它有没有资格定义企业事实？”

所以：

Relevance
≠
Authority

边界二：Knowledge 知识 ≠ Memory 记忆 ​

Knowledge 的核心是：

企业 / 外部权威事实。

Memory 的核心是：

历史交互中值得未来复用的信息。

一个错误历史记忆不能覆盖企业正式指标口径。

边界三：Query Success 查询成功 ≠ Business Answer Correct 业务回答正确 ​

SQL 能执行：

只说明数据库接受了 Query。

真正正确还需要：

Right Intent
Right Metric
Right Dataset
Right Time
Right Permission
Fresh Data
Correct Analysis
Supported Claim

1.3 本篇的两条面试主线 ​

Knowledge 主线 ​

Source
→ Canonical Knowledge
→ Authority / ACL / Freshness
→ Retrieval
→ Evidence
→ Context

Data Agent 主线 ​

User Question（用户问题）
→ Semantic Grounding（语义对齐）
→ Metric / Dataset Discovery（指标 / 数据集发现）
→ Source Routing（数据源路由）
→ Query Planning（查询规划）
→ Execution（执行）
→ Artifact / Analysis（产物 / 分析）
→ Evidence（证据）
→ Verification（验证）

面试时不要把两条线分开背。

企业 Data Agent 正是 Knowledge Architecture 的典型消费方：

知识层负责“这个指标是什么、哪张表可信”；Data Tool 负责“当前事实是多少”；Agent 负责“下一步怎样分析”。

1.4 本篇的口述控制原则 ​

这篇很容易一回答就变成“数据平台百科”，所以面试现场尤其要控制信息密度。

例如问：

“Enterprise Knowledge Architecture 为什么不等于 RAG？”

先回答：

“因为 RAG 主要解决 Retrieval，企业 Knowledge 还要解决 Authority、Permission、Freshness、Version、Lineage 和 Eval。”

先停。

如果面试官继续追：

“那 Authority 怎么做？”

再进入 Source of Truth / Conflict Resolution。

Data Agent 也一样。问：

“为什么不是 NL2SQL？”

先讲：

Semantic Grounding
→ Source Routing
→ Execution
→ Evidence
→ Verification

不要一上来把 Metric Platform、Knowledge Graph、Warehouse、BI、Workflow 全部讲完。

这篇的高分关键不是术语多，而是能把“可信事实 → 可验证答案”的因果链说清楚。

1.5 读不懂时先记这张“Knowledge → Data Agent”速记表 ​

最重要的一条：

Knowledge
→ 决定“什么是真的 / 什么叫 GMV”

Data Tool
→ 计算“现在 GMV 是多少”

Agent
→ 决定“下一步查什么、怎么分析”

Verification
→ 证明“最后这句话是否真的站得住”

二、Enterprise Knowledge Architecture 企业知识架构 ​

2.1 Q1｜Enterprise Knowledge Architecture 为什么不等于 RAG，也不等于 Vector DB？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会把 RAG 看成 Knowledge Consumption（知识消费）链路的一部分，把 Vector DB（向量数据库）看成可选索引组件。

企业 Knowledge Architecture 真正要覆盖的是：

Source
→ Ingestion / Parse
→ Canonical Knowledge
→ Authority / ACL / Freshness
→ Index / Retrieval
→ Evidence / Citation
→ Version / Revoke / Delete
→ Eval / Governance

所以企业真正困难的往往不是“能不能召回”，而是“召回出来的东西有没有资格被相信和使用”。

2～3 分钟高分回答 ​

如果系统只有：

Document
→ Chunk
→ Embedding
→ TopK

它回答不了几个生产问题：

第一，Source of Truth（权威事实源）是谁？

同一个退款政策，Team Wiki 和官方制度冲突，哪个赢？

第二，Knowledge 是否仍有效？

旧文档相似度再高，也可能已经过期。

第三，Permission（权限）是否正确？

当前用户没权限看的 Chunk，不应该先召回再让模型“不要输出”。

第四，知识如何更新 / 删除？

源文档删了，Embedding、Cache、Derived Summary 是否一起失效？

第五，知识是否只有文档？

企业里还有：

• Structured Data（结构化数据）；
• Metric / Semantic Definition（指标 / 语义定义）；
• Operational State（运行状态）；
• Entity / Relationship（实体 / 关系）；
• Live API（实时接口）。

所以我更愿意把 RAG 定位成：

把某类 Knowledge 在当前 Query 下检索并投影给模型的方法。

而 Knowledge Architecture 管的是整个知识生命周期。

Microsoft 当前 Foundry IQ 也把 Knowledge Base 建模成可连接多 Source、支持权限、Keyword / Vector / Hybrid Retrieval（关键词 / 向量 / 混合检索）、Agentic Retrieval（智能体式检索）和 Citation（引用）的共享知识层，而不是单纯 Vector Store。[R1]

真实项目怎么带 ​

Data Agent 里最典型：

Metric Definition
Dataset Metadata
Business Rule

属于 Knowledge；

实时 GMV 则应该通过 SQL / BI / API Tool 查询。

如果全部 Embedding 成文本，反而失去数据系统原本的精确语义和实时性。

高分亮点句 ​

RAG 解决“怎么把相关内容取给模型”，Knowledge Architecture 解决“企业有哪些可信事实，以及这些事实怎样被生产、治理和证明”。

面试官真正想听什么 ​

• 是否把 RAG 等价成知识架构；
• 是否理解 Authority / Permission / Freshness；
• 是否有企业级知识生命周期意识。

典型追问 ​

1. 那 Vector DB 在整体架构里是什么角色？
2. 什么 Knowledge 不应该做 Embedding？
3. Knowledge Platform 和 Context Platform 的边界是什么？
4. Remote / Live Knowledge 怎么接入？

Red Flags ​

• “知识库就是 Vector DB。”
• “RAG 召回 TopK 后直接给模型就行。”

为什么这样回答 / 本题套路 ​

这是总边界题。不要先讲 Chunk / Embedding 技术细节，而要先扩大问题空间：从“检索”提升到“事实生命周期与治理”，这样后续 Authority、ACL、Delete、Eval 才有合理位置。

2.2 Q2｜企业事实为什么应该归 Knowledge 而不是 Memory？两者在 Authority、Lifecycle、Ownership 上的边界是什么？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会用三个维度区分：

Authority
Lifecycle
Ownership

Knowledge 由 Domain Source of Truth / Owner（领域权威源 / 负责人）定义；Memory 来自历史交互、观察或用户偏好。

所以 Memory 可以帮助未来决策，但不能因为“记住了”就获得修改企业事实的资格。

2～3 分钟高分回答 ​

比如：

“公司 GMV 定义是什么？”

应该由 Metric Registry（指标注册中心）或 Data Domain 定义。

而：

“这个用户更喜欢看周趋势。”

可以是 User Memory。

两者最大的差异是：

Authority

Knowledge
→ 官方 Source / Domain Owner 授权

Memory
→ 历史 Interaction / Observation / User Confirmation

Lifecycle

Knowledge
→ Version / Validity / Freshness / Revoke

Memory
→ Retention / Correction / Forget / Scope

Ownership

Knowledge
→ Domain / Data / Policy Owner

Memory
→ User / Agent / Team Scope

一个错误 Memory 即使被重复使用 100 次，也不应该覆盖 Metric Registry。

Context 则是第三个概念：

Knowledge 和 Memory 只有在当前任务需要时，才经过 Context Policy 进入这一轮模型。

真实项目怎么带 ​

Data Agent 很适合讲：

GMV 定义 → Knowledge
用户偏好“默认看周维度” → Memory
当前这一轮给模型的 GMV 定义 + 用户偏好 → Context

高分亮点句 ​

Memory 记录“过去对我有用什么”，Knowledge 负责“组织正式承认什么是真的”。

面试官真正想听什么 ​

• Knowledge / Memory 是否混淆；
• 是否理解企业事实 Authority；
• 是否会让 Agent 自己“学习”正式业务口径。

典型追问 ​

1. 用户纠正企业知识怎么办？
2. Memory 和 Knowledge 冲突听谁的？
3. Team Shared Memory 能否成为 Knowledge？
4. Skill 又属于哪一层？

Red Flags ​

• “模型记住得多了以后就是 Knowledge。”
• “统一存在长期向量库，检索时再判断。”

为什么这样回答 / 本题套路 ​

这是Authority 边界题。高分点不是定义，而是说明“谁有资格定义事实”，这是企业 Agent 和个人助手的本质差异之一。

2.3 Q3｜Search Relevance 为什么不等于 Knowledge Correctness？Source of Truth 和 Authority 怎么进入检索链路？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

相似度只能回答：

“这段内容和 Query 有多相关？”

企业知识还必须回答：

“它有多权威、当前是否有效、是否适用于这个用户 / Region / 时间？”

所以最终 Evidence 不能只按 Relevance 排序。

2～3 分钟高分回答 ​

举个例子：

Team Wiki：退款期限 30 天
相似度 0.96

Official Policy：退款期限 14 天
相似度 0.84

如果系统只看 Vector Similarity，就会把错误口径排在前面。

更合理的链路是：

Permission Eligibility
→ Relevance Recall
→ Authority
→ Version / Validity
→ Freshness
→ Scope
→ Conflict Resolution
→ Evidence

Authority 可以显式分级：

A0 Source of Record
A1 Official Published Policy
A2 Domain-owned Knowledge
A3 Team Wiki
A4 User Note
A5 Untrusted External Content

这里不要机械追求一套统一分数。

更重要的是：

某些 Authority Rule 应该是 Hard Constraint（硬约束），而不是给 Vector Score 加 0.1。

项目映射 ​

Data Agent 的 Metric Definition 特别典型：

业务 Wiki 写的“GMV”再像用户 Query，也不能覆盖正式 Metric Definition。

高分亮点句 ​

Relevance 回答“像不像”，Authority 回答“谁有资格定义事实”。

面试官真正想听什么 ​

• 是否理解搜索相关性和业务正确性的区别；
• 是否会把 Authority 建模成系统语义；
• 是否有 Source of Truth 意识。

典型追问 ​

1. Authority 和 Confidence 区别是什么？
2. 多个 A0 Source 冲突怎么办？
3. Authority 是人工配置还是自动学？
4. External Web Source 应该是什么级别？

Red Flags ​

• “相似度最高的答案最可信。”
• “让 LLM 根据内容自行判断哪个更权威。”

为什么这样回答 / 本题套路 ​

这是失败机理题。先用一个“高相关但过期 / 低权威”的反例打破 Vector Score 直觉，再推导 Authority-aware Retrieval。

2.4 Q4｜固定 Chunk Size 为什么可能破坏业务语义？不同 Source 应怎样选择 Knowledge Unit？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

Chunking（分块）的目标不是把文档平均切小，而是得到一个适合检索、同时又尽量保持原始语义完整的 Knowledge Unit（知识单元）。

固定长度很容易把条件、例外、表头、函数上下文切断，所以 Chunk Strategy（分块策略）应该跟 Source Structure（源结构）走。

2～3 分钟高分回答 ​

典型事故：

原文：

“仅 Sev-1 且值班总监批准时，可以跳过普通审批。”

固定 Token 切块以后，某个 Chunk 只剩：

“可以跳过普通审批。”

这个 Chunk 被检索出来时，语义已经变了。

所以不同 Source 应该选择不同 Unit。

Policy / Contract

Clause / Section-aware

FAQ

Question + Answer

Code

Function / Class / Symbol

Ticket / CRM

Record

Table

Table / Row Group + Header Context

Long Documentation

Parent-child Chunk

企业 Knowledge Unit 最好同时保留：

parent_id
source_id
section_path
version
effective_time

这样即使检索到子 Chunk，也能恢复 Parent Context。

多模态 Knowledge 怎么处理 ​

如果 Source 是 PDF、截图、流程图、表格或扫描件，也不能简单 OCR 后按固定 Token 切。

更合理的是：

Raw Media
→ OCR / Vision Parse
→ Structured Representation
→ Region / Page / Table Coordinates
→ Text / Image Index
→ Citation 回原始区域

这样检索结果不仅能返回文本，还能回到原始 Page / Region 做 Evidence。

真实项目怎么带 ​

Data Agent 的 Dataset Metadata 不应该按 500 Token 切。Metric Definition、字段、Join Relation 都应该保留原生结构。

高分亮点句 ​

Chunk Size 是实现参数，Knowledge Unit 才是业务语义。

面试官真正想听什么 ​

• 是否知道 Chunking 会改变语义；
• 是否会按 Source 类型设计检索单元；
• 是否理解 Parent / Child Context。

典型追问 ​

1. Chunk 越大 Recall 越好吗？
2. Overlap 怎么选？
3. Table 怎么 Chunk？
4. 多模态文档怎么办？

Red Flags ​

• “所有文档统一 512 Token + 10% overlap。”

为什么这样回答 / 本题套路 ​

这是工程实现题。不要先报“最佳 Chunk Size”，而是先解释为什么 Source Structure 是第一决定因素。

2.5 Q5｜Hybrid Search、Metadata Filter、Rerank 分别解决什么问题？推荐的默认检索链路是什么？ ​

复习优先级：P0｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会把 Retrieval 分成：

Eligibility
→ Recall
→ Precision

Metadata / ACL Filter（元数据 / 权限过滤）先决定谁有资格出现；Keyword + Vector 做高 Recall；Reranker 再提高 Precision。

2～3 分钟高分回答 ​

一个企业检索链路通常是：

Identity / Tenant / ACL / Time Filter
→ Keyword Recall + Vector Recall
→ Candidate Merge / Dedup
→ Semantic Rerank
→ Authority / Freshness / Conflict
→ Evidence Pack

为什么 Filter 尽量前置？

因为无权限内容如果先召回给 Reranker / LLM，再说“最后不要输出”，敏感数据其实已经进入了不该进入的处理边界。

Keyword 和 Vector 各自擅长不同 Query：

Error Code / Metric ID / API Name
→ Keyword

概念 / 同义表达
→ Vector

Reranker 用更昂贵的模型对几十个 Candidate 做二次判断。

但 Rerank 不是默认“越多越好”。

它引入：

• Cost；
• Latency；
• Model Dependency。

所以要看：

Rerank Lift
Task Success Delta
P95 Latency

AWS Bedrock Knowledge Bases 当前 Retrieval API 也把 Metadata Filter 和 Reranking 作为显式能力，这能说明“过滤、召回、重排”已经是独立的生产阶段，而不是一个 TopK 参数。[R2][R3]

高分亮点句 ​

Filter 决定“有没有资格进场”，Recall 决定“能不能找到”，Rerank 决定“谁最值得排前面”。

面试官真正想听什么 ​

• 是否理解多阶段 Retrieval；
• 是否知道 ACL 不能放最后；
• 是否会用 Eval 判断 Reranker 是否值得。

典型追问 ​

1. Hybrid 权重怎么调？
2. Rerank Candidate 数量怎么选？
3. Reranker 会不会看到无权限数据？
4. Keyword 和 Vector 谁应该先？

Red Flags ​

• “Vector Search + Reranker 就够了。”
• “权限最后生成答案时再检查。”

为什么这样回答 / 本题套路 ​

这是Pipeline 题。按 Eligibility → Recall → Precision 顺序讲，比直接罗列三种技术更有逻辑，也更容易回答权限与成本追问。

2.6 Q6｜什么问题应该走 Vector / Keyword，什么问题应该走 SQL / Graph / Live API？ ​

复习优先级：P0｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我不会强迫所有 Knowledge 进入同一种检索技术。

判断关键是：

用户是在找文本语义、精确标识、结构化计算、多跳关系，还是当前实时状态。

2～3 分钟高分回答 ​

我通常这样路由：

Error Code / ID / exact name
→ Keyword / Exact Lookup

概念 / 文档语义
→ Vector / Hybrid Search

聚合 / Join / 精确数值
→ SQL / Structured Query

实体多跳关系
→ Graph

实时库存 / Health / On-call / Permission
→ Live API

例如：

“退款规则是什么？”

查 Knowledge。

“今天退款金额是多少？”

SQL。

“当前支付服务是否健康？”

Live API。

“这个服务依赖哪些下游、哪些团队负责？”

可能适合 Graph。

因此成熟 Knowledge Layer 应该有 Source Router：

Query Understanding
→ Source / Retrieval Mode
→ Execute
→ Unified Evidence

而不是把所有源先文本化。

真实项目怎么带 ​

Data Agent 非常适合：

Metric Definition → Knowledge
Current Metric Value → SQL
Dataset Relationship → Metadata / Graph
Live Pipeline State → API

高分亮点句 ​

先选对知识源，再谈在这个源里怎么 Search。

面试官真正想听什么 ​

• 是否会 Source Routing；
• 是否过度 Vector 化；
• 是否理解 Structured / Live Knowledge。

典型追问 ​

1. Router 用规则还是 LLM？
2. Mixed Query 怎么办？
3. Graph 什么时候是过度设计？
4. Live API 超时如何处理？

Red Flags ​

• “所有数据都 Embedding 后统一搜索。”

为什么这样回答 / 本题套路 ​

这是方案决策题。先按 Query Semantics 建立决策树，再映射检索方式，这比按产品组件答更稳定。

2.7 Q7｜多个知识来源返回互相冲突的答案时，系统怎样决定哪个 Evidence 可以进入 Context？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

冲突不能交给模型凭语气判断。

我会先做结构化 Conflict Resolution（冲突解决）：

Authority
→ Version / Validity
→ Scope
→ Time
→ Resolve or Escalate

只有被接受的 Evidence 才进入最终 Context；无法自动解决时应明确暴露冲突。

2～3 分钟高分回答 ​

假设：

Official Policy：14 天
Team Wiki：30 天
Customer Note：45 天

步骤是：

第一，判断是否真的冲突

可能一个适用于 US，一个适用于 SG，不是冲突而是 Scope 不同。

第二，比较 Authority

Official Source 通常优先于 Team Wiki。

第三，比较 Validity

同一 Authority 下，新 Version 可能 supersede（取代）旧版本。

第四，决定是否能自动 Resolve

如果规则明确，系统决定。

如果两个同级 Source 都有效但内容冲突：

Escalate
→ Human / Domain Owner

不要让模型凭“哪个看起来更合理”静默选择。

冲突本身也应该可观测：

Conflict Rate
Auto-resolution Rate
Human Escalation
Wrong Resolution

高分亮点句 ​

冲突知识不是 Retrieval Noise，而是一种需要显式治理的业务状态。

面试官真正想听什么 ​

• 是否知道 Knowledge Conflict 是一等对象；
• 是否会把 Authority / Scope / Time 放进解决链路；
• 是否有 Escalation 思维。

典型追问 ​

1. 两个 Source of Truth 冲突怎么办？
2. 模型是否应该看到冲突的两个版本？
3. Conflict Resolution 能否用 LLM？

Red Flags ​

• “让模型综合一下。”
• “相似度高的优先。”

为什么这样回答 / 本题套路 ​

这是冲突治理题。高分点是先区分 Scope 差异和真正 Conflict，再说明哪些规则可确定性处理，哪些必须升级 Owner。

2.8 Q8｜为什么 ACL 必须在 Retrieval 前生效？怎样防止跨租户 Index / Cache 泄漏？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

权限应该决定：

Candidate 是否有资格参与 Retrieval。

而不是先把无权限内容召回给模型，再在最终输出阶段做过滤。

多租户系统必须让 Tenant / ACL Scope 贯穿 Source → Index → Cache → Rerank → Trace。

2～3 分钟高分回答 ​

正确链路应该是：

User Identity
+ Agent Delegated Identity
→ Tenant / Domain / Row / Field Policy
→ Eligible Candidate Set
→ Retrieval
→ Rerank
→ Context

跨租户常见风险包括：

• Tenant A 的 Chunk 进入共享 Index；
• Query Cache Key 没包含 Tenant；
• Embedding / Retrieval Cache 跨 Scope 复用；
• Remote Connector 使用平台超级账号；
• Reranker / Eval 保存了敏感内容。

所以要显式绑定：

tenant_id
principal_id
policy_version
region
classification
source_acl

Microsoft Foundry IQ 当前强调 Query-time Permission Enforcement（查询时权限执行）以及使用 Caller Identity / Entra Identity 访问知识源，这说明企业 Knowledge Layer 已经把“权限感知检索”当成核心语义。[R1]

真实项目怎么带 ​

Data Agent 不应该用一个超级账号查所有 Dataset，再让 Prompt 控制字段输出。应该尽量复用数据平台本身的 Row / Column / Tenant Policy。

Knowledge Poisoning 也要单独防 ​

即使权限正确，Source 本身也可能被污染。

例如：

• Wiki 被错误编辑；
• 外部 Web 内容被 Prompt Injection；
• 恶意文档伪造 Official Policy；
• 自动 Ingestion 把低可信内容标成高 Authority。

所以 Security 不只是 ACL，还要有：

Source Provenance
Trust Level
Publisher / Owner
Change Audit
Content Scan
Authority Policy

高分亮点句 ​

权限不是生成后的内容审核，而是决定哪些证据一开始就有资格进入候选集；但“有权限看”也不代表“内容一定可信”。

面试官真正想听什么 ​

• 是否理解 Retrieval 前权限；
• 是否考虑 Cache / Reranker / Trace 的二次泄漏；
• 是否有 Delegated Identity 思维。

典型追问 ​

1. Shared Index 是否一定不安全？
2. Permission Filter 会不会降低 Search Recall？
3. Remote Source 怎么传用户身份？
4. Trace 里敏感 Evidence 怎么处理？

Red Flags ​

• “最后输出前做脱敏就行。”
• “Agent 使用平台统一高权限 Credential。”

为什么这样回答 / 本题套路 ​

这是安全边界题。要把安全从最终答案层前移到 Candidate Eligibility，并提醒中间组件本身也是数据边界。

2.9 Q9｜Source 已删除，但旧 Chunk 仍被搜到；怎样设计 Lineage、Revoke 和 Delete Propagation？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

删除 Knowledge 不是删一条 Source Record，而是一个 Data Lineage（数据血缘）问题。

我会区分：

Revoke
→ 立即停止使用

Delete
→ 最终把所有派生数据清理掉

2～3 分钟高分回答 ​

一条 Source 可能派生出：

Raw Source
→ Parsed Object
→ Canonical Knowledge
→ Chunk
→ Embedding
→ Keyword Index
→ Graph Edge
→ Cache
→ Derived Summary

如果只删 Raw Source，后面的派生对象还会继续召回。

所以 Knowledge Object 必须带 Lineage：

source_id
source_version
derived_from
parser_version
index_version

高风险知识发现错误时，我不会等整个异步 Delete Pipeline 跑完。

先：

Revoke source_version
→ Remove from Eligible Candidate
→ Invalidate Cache
→ Block Remote Fetch

然后异步：

Delete Chunk
Delete Embedding
Delete Derived Object
Reindex

高分亮点句 ​

Revoke 解决“现在立刻不能再用”，Delete 解决“最终彻底不存在”。

面试官真正想听什么 ​

• 是否理解派生数据；
• 是否有紧急撤销机制；
• 是否理解删除最终一致性。

典型追问 ​

1. 删除怎么证明完整？
2. Snapshot / Trace 里的历史 Evidence 要删吗？
3. Embedding 怎么定位 Source？
4. GDPR / 隐私删除怎么办？

Red Flags ​

• “删 Vector DB 里的 Chunk 就行。”
• “等下一次全量重建 Index。”

为什么这样回答 / 本题套路 ​

这是Lifecycle / Incident 题。先画派生链，再自然得出 Lineage；再用紧急 Revoke 和最终 Delete 区分实时风险和数据清理。

2.10 Q10｜数据源结构（Source Schema）改了但服务不报错，为什么会形成静默知识故障（Silent Knowledge Failure）？怎样治理 Schema Evolution（结构演进）？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

最危险的 Schema 变化不是 Parse Error，而是：

Pipeline 仍然成功，但字段语义已经变了，最终 Knowledge 悄悄失真。

所以 Source 需要 Knowledge Contract（知识契约），Schema Evolution（Schema 演进）需要 Compatibility Check、Shadow Parse、Knowledge Diff 和 Migration。

2～3 分钟高分回答 ​

例如：

owner: string

变成：

owners: string[]

旧 Parser 可能仍然运行成功，却只取第一个 Owner，或者直接丢字段。

更危险的是字段名字不变、语义变化：

status
old: current lifecycle state
new: last completed state

类型完全兼容，但业务意义变了。

所以 Source Contract 至少包含：

schema_version
field semantics
required / optional
compatibility rule
owner
deprecation_date
migration_plan

演进流程：

Detect Change
→ Compatibility Check
→ Shadow Parse
→ Knowledge Diff
→ Offline Eval
→ Reindex / Migrate
→ Deprecate Old Version

不只是 Source Schema，Index Pipeline 也要版本化 ​

Knowledge 质量还会受到：

parser_version
chunking_version
embedding_model_version
index_version
reranker_version

影响。

Embedding Model 或 Chunking Strategy 改变时，我不会直接原地覆盖旧 Index，而更倾向：

Build v2
→ Backfill
→ Offline Eval
→ Shadow Query
→ Compare Retrieval Diff
→ Canary
→ Alias Switch
→ Rollback Window

真实项目怎么带 ​

Data Agent 的 Dataset / Metric Schema 变化非常典型：

列名没变但口径改了，比简单 Column Not Found 更危险。

高分亮点句 ​

Schema Compatibility 不是 Semantic Compatibility。系统不报错，可能恰恰是最危险的失败。

面试官真正想听什么 ​

• 是否理解 Silent Failure；
• 是否会把 Source Schema 当 Contract；
• 是否考虑迁移和 Regression。

典型追问 ​

1. 自动 Schema Diff 够吗？
2. Parser Version 要不要绑 Trace？
3. Embedding Model 升级算不算 Schema Migration？
4. 如何 Canary Reindex？

Red Flags ​

• “Schema 变了，Parser 报错再修。”
• 只检查字段类型，不检查语义。

为什么这样回答 / 本题套路 ​

这是架构演进 + Debug 题。先强调“服务成功 ≠ Knowledge 正确”，再把 Schema 变化升级成 Versioned Contract。

2.11 Q11｜知识评测（Knowledge Eval）为什么要拆成 Source（源质量）、Retrieval（检索）、Evidence（证据）、Answer（答案）四层？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为只看最终 Answer Accuracy（答案准确率）无法定位问题。

我会拆成：

Source Quality
Retrieval Quality
Evidence Quality
Answer Quality

这样失败以后知道应该修数据、Search、Evidence 还是模型。

2～3 分钟高分回答 ​

Source Quality

看：

• Parse；
• Freshness；
• Metadata；
• ACL；
• Conflict。

Retrieval Quality

看：

• Recall@K；
• Precision@K；
• MRR / nDCG；
• Source Routing Accuracy；
• Rerank Lift。

Evidence Quality

看：

• Authority；
• Citation Correctness；
• Freshness；
• Evidence Sufficiency（证据充分性）。

Answer Quality

看：

• Grounded Accuracy（基于证据的准确性）；
• Unsupported Claim（无证据主张）；
• Task Success。

比如答案错：

Source 错
→ 修 Source

Source 对但没召回
→ 修 Retrieval

召回对但引用错
→ 修 Evidence Assembly

Evidence 对但模型结论错
→ 修 Prompt / Model / Verification

生产里还应该：

Production Trace
→ Failure Mining
→ Eval Dataset
→ Experiment
→ Release Gate

这里还有一个非常重要的生产细节：Retrieval Trace（检索链路追踪）必须绑定版本。

至少要能回答这次结果来自：

source_version
parser_version
chunking_version
embedding_version
index_version
retrieval_policy_version
reranker_version
ACL / authority_policy_version

否则某次 Retrieval Regression（检索回归）发生后，你只知道“答案变差了”，却无法定位是 Source、Chunk、Embedding、Index、Reranker 还是 Policy 发生变化。

企业也可以做 Knowledge Quality Dashboard（知识质量看板），但我不建议压成一个无法解释的总分。更好的方式是分别暴露：

Freshness
Permission Correctness
Parse Quality
Retrieval Recall
Evidence Authority
Conflict Rate
Citation Correctness

再根据具体业务决定 Release Gate。

Snowflake Cortex Analyst 当前也使用 Verified Queries（已验证查询）作为评测 Ground Truth，并显式跟踪 SQL Correctness、Regression、Latency；这说明 Data Agent / Semantic Layer 的质量评测已经在向“版本化回归闭环”发展。[R4][R5]

高分亮点句 ​

Eval 的价值不只是给一个分，而是让失败可以归因。

面试官真正想听什么 ​

• 是否理解分层 Eval；
• 是否会从线上 Failure 构建回归集；
• 是否能区分 Search 失败与模型失败。

典型追问 ​

1. Recall@K 好但最终答案差怎么办？
2. LLM Judge 能评 Evidence 吗？
3. Eval Dataset 如何防 Leakage？
4. Online Eval 怎么做？

Red Flags ​

• “RAG Eval 看一个最终准确率。”
• “用 LLM Judge 统一打一分。”

为什么这样回答 / 本题套路 ​

这是质量体系题。重点不是指标数量，而是建立 Failure Attribution（失败归因）的层次结构。

2.12 Q12｜什么时候 Agentic Retrieval / Query Decomposition 值得，什么时候只是增加成本和延迟？ ​

复习优先级：P1｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

Agentic Retrieval 适合：

复杂、多源、多跳、需要迭代搜索的 Query。

简单、单源、确定性问题不要为了“更 Agent”引入规划与多轮检索。

2～3 分钟高分回答 ​

简单问题：

“退款期限是多少？”

如果已有 Official Policy Source，直接 Lookup + Cite 更好。

复杂问题：

“比较 SG、US 两地过去两年的退款政策变化，并判断当前某客户应该适用哪一条。”

可能需要：

Query Decomposition
→ Source Routing
→ Parallel Search
→ Inspect Results
→ Refine Query
→ Merge Evidence

这时 Agentic Retrieval 才真正有价值。

判断是否值得主要看：

Query Complexity
Source Diversity
Multi-hop Need
Uncertainty
Coverage Gain
Latency / Cost Budget

Microsoft Foundry IQ 当前 Agentic Retrieval 支持 Query Planning、Subquery、Parallel Search、Semantic Reranking 和 Citation，这可以作为这种模式已经进入企业知识产品的现实证据。[R1]

但产品支持不代表所有 Query 都应该打开高 Reasoning Effort。

高分亮点句 ​

Agentic Retrieval 应该解决“固定 Query Pipeline 不够表达的问题”，而不是把简单 Search 变成更贵的 Search。

面试官真正想听什么 ​

• 是否会控制 Agentic Complexity；
• 是否理解 Query Decomposition 的收益与成本；
• 是否知道简单 Query 要走 Fast Path（快速路径）。

典型追问 ​

1. 怎么判断 Query Complex？
2. 多 Query 结果冲突怎么办？
3. Agentic Retrieval 如何 Eval？
4. 如何限制 Fan-out？

Red Flags ​

• “所有 RAG 都应该先让 Agent 拆 Query。”
• “多查几次一定 Recall 更高。”

为什么这样回答 / 本题套路 ​

这是Trade-off 题。先给 Fast Path / Complex Path 两类场景，再明确“收益是否超过额外 Cost / Latency”。

2.13 Q13｜大型企业为什么更适合 Federated Knowledge（联邦式知识架构），而不是一个中央 Vector DB（向量数据库）？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为不同 Domain 的 Source of Truth、ACL、Region、Freshness、Schema、Owner 都不同。

平台应该统一：

发现、访问、Evidence、治理语义。

不一定统一：

所有底层存储。

2～3 分钟高分回答 ​

中央 Vector DB 在小规模时简单，但大型企业会遇到：

• Data Residency（数据驻留）；
• Domain-specific ACL；
• Source-specific Freshness；
• Structured / Live Source；
• 不同 Owner；
• Schema Lifecycle；
• 重复同步。

更合理的 Federated Architecture（联邦式架构）是：

Domain-owned Source
→ Shared Knowledge Contract
→ Common Discovery / Identity / Policy
→ Domain Retrieval
→ Unified Evidence

平台统一：

Source Registry
Identity
Authority Semantics
Evidence Contract
Trace / Eval

Domain 保留：

Source of Truth
Storage
Native ACL
Business Semantics
Freshness Ownership

还要特别注意 Data Residency（数据驻留）。

真正跨 Region 的不只是原始 Source，还包括：

Query
Embedding
Reranker Input
Cache
Trace
Eval Dataset

所以“原始数据留在本地”并不能自动满足 Residency；整条 Retrieval / Observability 链都要检查数据是否跨域。

真实项目怎么带 ​

Data Agent 跨业务线后，不应该强制所有 Dataset、Metric、Policy 都同步进一个 Vector DB。更合理的是让 Data Domain 保留语义和权限 Ownership，Agent Platform 统一访问契约。

高分亮点句 ​

Federation 的目标不是“每个团队各玩各的”，而是统一协议和治理，同时保留事实归属。

面试官真正想听什么 ​

• 企业平台化边界；
• 是否理解 Data Residency / Domain Ownership；
• 是否有中央大一统反思。

典型追问 ​

1. Federated Search 怎么排序？
2. 多域 Evidence 怎么合并？
3. Registry 会不会变单点？
4. 什么规模才需要 Federation？

Red Flags ​

• “大公司统一一个 Vector DB 最方便治理。”
• “Federation 就是不做统一平台。”

为什么这样回答 / 本题套路 ​

这是架构判断题。要说明为什么中央化在小规模合理、哪些 Scale / Governance Trigger 让它失效，再推导 Federation。

2.14 Q14｜Knowledge Control Plane 应该统一什么？什么时候应该 Build，什么时候应该 Buy？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

Knowledge Control Plane（知识控制面）应该统一：

Source、Authority、Policy、Version、Lineage、Eval、Cost 这些稳定治理语义。

它不应该为了“自研”重新实现所有 Search / Vector / Parser 基础能力。

Build vs Buy 的判断核心是：

Differentiation
Governance
Scale
Integration / Switching Cost

2～3 分钟高分回答 ​

我认为适合平台统一的对象包括：

Source Registry
Connector Registry
Authority Policy
ACL / Identity
Freshness SLA
Index Registry
Retrieval Policy
Reranker Registry
Evidence Contract
Eval
Lineage
Revoke / Deprecation
Cost

底层 Search 可以是：

• Azure AI Search；
• OpenSearch；
• Elastic；
• Databricks；
• Snowflake；
• 自研；
• 其他 Provider。

平台不应该把“统一治理”误解成“统一底层技术实现”。

Buy 更适合：

• Source 少；
• 规模有限；
• 权限简单；
• 托管能力满足 SLO；
• 团队希望快速上线。

Build 更有价值：

• 多 Provider；
• 多 Domain；
• 多 Agent 共用；
• 强 Data Residency；
• 统一 Authority / ACL；
• 需要跨平台 Eval / Cost / Version。

高分亮点句 ​

Control Plane 的价值是统一治理语义，不是重新造所有 Data Plane。

面试官真正想听什么 ​

• 是否有平台边界；
• 是否会 Build vs Buy；
• 是否理解 Control Plane / Data Plane 分离。

典型追问 ​

1. 哪些能力应该先 Build？
2. Search Provider 如何可替换？
3. Migration / Alias Switch 怎么做？
4. Control Plane 自己挂了怎么办？

Red Flags ​

• “企业级一定全自研。”
• “买了云 Knowledge Base 就不需要治理。”

为什么这样回答 / 本题套路 ​

这是Platform + Judgment 题。先定义 Control Plane 的稳定对象，再讨论 Build / Buy，避免先从厂商功能表做架构。

2.15 阶段性总结：Knowledge Architecture 的核心记忆 ​

这一部分如果只记五句话：

1. RAG 是 Knowledge Consumption，不是完整 Knowledge Architecture。
2. Relevance 不等于 Correctness；Authority 决定谁有资格定义事实。
3. Permission 应该决定 Candidate Eligibility，而不是最后输出时再过滤。
4. Revoke 解决立即停止使用，Delete 解决最终彻底清理。
5. 平台统一 Knowledge Governance，不一定统一所有底层存储。

从这里进入 Data Agent：

Data Agent 最核心的问题之一，就是怎样把 Knowledge 中的业务语义与实时 Data Tool 的事实计算组合起来，并最终形成可验证答案。

三、Data Agent 项目深挖 ​

本章不是单独背一套“数据 Agent 八股”。它是前面 Knowledge Architecture 在真实数据业务中的落地。
面试时优先从你真实负责的 Data Agent 切入；如果某项机制还没有上线，就明确说“当前做到 A，下一阶段我会在出现 B Trigger 后演进到 C”。

3.1 Q15｜你做的 Data Agent 到底解决什么问题？为什么不是传统 BI、NL2SQL、搜索或 Copilot 就够了？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

我会先把 Data Agent 定义成：不是“自然语言转 SQL”，而是把用户意图、企业数据语义、数据权限、查询执行、分析推理和结果验证串成一个闭环。

传统 BI 更适合预定义报表，NL2SQL 主要解决 SQL 生成，搜索主要解决已有知识查找，Copilot 更偏辅助操作。真正需要 Data Agent 的场景，是问题路径无法预先完全定义，需要根据中间结果继续选择数据源、生成分析步骤、执行查询、下钻并验证结论。

2～3 分钟高分回答 ​

我一般先不从“用了什么模型”讲，而是先讲用户问题。

企业里很多数据问题不是“给我一张表”，而是：

“为什么这个月 GMV 下滑？”
“哪些商家导致了变化？”
“这个指标和上个月口径一样吗？”

这类问题至少包含六层不确定性：

1. Intent：用户到底想问什么；
2. Semantic Grounding：GMV 到底是哪一个口径；
3. Source Selection：应该查 Dataset、BI 语义层还是实时 API；
4. Query Planning：先查总量还是先做维度拆解；
5. Execution：SQL / BI / API 怎么执行；
6. Verification：最终结论是否真的被 Evidence 支持。

所以我不会把 Data Agent 等价成 NL2SQL。NL2SQL 只是其中一个 Tool。

我更倾向的主链路是：

User Question
→ Intent / Metric Understanding
→ Knowledge / Dataset Discovery
→ Analysis Plan
→ SQL / BI / API
→ Result Artifact
→ Drill-down / Re-plan
→ Evidence
→ Verification
→ Answer

什么时候不需要 Agent？如果只是固定报表、稳定指标查询、确定性 CRUD，我反而会优先走 BI / Metric API / Workflow，因为更稳定、更便宜、更容易审计。

项目映射 ​

如果你面试时讲自己的 Data Agent，可以用这种方式：

“我现在做的 Data Agent，我不会把价值定义成‘帮用户写 SQL’，而是希望把从问题理解到可信答案的链路打通。真正难的地方是指标语义、Dataset 选择、权限、结果处理和 Verification，而不是 SQL Syntax 本身。”

如果你们当前还没有全部做到，就继续补一句：

“我们当前已经做到 A / B，下一阶段会重点补 C，因为规模上来以后这里会先成为瓶颈。”

高分亮点句 ​

Data Agent 不是把自然语言翻译成 SQL，而是把业务问题翻译成一条可验证的数据分析链路。

面试官真正想听什么 ​

• 你是不是把 Data Agent 理解成 NL2SQL；
• 你有没有产品 / 数据平台视角；
• 你是否知道什么场景不该 Agent 化；
• 你是否理解端到端可信链路。

递进追问 ​

1. 那为什么不能直接用大模型 + Schema？
2. Semantic Layer 是否一定需要？
3. 如果用户问题很简单，还走完整 Agent Loop 吗？
4. Data Agent 和 BI Copilot 的边界是什么？
5. 你怎么定义最终“成功”？

Red Flags ​

• “Data Agent 本质就是 Text-to-SQL。”
• “大模型足够强以后不需要 Semantic Layer。”
• “所有数据问题都可以 Agent 化。”

为什么这样回答 / 本题套路 ​

这是 项目定位题。不要先讲架构，而要先回答“为什么这个项目值得存在”。先把旧方案的能力边界说清楚，再说明 Agent 解决的是哪类新增不确定性。这样才能体现 P7/P8 的产品判断和架构判断，而不是只会堆技术栈。

3.2 Q16｜从用户一句“近 30 天 GMV 为什么下降”开始，到最终给出可信答案，完整链路应该是什么？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

我不会把它当成“一条 SQL”。我会把它拆成：指标口径确认 → 时间与业务范围确认 → 数据源发现 → 基线查询 → 异常点识别 → 维度下钻 → 贡献分析 → Evidence → Verification → 结论。

核心是每一步都能回溯，并且模型的结论要被数据证据支持。

2～3 分钟高分回答 ​

第一步我会先解决语义，不急着查数。

用户说“近 30 天 GMV 为什么下降”，至少要先确认：

• GMV 是下单口径还是支付口径；
• 对比前 30 天、同比还是环比；
• 是否限定某个地区 / 业务线；
• 数据是否完整到今天。

然后进入分析计划：

1. Resolve Metric
2. Resolve Time / Scope
3. Discover Source
4. Query Overall Trend
5. Detect Change Point
6. Drill Down by Key Dimensions
7. Rank Contribution
8. Cross-check with Known Events
9. Build Evidence Pack
10. Verify
11. Answer

比如整体下降 12%，继续按 Region、Category、Merchant Tier 做贡献拆解。发现某地区贡献了 70% 的下降，再继续查该地区关键维度。

这里我认为一个好的 Data Agent 不是“生成一条复杂 SQL”，而是能根据中间结果动态调整分析计划。

最后输出不能只是：

“因为 A 地区下降。”

还要附：

• 使用的 Metric Version；
• Time Range；
• Dataset；
• Filter；
• Query / Query ID；
• 数据 Freshness；
• 关键贡献值。

这样答案才是可验证的。

项目映射 ​

你可以把自己 Data Agent 的真实执行链路映射进来。建议准备一条你最常见的用户 Query，用它贯穿：

用户问题
→ 指标识别
→ 数据集选择
→ 查询
→ 结果分析
→ 可视化 / Artifact
→ 最终回答

高分亮点句 ​

我不会把“为什么下降”压成一条 SQL，因为它本质上是一个迭代分析任务，而不是一次查询任务。

面试官真正想听什么 ​

• 是否理解分析过程；
• 是否会先做语义消歧；
• 是否知道 Evidence / Verification；
• 是否会动态下钻。

递进追问 ​

1. 怎么自动决定下钻维度？
2. 查询次数会不会爆炸？
3. 如果多个维度都相关怎么办？
4. 怎么避免模型“讲故事”？
5. 如何做可视化？

Red Flags ​

• “直接让模型生成 SQL 查最近 30 天和前 30 天。”
• 不提指标口径和数据完整性。
• 不提 Evidence。

为什么这样回答 / 本题套路 ​

这是 端到端链路题。回答时应该先展示“分析任务”的结构，再讲系统。这样比从 Agent Planner / Tool Router 开始更自然，也更像真正做 Data Agent 的人。

3.3 Q17｜Dataset、Metric Definition、Schema、Business Knowledge、Live Data、User Memory 分别应该落在 Knowledge、Context、Tool 还是 Memory？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

我不会按“都是数据”统一存，而会按 Authority、Lifecycle、Access Pattern 划分。

• Metric Definition / Schema / Business Knowledge → Knowledge；
• Live Data → Tool / Query Engine；
• User Preference → Memory；
• 当前这一轮真正要给模型看的部分 → Context。

2～3 分钟高分回答 ​

我会先强调一个边界：

Source of Truth 和 Model-visible Context 不是一回事。

比如：

Metric Definition
→ Knowledge / Semantic Layer

Dataset Schema
→ Knowledge / Metadata

Live Data
→ SQL / BI / API Tool

User Preference
→ Memory

Current Metric + Relevant Schema + Result Summary
→ Context

为什么这样分？

因为这些对象生命周期完全不同。

Metric Definition 需要：

• Owner；
• Version；
• Authority；
• Validity。

Live Data 变化太快，不能复制进长期 Memory。

User Preference 例如“我更习惯按周看趋势”，可以做 Memory，但它不应该成为企业 Knowledge。

Context 只是当前这一轮的投影，它可以同时从 Knowledge、Memory、State、Tool Result 中选信息，但不拥有这些 Source。

如果把这些都塞一个 Vector DB，会快速出现：

• Authority 混乱；
• 删除语义混乱；
• 旧数据覆盖实时事实；
• ACL 难管理。

项目映射 ​

这题非常适合拿你的 Data Agent 架构图举例。你可以准备一个表：

对象        真实 Owner
Metric      指标平台
Schema      Metadata
Live Data   Query Engine
User Pref   Memory
Context     Agent Runtime

高分亮点句 ​

数据在哪里存不是第一问题，谁拥有它、多久变化一次、有没有资格定义事实才是第一问题。

面试官真正想听什么 ​

• 是否真的理解 Context / Knowledge / Memory 边界；
• 数据平台 Ownership 意识；
• 是否会把 Vector DB 当万能库。

递进追问 ​

1. Schema 属于 Knowledge 还是 Tool？
2. Live Data 能不能缓存？
3. 用户纠正 Metric Definition 怎么处理？
4. Context Engine 能不能修改 Knowledge？
5. Memory 和 Knowledge 冲突听谁的？

Red Flags ​

• “都可以 Embedding 后放 Vector DB。”
• “Memory 就是长期 Knowledge。”

为什么这样回答 / 本题套路 ​

这是 概念边界题。高分点不在于背定义，而在于用 Authority、Lifecycle、Ownership 解释“为什么必须分开”。

3.4 Q18｜Data Agent 最难的真的是 Text-to-SQL 吗？为什么 Semantic Grounding 往往比 SQL 生成本身更难？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我认为企业 Data Agent 最难的通常不是 SQL Syntax，而是 Semantic Grounding。因为 SQL 可以语法完全正确，但如果选错 Metric、Dataset、Time Scope、Join Path，业务答案仍然是错的，而且这种错误通常是 Silent Failure。

2～3 分钟高分回答 ​

Text-to-SQL 的错误分两类。

第一类是显性错误：

SQL Syntax Error
Column not found
Permission denied

这种反而好处理，因为数据库会报错。

真正危险的是第二类：

SQL executes successfully
but semantics are wrong

比如用户说“活跃用户”，企业里可能有：

DAU
active_buyer
active_creator
active_user_7d

模型选错其中一个，SQL 仍然能跑，而且结果看起来很合理。

所以 Semantic Grounding 至少要解决：

• Metric Resolution；
• Dataset Selection；
• Field Meaning；
• Time Semantics；
• Join Semantics；
• Business Scope；
• Historical Version。

企业数据里还有三个特别容易被忽略的语义：

Grain
→ 一行数据到底代表订单、用户、日、还是商家？

Join Cardinality
→ 1:1、1:N、N:M 会不会把指标重复放大？

Aggregation Semantics
→ 指标是 Additive、Semi-additive 还是 Non-additive？

例如订单表按 order_id 一行，明细表按 item_id 一行，如果直接 Join 后再 SUM(order_gmv)，SQL 完全合法，但 GMV 可能被重复计算。

这也是为什么成熟 Data Agent 需要 Semantic Layer（语义层）表达：

Measure
Dimension
Time Dimension
Grain
Join Relationship
Business Filter

而不是只给模型表名和列名。

Databricks 当前 Genie 的 Knowledge Store 也把 Join Relationship、Measure、Filter、Dimension 作为结构化 SQL Expression 管理，并明确指出结构化 SQL 表达比纯文本 Instruction 更一致；这可以作为“业务语义需要结构化承载”的现实证据。[R6]

我的设计思路通常是：

User Language
→ Semantic Candidate
→ Authority / Scope
→ Resolve
→ Load Relevant Schema
→ Generate Query

而不是：

User Language
→ Full Schema
→ LLM generates SQL

项目映射 ​

如果你们现在 Data Agent 的痛点也不是纯 SQL Syntax，可以把真实典型失败举出来，例如“用户说 A，系统选了 B Dataset”。不要编指标数值，讲真实 failure pattern 就够。

高分亮点句 ​

Syntax Error 会让系统报错，Semantic Error 会让系统自信地给错答案，后者更危险。

面试官真正想听什么 ​

• 是否只懂 NL2SQL；
• 是否理解企业数据语义层；
• 是否知道 Silent Failure。

递进追问 ​

1. Semantic Layer 怎么设计？
2. 没有统一 Metric Platform 怎么办？
3. 模型能不能直接自己 disambiguate？
4. 怎么 Eval Semantic Accuracy？

Red Flags ​

• “大模型能力强，给完整 Schema 就行。”
• 只谈 SQL execution accuracy。

为什么这样回答 / 本题套路 ​

这是 Why / Mechanism 题。先区分显性失败和隐性失败，再解释为什么业务语义更难，最后自然推导 Semantic Layer / Metric Registry。

3.5 Q19｜企业存在同名指标、历史口径、地区口径时，Agent 怎样决定哪个 Metric Definition 才是 Source of Truth？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

不能让模型凭相似度选。Metric 必须由 Semantic Layer / Metric Registry 显式表达 Authority、Scope、Version、Validity，Agent 做的是 Resolve，不是发明指标定义。

2～3 分钟高分回答 ​

我会先把 Metric 当成正式业务对象，而不是一段文本。

一个 Metric Contract 至少要有：

metric_id
name
definition
owner
domain
region
valid_from / valid_to
aggregation
dimensions
source_dataset
version

用户说“GMV”，先基于：

User Scope
Domain
Region
Time

筛 Candidate，再用 Authority 和 Validity Resolve。

如果仍然有两个合法口径，比如：

• 订单 GMV；
• 支付 GMV；

这时候系统不应该静默猜，而应该追问用户，或者根据当前业务上下文选择并显式说明。

我认为最重要的是：

模型可以帮助匹配，不能拥有最终定义权。

项目映射 ​

建议准备一个你们实际存在的“指标别名 / 历史口径”例子。如果没有，也可以讲企业数据平台常见模式，但要明确说“这是行业常见做法，不是我们线上现状”。

高分亮点句 ​

Similarity 回答“像不像”，Authority 回答“谁有资格定义这个指标”。

面试官真正想听什么 ​

• 数据治理能力；
• Source of Truth 意识；
• 版本治理；
• Agent 与数据平台边界。

递进追问 ​

1. 指标更新如何通知 Agent？
2. 旧口径如何 Revoke？
3. Cache 怎么失效？
4. 指标跨 Region 怎么治理？

Red Flags ​

• “取 Embedding 相似度最高的。”
• “让模型自己判断哪个更合理。”

为什么这样回答 / 本题套路 ​

这是 权威性 / 决策题。答案不能从模型能力讲，要从数据治理对象讲，这样才能体现企业级 Data Agent 的深度。

3.6 Q20｜有 1000 张表、500 个指标、几十个业务域时，Agent 怎样做 Dataset / Metric / Field Discovery，而不是把全量 Schema 塞进 Context？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

规模上来以后一定要做分层 Discovery。我的思路是：

Intent
→ Domain Routing
→ Metric / Dataset Search
→ Permission Filter
→ Candidate Ranking
→ Load Relevant Schema

而不是把全量 Schema 交给模型。

2～3 分钟高分回答 ​

Schema 很少时，全量 Prompt 是合理的。

但到 1000 张表以后，会出现：

• Token Cost；
• Attention Competition；
• 同名字段混淆；
• Wrong Dataset；
• Permission Surface 扩大。

所以架构需要从：

Static Schema Injection

演进成：

Metadata Registry
→ Domain Namespace
→ Semantic / Keyword Search
→ ACL
→ Candidate Dataset
→ Lazy Load Schema

Dataset Metadata 可以包括：

• Description；
• Owner；
• Domain；
• Freshness；
• Common Metrics；
• Join Relation；
• Tags；
• Permission。

然后模型只看到当前任务真正相关的几张表。

项目映射 ​

如果你的 Data Agent 当前已经遇到 Schema 很大，可以直接讲演进。如果还没有到这个规模，可以说：

“我们当前规模下静态注入还可用，但如果扩到多业务域，我会优先把 Schema Discovery 独立出来，因为这是非常明确的 Scale Trigger。”

高分亮点句 ​

大规模 Data Agent 的关键不是让模型读懂更多 Schema，而是先把候选空间缩小。

面试官真正想听什么 ​

• 是否理解 Tool / Schema Explosion；
• 是否有规模化设计能力；
• 是否能讲 Architecture Evolution。

递进追问 ​

1. Search Recall 不够怎么办？
2. Dataset Metadata 谁维护？
3. Join Path 怎么发现？
4. 权限过滤在哪一步？

Red Flags ​

• “Context Window 够大，直接全部塞。”
• “只用 Vector Search。”

为什么这样回答 / 本题套路 ​

这是 架构演进型问题。高分回答应该先承认小规模方案当时合理，再解释什么时候失效，最后引出 Registry / Discovery。

3.7 Q21｜同一个问题既能走 SQL、BI Dataset、Knowledge RAG、Live API 时，Agent 怎样做 Source Routing？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我会先判断用户在问的是 定义、历史分析、实时状态还是混合问题，再决定 Source。Source Routing 错了，再强的模型也救不了。

2～3 分钟高分回答 ​

可以把 Query 大致分成四类：

Definition / Policy
→ Knowledge

Metric / Aggregate
→ SQL / BI Semantic Layer

Realtime State
→ Live API

Mixed Analysis
→ Multi-source Plan

例如：

“GMV 是什么？”

应该查 Metric Definition。

“今天 GMV 多少？”

应该走实时 Data Query。

“为什么下降？”

需要 Metric Definition + SQL Drill-down。

所以我不会简单用一个 Retriever，把所有 Source 文本化后统一召回。

更合理的是：

Query Understanding
→ Source Classification
→ Candidate Source
→ Execute / Retrieve
→ Evidence Merge

项目映射 ​

如果你们 Data Agent 里有 BI Dataset / SQL / 知识库并存，这题非常适合讲真实 Router。如果目前只有 SQL，可以说这是下一阶段扩源后必须解决的问题。

高分亮点句 ​

Retrieval 之前先选对 Source，比在错误 Source 上做更强 Rerank 更重要。

面试官真正想听什么 ​

• 是否理解多源数据系统；
• 是否会做 Source Routing；
• 是否会过度 RAG 化。

递进追问 ​

1. Routing 用规则还是模型？
2. Mixed Query 怎么拆？
3. Routing 如何 Eval？
4. Source 不可用怎么 Fallback？

Red Flags ​

• 所有问题都丢 RAG。
• 所有问题都转 SQL。

为什么这样回答 / 本题套路 ​

这是 方案决策题。先做 Query Type 分类，再推导 Source Choice，体现“不是所有数据问题都用同一个技术”。

3.8 Q22｜怎样避免“SQL 语法正确但业务语义错误”？生成前、执行前、执行后分别做什么校验？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会分三层：

生成前：Semantic Validation
执行前：Query Safety / Permission
执行后：Result / Business Verification

SQL 能跑通，只证明数据库接受了它，不证明回答了用户的问题。

2～3 分钟高分回答 ​

生成前先确认：

• Metric；
• Dataset；
• Time Range；
• Dimension；
• Grain；
• Join Path / Cardinality；
• Aggregation Semantics；
• Scope。

例如：

订单粒度
JOIN
商品明细粒度

如果没有明确 Grain / Cardinality，最容易产生“SQL 正确、指标被重复聚合”的 Silent Error。

执行前做：

• SQL Parse；
• Permission；
• Read-only / Write Policy；
• Query Cost Estimate；
• Full Scan；
• Cartesian Join / Explosive Join；
• Partition / Limit；
• Timeout / Cancellation Budget。

生产里尤其要避免：

一个错误 NL2SQL Query 没有泄露数据，却把 Warehouse 扫爆。

执行后做：

• Result Sanity；
• Null / Row Count；
• Known Range；
• Duplicate / Cardinality Check；
• Compare Baseline；
• Metric Invariant；
• Evidence。

例如用户问 GMV，但模型查成订单数，SQL 完全正确，必须在 Semantic Verification 阶段发现。

项目映射 ​

你可以准备一个真实“SQL 成功但答案错”的例子。哪怕只是 Dataset / Filter 选错，也足够有说服力。

高分亮点句 ​

Execution Success 是数据库维度的成功，不是业务问题维度的成功。

面试官真正想听什么 ​

• 是否懂 Verification；
• 是否把数据库报错当唯一 Failure；
• 是否有业务正确性意识。

递进追问 ​

1. Semantic Verification 能自动化吗？
2. 如何校验复杂指标？
3. Query Cost Gate 怎么做？
4. 如何处理无 Golden Answer 的问题？

Red Flags ​

• “SQL 执行成功就返回。”
• 只做 Syntax Validation。

为什么这样回答 / 本题套路 ​

这是 工程实现型题。按执行生命周期回答最清楚：Before Generation / Before Execution / After Execution。

3.9 Q23｜企业 Data Agent 怎样处理 Tenant、Row-level、Column-level、Field Masking、Purpose-based Access，为什么权限不能只靠 Prompt？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

权限必须在数据执行层强制生效，不能靠模型记住“不要查”。我的原则是：

User Identity
→ Delegated Agent Identity
→ Dataset / Row / Column / Purpose Policy
→ Query

而且无权限数据最好在进入模型之前就被排除。

2～3 分钟高分回答 ​

Prompt 只是行为提示，不是安全边界。

企业 Data Agent 的权限至少要考虑：

• Tenant；
• Dataset ACL；
• Row-level；
• Column-level；
• Masking；
• Purpose；
• Region。

我更倾向复用原有数据平台的权限体系：

User
→ Agent acts on behalf of user
→ Query Engine enforces policy

而不是让 Agent 用一个超级 Service Account，再靠 Prompt 控制。

因为一旦敏感数据已经进了 Context，即使最后不输出，泄漏风险已经发生。

还要特别注意 “数据没有进最终答案，但泄漏到了中间系统”：

Generated SQL
Query Result Sample
Context Snapshot
Trace
Eval Dataset
Cache
Artifact

这些对象都可能包含：

• 敏感字段名；
• Row-level 数据；
• 客户 ID；
• 商业指标；
• 查询条件。

所以安全 Scope 必须贯穿：

Query
→ Result
→ Context
→ Trace
→ Eval
→ Artifact

而不是只保护最终 Chat Response。

项目映射 ​

如果你们 Data Agent 已经接企业 Dataset，这里一定要准备“权限从哪里继承、谁执行校验、Agent 是否使用用户身份”的真实答案。

高分亮点句 ​

Prompt 可以约束模型行为，但不能承担 Authorization。

面试官真正想听什么 ​

• 企业安全意识；
• 是否懂 Delegated Identity；
• 是否会复用已有数据权限体系。

递进追问 ​

1. Cache 怎么避免跨租户？
2. Rerank 服务看到了敏感数据怎么办？
3. 审计怎么做？
4. Service Account 真的不能用吗？

Red Flags ​

• “在 System Prompt 里写用户不能访问的数据。”
• Agent 共用高权限账号。

为什么这样回答 / 本题套路 ​

这是 安全边界题。高分点是把“模型层行为约束”和“系统层权限强制”彻底分开。

3.10 Q24｜SQL 返回 100 万行结果时，怎样让 Agent继续分析，而不是把结果直接塞进 Context？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

原始结果应该留在 Data Plane，Context 只放决策需要的 Projection。

我会做：

Raw Result
→ Artifact / Table
→ Profile / Aggregate / Sample
→ Context

模型需要进一步分析时再生成下一条 Query。

2～3 分钟高分回答 ​

百万行结果直接塞模型有三个问题：

• Token 不可能承受；
• Attention 被噪声淹没；
• 大量原始数据可能包含敏感信息。

所以我会把结果持久化成 Artifact / Temporary Table，然后做 Profile：

• Row Count；
• Schema；
• Null Rate；
• Min / Max；
• Top-K；
• Distribution；
• Sample。

Context 里只保留：

summary
statistics
sample
query_handle
artifact_pointer

后续如果模型需要看某个 Region，再通过 SQL 对 Artifact / Source 下钻。

项目映射 ​

这和你 Data Agent 的 Generative UI 很适合结合：大结果可以作为 Table / Chart Artifact 展示，而模型只拿摘要和指针继续推理。

高分亮点句 ​

Agent 不应该“阅读百万行”，而应该“对百万行发起计算”。

面试官真正想听什么 ​

• 大数据结果处理；
• Context Engineering；
• Data Plane / Model Plane 分层；
• Generative UI / Artifact 思维。

递进追问 ​

1. Sample 怎么避免偏差？
2. Profile 成本会不会很大？
3. Artifact 生命周期怎么管理？
4. 用户要导出全量怎么办？

Red Flags ​

• “切成多个 Chunk 全塞进去。”
• “Context Window 大就没问题。”

为什么这样回答 / 本题套路 ​

这是 工程实现 + Context 题。核心不是“怎么压缩”，而是把 Raw Data 和 Model Context 分成两个 Plane。

3.11 Q25｜Data Agent 最终答案怎样验证？SQL 能执行成功为什么不等于业务答案正确？ ​

复习优先级：P1｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

我会把 Verification 分成四层：

Data
Semantic
Analysis
Conclusion

SQL 成功只覆盖第一层。

2～3 分钟高分回答 ​

Data Verification

Query 是否成功，数据是否完整。

Semantic Verification

Metric、Dataset、Time、Filter 是否选对。

Analysis Verification

计算、同比、环比、贡献率是否正确。

Conclusion Verification

最终 Claim 是否真的有 Evidence 支持。

例如：

SQL 查出销量下降 20%，但用户问的是 GMV，这就是 Data 层成功、Semantic 层失败。

生产里高价值问题可以加 Deterministic Verifier：

• 重算公式；
• 对比 Metric API；
• 检查 Time Window；
• 检查 Filter；
• 检查 Evidence Coverage。

项目映射 ​

你可以结合 Data Agent 最终结果展示：答案不只是文字，还应该保留来源、Query、Artifact、指标口径。

高分亮点句 ​

Model says done 不是 Data Question solved。

面试官真正想听什么 ​

• 是否真正理解 Verification；
• 是否区分模型输出和事实结果。

递进追问 ​

1. Verification 自己也会错怎么办？
2. 无法 Deterministic Verify 的分析题怎么办？
3. LLM Judge 能不能用？

Red Flags ​

• “执行 SQL 没报错就算成功。”
• “让另一个模型检查一下。”

为什么这样回答 / 本题套路 ​

这是 验证机制题。用分层 Verification 比简单说“加一个 Judge”更企业级，也能和通用 Agent Verification 方法统一。

3.12 Q26｜Data Agent 为什么必须输出 Evidence / Lineage？如何让用户知道结论基于哪些表、指标、过滤条件和时间范围？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为企业数据答案必须可复现、可审计、可质疑。Evidence 不是“模型解释”，而是能回到真实数据源的机器可验证引用。

2～3 分钟高分回答 ​

我会让每个关键结论绑定 Evidence Pack：

claim_id
metric_id / metric_version
dataset / table_version
query_id / SQL
time_range
filters
dimensions
grain
freshness / completeness
result snapshot / artifact
source owner

对于一次多轮分析，还应该记录：

Claim
→ Supporting Query / Artifact
→ Metric / Dataset Version

这样 Lineage 不只是“这条 SQL 来自哪张表”，而是能回答：

最终这句话是由哪一组数据证据支持的？

用户看到：

“A 地区贡献了 70% 的下降。”

应该可以展开看到：

• 数据来源；
• 时间范围；
• 指标口径；
• 查询；
• 样本 / 图表。

这样有三个价值：

1. 用户更信任；
2. Debug 更容易；
3. Eval 可以判断 Claim 是否 Grounded。

项目映射 ​

Data Agent 如果有 Generative UI，这里是很好的亮点：UI 可以直接把 Evidence / Chart / Table / Query 作为可交互 Artifact，而不是只输出一段 Chat 文本。

高分亮点句 ​

Evidence 不是解释得更像真的，而是让答案真的可以回源。

面试官真正想听什么 ​

• 可信 Data Agent；
• Lineage；
• 可审计性；
• UI / Artifact 设计。

递进追问 ​

1. Evidence 太多怎么展示？
2. SQL 要不要直接给用户？
3. 数据源变了以后旧 Evidence 怎么办？

Red Flags ​

• 把 CoT（Chain of Thought，内部推理过程）当 Evidence；
• 把“模型解释得很详细”误认为可审计；
• 只给自然语言“根据数据分析”，没有可回源 Query / Metric / Artifact。

为什么这样回答 / 本题套路 ​

这是 可信性 / 产品化题。应同时回答系统与 UX：Evidence 既是后端数据结构，也是用户信任界面。

3.13 Q27｜某次指标口径升级后，服务没有报错，但 Agent 大量回答旧口径，你怎么排查和修复？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

这是典型 Silent Semantic Regression。我不会先看模型，而会沿着：

Metric Version
→ Index
→ Cache
→ Context Snapshot
→ Generated Query
→ Answer

逐层 Diff。

2～3 分钟高分回答 ​

先确认 Metric Registry 的新版本有没有正确发布。

然后检查：

1. 旧 Metric 是否仍然 Eligible；
2. Knowledge Index 是否 Reindex；
3. Cache Key 是否带 Version；
4. Context Snapshot 是否还拿到旧定义；
5. Memory / Skill 有没有复制旧口径；
6. Query 是否绑定 Metric Version。

修复可能包括：

Revoke old metric
→ Invalidate cache
→ Reindex
→ Version-aware retrieval
→ Regression replay
→ Canary

最重要的是防复发：以后 Metric 变更必须进入 Knowledge Release 流程，而不是“改了 Wiki 就算完”。

项目映射 ​

如果你们真实发生过“指标变更 / Schema 变更 / Dataset 改名”导致 Agent 异常，这题是非常好的事故题。

高分亮点句 ​

最危险的不是系统 500，而是系统全绿但语义已经过期。

面试官真正想听什么 ​

• Debug 能力；
• Version / Cache / Lineage；
• 是否做过线上问题。

递进追问 ​

1. 如何快速止血？
2. Revoke 和 Delete 区别？
3. 怎么自动发现 Schema Drift？
4. 如何做回归集？

Red Flags ​

• “换模型。”
• “把 Prompt 再强调一次新定义。”

为什么这样回答 / 本题套路 ​

这是 故障诊断题。先建立根因链，再做排查顺序；最后一定补“怎么防复发”，这会明显体现生产经验。

3.14 Q28｜Data Agent 的 SQL Execution Success 很高，但用户仍反馈“答案不可信”，最可能是哪几层出了问题？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

SQL Execution Success 只能证明数据库层没失败。用户不信通常来自：

Intent
Semantic
Source
Freshness
Analysis
Evidence

这些层。

2～3 分钟高分回答 ​

我会把失败链拆成：

Question
→ Resolved Intent
→ Metric / Dataset
→ Query Plan
→ SQL
→ Result
→ Claim

逐层看。

典型问题：

• Intent 理解错；
• Metric 选错；
• Dataset 不是 Source of Truth；
• Time Window 不对；
• Join 错；
• 数据延迟；
• Filter 漏；
• 结果正确但解释过度；
• 没有 Evidence。

所以真正的成功率不能只用：

SQL Execution Rate

而应该有：

Semantic Accuracy
Metric Accuracy
Evidence Quality
Verified Task Success

项目映射 ​

可以从你们用户实际反馈里挑一种“SQL 没报错但答案不好”的问题做案例。

高分亮点句 ​

“能查出来”是数据库成功，“答对问题”才是 Data Agent 成功。

面试官真正想听什么 ​

• 是否懂分层质量指标；
• 是否会做 Failure Attribution。

递进追问 ​

1. 这些层怎么自动打标签？
2. 失败集怎么建立？
3. 用户反馈怎么变 Eval？

Red Flags ​

• 把“SQL 成功率高”当项目成功。
• 只优化模型 Prompt。

为什么这样回答 / 本题套路 ​

这是 Failure Attribution 题。要把一条业务结果拆成多层链路，展示“我知道正确率不是一个指标”。

3.15 Q29｜Data Agent 应该怎样评测？SQL Execution Accuracy、Semantic Accuracy、Metric Accuracy、Evidence Quality、Task Success 分别怎么测？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会做分层 Eval，不会只看 Text-to-SQL Benchmark。

最终最重要的是：

Verified Business Answer Success

但它下面要拆成 SQL、语义、指标、证据几个层，才能定位失败。

2～3 分钟高分回答 ​

可以设计五层：

1. SQL Execution Accuracy

SQL 能不能跑。

2. Semantic Accuracy

Dataset、Dimension、Time、Filter 是否选对。

3. Metric Accuracy

Metric Definition / Version 是否正确。

4. Evidence Quality

Source、Citation、Freshness 是否充分。

5. Task Success

用户问题是否真正解决。

Eval Set 来源：

• Golden / Verified Query；
• Historical BI Question；
• User Correction；
• Production Failure；
• Long-tail Domain。

这里我不会把“SQL 字符串 Exact Match（完全字符串匹配）”当成最高标准，因为：

不同 SQL
→ 可能得到完全等价的业务结果

更合理的 SQL 层 Eval 是：

Execution Success
+
Result Equivalence
+
Semantic Constraint Check

例如两个 Query 写法不同，但都正确使用同一 Metric、Time Window 和 Grain，应该被视为正确。

同时 Eval 本身也要做 Measurement Quality（测量质量）检查：

• Eval Set 是否代表线上任务分布；
• Ground Truth 是否过期；
• 是否有 Data / Prompt Leakage；
• LLM Judge 与 Human Label 的一致性；
• 3% 提升是否超过评测噪声；
• 是否只在简单 Segment 上提升。

然后把线上 Trace 做 Failure Mining，不断补回归集。

项目映射 ​

建议后面你把自己 Data Agent 现有的指标口径告诉我，我们可以把这题直接改成你项目的真实版本。

高分亮点句 ​

Eval 的目的不只是给一个总分，而是让失败可以归因。

面试官真正想听什么 ​

• 是否懂 Eval；
• 是否懂 Production Feedback Loop；
• 是否能做质量体系。

递进追问 ​

1. 没有 Golden SQL 怎么办？
2. LLM Judge 怎么用？
3. Offline 提升 3% 怎么判断有效？
4. Eval Dataset 怎么防 Leakage？

Red Flags ​

• “看 BLEU / exact match。”
• “用一个 LLM Judge 打分就够。”

为什么这样回答 / 本题套路 ​

这是 评测设计题。高分不是列指标，而是解释“为什么必须分层”和“如何形成线上反馈闭环”。

3.16 Q30｜Data Agent 如何同时优化模型 Token、Schema Discovery、Query Latency、Warehouse Cost 和端到端响应时间？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我不会先优化 LLM，而会先拆整个 Critical Path，找到真正瓶颈：

Intent
→ Schema Search
→ Model
→ Query Queue
→ Warehouse
→ Result Processing
→ Follow-up

然后按瓶颈优化。

2～3 分钟高分回答 ​

常见优化：

Context / Token

• Schema Lazy Load；
• Tool Search；
• Compaction。

Query

• Query Plan Cache；
• Pre-aggregation；
• Partition Pruning；
• Result Cache；
• Cost Estimate。

Model

• 小模型做 Routing；
• Reasoning Model 只处理复杂 Query。

Execution

• 独立 Query 并行；
• Partial Result；
• Async Long Query。

指标不能只看：

Token Cost

而要看：

Cost per Verified Analysis
P95 End-to-end Latency
Warehouse Scan Bytes
Task Success

项目映射 ​

如果你的 Data Agent 主要成本目前在模型，可以讲 Token；如果真正成本在查询引擎，就应该如实讲 Query / Warehouse。

高分亮点句 ​

Agent 性能优化一定看 Critical Path，不看单点最优。

面试官真正想听什么 ​

• 成本 / 性能工程；
• 是否会找真正瓶颈；
• 是否能做系统级优化。

递进追问 ​

1. Query Cache 怎么避免旧数据？
2. 为什么不全用最强模型？
3. Partial Result 如何设计？

Red Flags ​

• “换更快模型。”
• “压缩 Prompt 就行。”

为什么这样回答 / 本题套路 ​

这是 性能优化题。先建性能模型，再谈手段，避免成为优化技巧清单。

3.17 Q31｜Data Agent 从几十张表扩到上千 Dataset、再扩到跨域企业数据平台后，架构会怎样演进？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

我会把它看成三阶段：

几十表
→ Static Schema

数百表
→ Metadata / Semantic Discovery

跨域企业
→ Domain Routing + Federated Governance

真正发生变化的不是 SQL 生成，而是语义、权限、Ownership 和治理。

2～3 分钟高分回答 ​

阶段 1：小规模

Prompt + Schema

简单、快，当时合理。

阶段 2：数百表

出现：

• Token；
• Wrong Dataset；
• 同名字段；
• 权限复杂。

升级：

Metadata Registry
+ Search
+ Semantic Layer

阶段 3：跨域

又出现：

• 不同 Domain Owner；
• 不同 ACL；
• 不同 Region；
• 指标冲突；
• Freshness；
• Cost。

这时需要：

Domain Routing
Federated Knowledge
Metric Governance
Control Plane

核心判断 ​

架构升级不是因为“表数量达到某个数字”，而是 Failure Mode 发生质变。

项目映射 ​

这题非常适合讲你项目“现在在哪个阶段”和“下一阶段想演进到哪里”。

高分亮点句 ​

规模上升以后先坏的通常不是 SQL 生成，而是语义治理和 Ownership。

面试官真正想听什么 ​

• 架构演进；
• 是否理解 Trigger；
• 是否会过度设计。

递进追问 ​

1. 什么时候需要 Federated？
2. Control Plane 统一什么？
3. Domain Team 不愿接怎么办？

Red Flags ​

• 一开始就设计超级中央平台。
• 把规模问题全部归因于模型 Context。

为什么这样回答 / 本题套路 ​

这是 架构演进题。一定要说明“小规模旧方案为什么合理”，否则容易显得只会事后评价。

3.18 Q32｜Data Agent 做成企业平台以后，哪些能力应该平台统一，哪些必须留给 Data Domain / BI / Metric Owner？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我的原则是：

Platform owns Guarantees，Domain owns Meaning。

平台统一 Run、权限、Trace、Query Safety、Evidence Contract、Eval；Domain 拥有 Metric Definition、Dataset Meaning、Join Semantics、Data Quality Rule。

2～3 分钟高分回答 ​

平台适合统一的是跨业务稳定能力：

Run / Runtime
Identity / Permission Hook
Query Safety
Evidence Contract
Trace / Eval
Cost
Source Discovery Interface

Domain 必须保留：

Metric Definition
Dataset Meaning
Join Rule
Business Verification
Data Quality

为什么？

因为平台如果开始决定“GMV 到底怎么定义”，就变成数据语义中央审批瓶颈。

反过来，如果每个 Domain 自己做权限、Trace、Runtime，又会重复建设。

项目映射 ​

你现在做 Data Agent 平台时，这道题非常适合讲“哪些能力我们希望 SDK / 平台统一，哪些交给业务配置”。

高分亮点句 ​

平台应该统一“怎么可靠地做”，而不是统一“业务到底是什么意思”。

面试官真正想听什么 ​

• 平台边界；
• 组织 Ownership；
• P8 架构判断。

递进追问 ​

1. Metric Owner 不维护怎么办？
2. 平台怎么做 Extension？
3. Domain 自建能力怎么接入？

Red Flags ​

• “平台统一所有 Metric / Dataset / Workflow。”
• “各业务完全自治就好。”

为什么这样回答 / 本题套路 ​

这是 平台边界 / Leadership 题。回答一定要从“稳定不变量 vs 高变化语义”切入。

3.19 Q33｜现场设计一个企业级 Data Agent：要求支持多租户、统一指标口径、SQL / BI / API 多源、百万行结果、Evidence、权限和可观测性。 ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我会先定五个 Guarantee，而不是先画组件：

1. 语义正确；
2. 权限不穿透；
3. 大结果不直接进模型；
4. 结论可追溯；
5. 长任务可恢复。

然后再推导架构。

2～3 分钟高分回答 ​

我会分六层。

1. Interaction

Web / API
Run ID
Streaming

2. Semantic / Context

Intent
Metric Resolution
Context Builder

3. Knowledge

Metric Registry
Dataset Metadata
Business Knowledge

4. Planning / Routing

Planner
Source Router
SQL / BI / API

5. Execution

Query Engine
Artifact
Large Result Profile

6. Assurance

Identity / ACL
Evidence
Verification
Trace / Eval
Cost
Version

主链路：

User
→ Resolve Meaning
→ Select Source
→ Plan
→ Execute
→ Analyze
→ Verify
→ Evidence-backed Answer

规模化 ​

多租户还要有：

• Tenant Scope；
• Quota；
• Cache Isolation；
• Region；
• Audit。

项目映射 ​

这题可以直接拿你现有 Data Agent 架构做母图，但必须区分“当前实现”和“目标架构”。

高分亮点句 ​

我先定义系统必须保证什么，再决定要有哪些组件。

面试官真正想听什么 ​

• System Design；
• 是否能从约束推导架构；
• 是否会考虑非功能性要求。

递进追问 ​

1. 10 万并发怎么办？
2. 数据权限怎么做？
3. Metric Registry 宕机怎么办？
4. Query 长任务怎么恢复？
5. 成本怎么治理？

Red Flags ​

• 上来先列 15 个组件，没有目标 / SLO。
• 不提权限和 Verification。

为什么这样回答 / 本题套路 ​

这是 System Design 题。P7/P8 最重要的是先讲 Goal / Constraint / Invariant，再画架构，而不是组件百科。

3.20 Q34｜你在 Data Agent 项目里最关键的技术决策是什么？它解决了什么真实失败，指标改善多少，为什么是你来推动？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

这道题不能用通用答案，必须用你真实项目。最好的结构是：

Problem
→ Evidence
→ My Decision
→ Opposition
→ Implementation
→ Metric
→ Result

2～3 分钟高分回答 ​

你可以这样组织：

“我在这个项目里比较关键的一次决策，是把 ______ 从 ______ 演进成 ______。当时不是为了架构更复杂，而是我们已经观察到 ______ 的真实问题。”

然后：

“我当时判断根因不是模型本身，而是 ______。我们比较过 A / B / C 三种方案，最后选 B，因为 ______。”

再讲：

“我主要推动了 ______，包括 ______。上线前我们通过 ______ 验证，上线后核心指标从 ______ 到 ______。”

最后：

“这个方案也引入了新的复杂度，比如 ______。如果下一阶段规模继续放大，我会进一步做 ______。”

你可以考虑的真实主题 ​

只能选你真正做过的，例如：

• Schema 全量注入 → Discovery；
• NL2SQL → Semantic Layer；
• Raw Result → Artifact；
• 页面 State → Durable Run；
• 无 Evidence → Evidence-backed；
• Tool 静态注册 → Capability Discovery。

高分亮点句 ​

我不是为了“采用新技术”推动这次升级，而是因为旧架构已经出现了可量化的 Failure。

面试官真正想听什么 ​

• 你个人做了什么；
• 是否真正有技术判断；
• 是否有数据证明；
• 是否能推动落地。

递进追问 ​

1. 谁反对？
2. 为什么不选另外一个方案？
3. 如果重新做会改什么？
4. 你个人贡献占多少？

Red Flags ​

• 全程说“我们团队”。
• 没有明确 Decision。
• 没有 Metric。
• 把未来想法包装成已经上线。

为什么这样回答 / 本题套路 ​

这是 Ownership 题。知识点不是重点，真实性最重要。必须区分“我实际做过”“团队做过”“我认为下一阶段应该做”。

3.21 Q35｜底层 SQL 执行成功，但当天分区延迟、数据只到 80%、上游质量告警未恢复时，Data Agent 怎样识别 Freshness / Completeness 风险并避免给出“看起来正确”的答案？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

SQL 成功不代表数据可信。Data Agent 在 Query / Answer 前必须把 Freshness、Completeness、Data Quality State 当成 Evidence Eligibility 的一部分。

如果数据只完整到 80%，我宁愿降级、提示或回退到最近完整周期，也不能给一个高置信度结论。

2～3 分钟高分回答 ​

这类问题非常危险，因为整个链路可能都是“绿的”：

SQL valid
Query success
Chart rendered
LLM answer fluent

但真正的问题是数据不完整。

所以 Dataset Metadata 需要暴露：

expected_watermark
actual_watermark
completeness_ratio
quality_status
upstream_incident
owner

Query Planning 前先检查。

如果：

expected = 10:00
actual   = 08:00

或者关键 Partition 只完成 80%，系统可以：

1. 阻止强结论；
2. 标记 Partial / Stale；
3. 回退到最近完整周期；
4. 告诉用户当前数据状态；
5. 等数据恢复后 Re-run。

例如用户问：

“今天 GMV 为什么下降？”

真正原因可能只是数据还没落完。

进一步 ​

Data Quality 应该进入 Verification：

Claim
→ Supporting Query
→ Data Freshness / Completeness
→ Evidence Valid?

项目映射 ​

这题很适合体现你“数据领域”的差异化。普通 Agent Engineer 往往只关注 SQL 和模型，但 Data Agent 真正必须理解数据生产链和 SLA。

高分亮点句 ​

Data Quality 不是外围监控，而是“这份数据现在有没有资格支持这个结论”的一部分。

面试官真正想听什么 ​

• 数据工程基础；
• 企业级可信性；
• 是否真正懂数据生产链；
• 是否能识别 Silent Failure。

递进追问 ​

1. Freshness SLA 谁定义？
2. Partial Data 可以给用户看吗？
3. 多个 Source Freshness 不一致怎么办？
4. 数据恢复后是否自动 Re-run？

Red Flags ​

• “SQL 成功就说明数据没问题。”
• 只在最终文本里写一句“数据可能有延迟”。

为什么这样回答 / 本题套路 ​

这是 数据质量事故题。它非常适合区分“懂 Agent”和“真的懂 Data Agent”。回答要先指出 Silent Failure，再把 Freshness / Completeness 提升为 Evidence Contract 的一部分。

3.22 Q36｜用户问“为什么 GMV 下降”，Agent 发现 A 地区贡献了 70% 的下降，能不能直接说“A 地区导致了 GMV 下降”？怎样区分贡献分析、相关性和因果推断？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

不能直接这么说。

A 地区贡献了 70% 的下降 通常只证明：

在这次指标分解里，A 地区解释了大部分数值变化。

它并不自动证明：

A 地区是造成下降的因果原因。

我会严格区分：

Contribution Analysis（贡献分析）
Correlation（相关性）
Causal Inference（因果推断）

Data Agent 如果没有实验、准实验或明确因果模型，应该把答案表达成“主要变化来自哪里”，而不是“真正为什么发生”。

2～3 分钟高分回答 ​

这是 Data Agent 特别容易出现的一类高风险“讲故事”。

用户问：

“为什么 GMV 下降？”

Agent 做维度拆解：

Region A  -7%
Region B  -2%
Region C  -1%

可以合理说：

“从贡献分解看，Region A 占本次下降的 70%。”

但不能立即说：

“因为 Region A 的用户流失导致了整体 GMV 下跌。”

因为这里至少跨了两步：

数值贡献
→ 行为相关
→ 因果机制

真正的 Causal Claim（因果主张）通常还需要：

• Experiment / A/B Test；
• Natural Experiment（自然实验）；
• Difference-in-Differences 等准实验；
• Confounder（混杂因素）控制；
• 明确业务因果模型；
• 或足够强的外部 Evidence。

所以我会让 Data Agent 对结论做 Claim Type（主张类型）标记：

Descriptive
→ “下降主要集中在 A 地区”

Correlational
→ “A 地区下降与 X 指标同步变化”

Causal
→ “X 导致 A 地区下降”

只有 Evidence 达到对应等级时，才允许升级 Claim Strength（主张强度）。

真实项目怎么带 ​

如果你们 Data Agent 当前主要做 BI / Data Analysis，我建议面试时主动说：

“我们会非常谨慎地区分贡献分析和因果归因。没有因果证据时，我们只说‘主要变化来自哪里’，不会让模型自动升级成‘为什么发生’。”

这句话非常能体现数据领域专业性。

高分亮点句 ​

维度贡献回答“变化发生在哪里”，因果分析才回答“为什么会发生”。

面试官真正想听什么 ​

• 你是否理解分析与因果的边界；
• 是否知道 LLM 很容易把相关性讲成因果故事；
• 是否能控制 Data Agent 的 Claim Strength。

递进追问 ​

1. Data Agent 能自动做 Causal Inference 吗？
2. 如果没有实验数据，怎么回答“为什么”？
3. Contribution Analysis 怎么自动选维度？
4. 如何评测模型有没有过度因果化？

Red Flags ​

• “某维度贡献最大，所以它就是根因。”
• 只要 LLM 给出合理解释，就称为 Root Cause。
• 把 Correlation 当 Causation（因果关系）。

为什么这样回答 / 本题套路 ​

这是Data Analysis 边界 + 高阶可信性题。它不是额外堆一个算法知识点，而是在约束 Data Agent 的结论权限：先判断 Evidence 能支持哪一级 Claim，再决定模型可以说多强的话。这个问题能明显区分普通 NL2SQL / BI Chat 与真正懂数据分析边界的高级 Data Agent 候选人。

四、把 Knowledge Architecture 与 Data Agent 真正连起来 ​

4.1 为什么企业 Data Agent 不能只是一套 NL2SQL ​

把本篇两部分连起来，可以得到一条更完整的链：

Knowledge Layer
→ 负责“指标 / Dataset / Policy / Schema 到底是什么意思”

Data / Tool Layer
→ 负责“当前真实数据是多少”

Agent
→ 负责“下一步应该问什么、查什么、怎样下钻”

Verification
→ 负责“最后这个结论是否真的被 Evidence 支持”

所以一个企业 Data Agent 如果只有：

User Question
→ LLM
→ SQL
→ Result

本质上仍然只是一个增强版 Query Generator（查询生成器）。

真正走向企业级以后，需要补：

Semantic Grounding
Authority
Permission
Freshness
Source Routing
Evidence
Evaluation
Lineage

4.2 两种“看起来成功、其实失败”的典型场景 ​

场景一：SQL 全部成功，但语义错 ​

用户问 GMV
→ Agent 选成订单金额
→ SQL 正常执行
→ Chart 正常显示
→ LLM 正常解释

所有系统指标都可能是绿色，但业务答案错。

场景二：指标定义正确，但数据不完整 ​

Metric 正确
→ Dataset 正确
→ SQL 正确
→ 当天 Partition 只完成 80%
→ Agent 得出“GMV 大幅下降”

真正原因只是数据还没落完。

这两类问题说明：

企业 Data Agent 的核心质量，不是“查询能不能跑”，而是“语义、数据、分析、Evidence 四层能不能同时正确”。

4.3 Data Agent 的统一 Failure Taxonomy ​

面试时如果问：

“Data Agent 为什么会答错？”

不要只说“模型幻觉”。

可以按下面的 Failure Taxonomy（故障分类）回答：

Intent Failure
→ 用户问题理解错

Semantic Failure
→ Metric / Dimension / Time 选错

Source Failure
→ Dataset / API / Knowledge Source 选错

Permission Failure
→ 看到了不该看的数据

Freshness / Quality Failure
→ 数据延迟、不完整、异常

Planning Failure
→ 分析步骤不合理

Execution Failure
→ SQL / API / Tool 执行失败

Analysis Failure
→ 计算或归因错误

Evidence Failure
→ 证据不足或引用错误

Causal Claim Failure
→ 贡献 / 相关性被错误升级成因果结论

Generation Failure
→ Evidence 正确但最终表述错误

这套分类的价值是：

出现最终答案错误以后，能快速归因到系统层，而不是统一甩给模型。

4.4 Data Agent 的统一 Evaluation Stack ​

对应上面的 Failure Taxonomy，可以形成：

Semantic Eval
↓
Source Routing Eval
↓
SQL / Tool Eval
↓
Data Quality Eval
↓
Evidence Eval
↓
Claim Strength / Causal Safety Eval
↓
Answer Eval
↓
Task Success

最终最高层建议关注：

Verified Business Answer Success（经验证的业务回答成功率）

而不是只看：

SQL Execution Rate
Text-to-SQL Exact Match
LLM Judge Score

五、P7+～P8 面试里怎样讲好 Data Agent ​

5.1 不要把项目讲成“技术栈介绍” ​

低质量：

我们用了某模型
+ 某 Framework
+ Vector DB
+ SQL Tool

高质量：

业务问题是什么
↓
为什么传统 BI / NL2SQL 不够
↓
真正的 Failure 在哪里
↓
为什么做这次架构升级
↓
我主导了什么
↓
指标怎么变化
↓
新复杂度是什么

5.2 推荐准备三个真实故事 ​

不要准备 21 个故事。

准备三个足够强的真实故事，就能覆盖大量追问：

故事 A：语义 / 指标问题 ​

例如：

Metric / Dataset 选错
→ 为什么原方案看起来合理
→ 怎么发现
→ 怎么治理

故事 B：生产 Failure ​

例如：

数据延迟
权限
Query Cost
Large Result
Context Regression

故事 C：架构演进 ​

例如：

Schema 全量注入
→ Dataset Discovery

NL2SQL
→ Semantic Layer

Raw Result
→ Artifact / Generative UI

只能选择你真正发生过或正在建设的内容。

5.3 项目事实与架构推演的推荐表达 ​

如果当前并没有完整实现某个高级机制，可以这样说：

“我们当前线上实际做到的是 A。随着 Dataset / 用户规模上来，现在已经看到 B 的问题。我的判断是达到 C Trigger 后，下一步应该演进到 D，因为 D 能解决……但它会新增 E 的治理成本。”

这种表达比：

“我们已经有完整 Knowledge Control Plane。”

更可信，也更高级。

六、本篇 2～3 分钟总复述 ​

如果面试官让你整体讲：

“你怎么理解企业 Knowledge 和 Data Agent？”

可以这样回答：

“我会先把 Knowledge 和 RAG 区分开。RAG 只是把相关内容取给模型的一种方式，企业 Knowledge 真正还要解决 Source of Truth、Authority、Freshness、ACL、Version、Conflict、Lineage 和 Eval。Search Relevance 只回答‘像不像’，并不能回答‘谁有资格定义事实’。

对 Data Agent 来说，这个问题更明显。Data Agent 也不是单纯 Text-to-SQL，因为一个企业数据问题要先解决 Metric / Dataset 的 Semantic Grounding，再决定走 SQL、BI、Knowledge 还是 Live API；查询以后还要处理大结果、数据 Freshness、Evidence 和 Verification。SQL 能执行成功，只说明数据库接受了 Query，并不代表业务问题回答正确。

所以我整体的架构判断是：Knowledge Layer 负责业务事实和语义，Data / Tool Layer 负责当前事实计算，Agent 负责动态分析决策，Verification 负责证明最终结论。真正企业级以后，Permission、Evidence、Eval、Lineage 和 Domain Ownership 都必须成为一等能力。”

七、业界实现证据与边界 ​

本篇引用当前官方产品，只用于验证“这些工程问题真实存在”，不要求面试背产品 Feature。

• [R1] Microsoft Foundry IQ / Azure AI Search Agentic Retrieval：当前官方文档把 Multi-source Knowledge Base、Permission-aware Retrieval、Keyword / Vector / Hybrid Search、Agentic Retrieval、Citation 等建模成共享知识层能力；官方同时明确说明 Foundry IQ / Agentic Retrieval 的成熟度取决于具体 API / Portal 能力，部分已经 GA、部分仍处于 Preview，因此面试中应把它作为架构证据，而不是默认全部能力都已适合生产。
  https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/what-is-foundry-iq
  https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview

• [R2] AWS Bedrock Knowledge Bases — Retrieval Filter：官方 API 把 Metadata Filter 建模为 Retrieval 前的显式过滤能力。
  https://docs.aws.amazon.com/bedrock/latest/APIReference/API_RetrievalFilter.html

• [R3] AWS Bedrock — Reranking Metadata Configuration：官方 API 支持控制哪些 Metadata 参与 Reranking。
  https://docs.aws.amazon.com/bedrock/latest/APIReference/API_MetadataConfigurationForReranking.html

• [R4] Snowflake Cortex Analyst Evaluations：使用 Verified Queries 作为 Ground Truth，执行生成 SQL 并跟踪 Correctness、Regression、Latency。
  https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst-evaluations

• [R5] Snowflake Cortex Analyst Verified Query Repository：Verified Query 作为 Semantic View / Model 的可信 SQL 示例与评测基础。
  https://docs.snowflake.com/en/user-guide/views-semantic/verified-query-repository

• [R6] Databricks AI/BI Genie — Knowledge Store / Trusted Assets：官方文档把 Table / Column Description、Join Relationship、Measure、Filter、Dimension、Verified / Trusted Query 等作为显式语义资产，并说明结构化 SQL Expression 能比纯文本 Instruction 更一致地表达业务逻辑。
  https://docs.databricks.com/gcp/en/genie/add-instructions
  https://docs.databricks.com/aws/en/genie/talk-to-genie

产品会继续变化，真正应该掌握的是稳定机制：

text

Authority
Permission
Freshness
Retrieval
Evidence
Verification
Eval
Governance

八、本篇最终记忆锚点 ​

如果只记 13 句话：

1. RAG 是 Knowledge Consumption，不是完整 Knowledge Architecture。
2. Vector DB 是索引组件，不是企业知识的 Source of Truth。
3. Relevance 回答“像不像”，Authority 回答“谁有资格定义事实”。
4. Knowledge 和 Memory 的根本差异是 Authority、Lifecycle、Ownership。
5. Chunk Size 是实现参数，Knowledge Unit 才是业务语义。
6. 先选对 Source，再谈在 Source 里怎么 Search。
7. Permission 应该决定 Candidate Eligibility，而不是最后输出时再过滤。
8. Revoke 是立即停止使用，Delete 是最终彻底清理。
9. SQL Execution Success 不等于 Business Answer Correct。
10. Data Agent 最难的往往不是 SQL Syntax，而是 Semantic Grounding。
11. Data Quality 决定 Evidence 有没有资格支持结论。
12. Data Agent 不是把自然语言翻译成 SQL，而是把业务问题翻译成一条可验证的数据分析链路。
13. Contribution ≠ Causation；变化主要来自哪里，不等于真正为什么发生。

九、本篇最容易拉开候选人差距的专家判断 ​

1. Relevance 决定“像不像”，Authority 决定“谁有资格定义事实”。
2. Data Agent 最大风险往往不是 SQL Syntax，而是“SQL 完全可执行，但业务语义错”。
3. 数据 Freshness / Completeness 不是监控附属项，而是 Evidence Eligibility（证据可用资格）的一部分。
4. Metric / Dataset / Schema / Live Data / User Memory 必须按 Authority 与 Lifecycle 分层，不能统一做成 RAG。
5. 百万行结果的正确做法不是压缩得更聪明，而是让 Compute Engine 负责计算，LLM 只消费小型 Evidence。
6. Contribution Analysis 回答“变化发生在哪里”，Causal Inference 才回答“为什么发生”。
7. 企业 Data Agent 的可信度来自“语义 + 数据质量 + Evidence + Verification”同时成立，而不是 SQL Execution Success。