OPENING30 秒开口版
我会把这件事讲成从业务语言到可执行查询计划的映射链路。用户不会说表名字段名，他会说“AI x Crypto 未 TGE 项目里，哪些融资强、热度上涨”。系统先通过 glossary 和 entity resolution 理解业务词和实体，再通过 semantic registry 找指标、维度、关系和版本口径，然后用 schema linking 把它们映射到 projects、tokens、funding_rounds、funding_participants、score_snapshots、entity_relationships 等表，最后由 semantic-plan 生成可执行的 SQL、搜索或图查询计划。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Glossary：业务术语和别名词典 Semantic Registry：指标、维度、关系、口径和版本的注册中心 Entity Resolution：处理项目改名、Token 重名、机构别名的实体消歧 Schema Linking：把业务词连接到表、字段和 join path |
| 为什么这样回答 | 开口要把“业务词”和“表字段”之间的中间层讲出来，避免显得只是 prompt 堆规则。 |
| 小白解析 | 用户说人话，数据库说表字段，语义层负责翻译。 |
| 关联知识点 | Modeling Layer 文档把 MDL 定义为 Physical Schema 和 Business Language 中间的抽象层。 |
1 MIN一分钟口语版
展开讲，我会分五步。第一步是业务词典，维护未 TGE、融资强、顶级投资人、解锁压力、透明度低等术语。第二步是实体解析，把项目名、slug、Token symbol、机构简称、官网域名、合约地址映射到唯一 entity_id。第三步是语义建模，把稳定口径沉到 semantic registry，比如融资强由金额、轮次、投资人质量和时间窗口组成；解锁压力由未来解锁金额、供应占比和流通市值组成。第四步是 schema linking，把这些语义对象映射到物理表和字段，并用 relationships 限定 join path。第五步是 semantic-plan，把用户问题转成指标、维度、过滤、排序和执行引擎选择。这样 SQL 生成不是临场猜，而是基于版本化语义和授权 schema。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Metric：带聚合或计算逻辑的业务指标 Dimension：用于分组、过滤和排序的业务维度 Relationship：声明式 join 路径和实体关系 Semantic Version：指标和语义口径的版本 |
| 为什么这样回答 | 一分钟版用五步结构，很适合面试现场背：词典、实体、语义、schema、计划。 |
| 小白解析 | 先认出你问的是谁，再理解你问的业务词，再找到对应表字段，最后生成查询计划。 |
| 关联知识点 | text2sql 的 semantic-plan 正是把 retrieve 和 assemble-context 的材料转成生成 SQL 前的可执行意图。 |
LINKING GOALS语义连接目标
业务词可治理
未 TGE、融资强、顶级投资人不是 prompt 里的散句，而是版本化语义资产。
实体可消歧
项目别名、Token 符号、机构简称必须解析成 entity_id 和 entity_type。
表结构可解释
表、字段、关系、指标、维度都有描述和权限，不让模型猜。
join path 可控
多表关联来自 relationships，不靠 LLM 自由发挥。
口径可版本化
热度、透明度、融资强度等口径变化后，runId 仍能回放当时版本。
下游合同稳定
报告 Agent 消费 semantic objects 和 data pack，不依赖物理表细节。
DIAGRAM业务语言到查询计划
从用户问题到物理查询
Web3 业务词映射示例
TABLE业务语义和表结构映射
| 业务表达 | 语义对象 | 可能映射 |
|---|---|---|
| 未 TGE 项目 | Token 状态维度 | tokens.token_status、tokens.tge_date、projects.token_status |
| 融资强 | 融资强度指标 | funding_rounds.amount_usd、round_type、announced_date、lead investor |
| 顶级投资人 | 机构质量维度 | organizations.org_type、funding_participants.is_lead、portfolio quality |
| 热度上涨 | 评分趋势指标 | score_snapshots.score、score_type、date、delta |
| 解锁压力 | Token 风险指标 | token_unlock_events.amount_usd、percent_supply、unlock_date |
| 共同投资网络 | 关系路径 | funding_participants、funding_rounds、entity_relationships |
| 项目基本面 | 组合分析对象 | 团队、融资、Token、新闻、评分、关系图谱和来源证据 |
面试时不要把映射讲成“写几个 prompt 示例”。资深说法是把业务术语、指标、关系、实体和版本都资产化，再让 semantic-plan 消费这些资产。
INTERVIEW MAP面试表达地图
- 先讲断层用户说业务语言，数据库是物理 schema，中间必须有语义层。
- 讲五类资产glossary、entity resolution、semantic registry、schema registry、relationship graph。
- 讲映射链路术语和实体 -> 指标维度 -> 表字段和 join path -> semantic-plan -> query。
- 讲版本治理指标口径变化要 semanticVersion，runId 回放要知道当时口径。
- 讲下游稳定报告 Agent 不直接依赖表名，而依赖稳定 semantic contract。
SUBAGENTS面试官和候选人模拟
本章继续沿用第一章的两个 subagent 视角：面试官 subagent 负责追问架构边界、失败模式、评测、治理和下游报告 Agent；候选人 subagent 负责把回答压成现场能讲出来的中文，并且把每个观点落到流程节点、数据对象、合同或工程权衡。
本章追问重点：业务词到底怎么落到表字段？口径变化怎么办？join path 谁来约束？
Q&A20 组高强度追问
面试官：你如何把“未 TGE、融资强、顶级投资人、生态项目、解锁压力”映射成可查询字段？
我不会让模型临场猜，而是放进 glossary 和 semantic registry。比如未 TGE 映射 token_status 和 tge_date，融资强映射金额、轮次、投资人质量和时间窗口，解锁压力映射 token_unlock_events 和供应占比。
业务语义、模糊词与默认口径：语义映射章主讲业务词如何落表，语义层和澄清章主讲默认与追问边界。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：业务语义层是单独设计，还是直接写在 prompt 里？为什么？
要单独设计。prompt 里的规则不可治理、不可版本化、不可复用；semantic registry 能被 RAG、planner、SQL generator、报告 Agent 和评测共同消费。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：用户说“最近很热的项目”，系统如何知道对应哪些表、字段、时间窗口？
glossary 解释“热”的业务含义，semantic registry 指向热度指标，schema linking 映射 score_snapshots 或 ranking index，intake 把“最近”转成时间窗口，semantic-plan 生成排序和过滤条件。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：表结构变化时，如何避免 Text2SQL 继续生成旧字段或错误 join？
schema registry 要和数据源同步，旧字段从 active semantic version 下线，RAG 索引重建，validate 阶段解析 SQL 检查字段存在性和关系路径。报告 Agent 依赖 semantic contract，可以减少物理表变化冲击。
Schema linking、schema 变更与 join path：语义映射章主讲 join path，流程和优化章只从生成稳定性角度补充。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：项目、Token、机构、融资轮次、新闻事件之间的实体关系怎么建模？
核心实体用 projects、tokens、organizations、people、funding_rounds、news_articles 等表，关系用 funding_participants、project_tags、project_ecosystems、entity_relationships 和 source_documents 连接。图谱用于多跳关系，SQL 用于统计。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：业务词典、schema registry、指标口径、样例问题，这几类知识分别放在哪里？
业务词典放 glossary，表字段和权限放 schema registry，指标维度关系放 semantic registry，样例问题和历史 SQL 放 RAG examples。它们都能被 retrieve 和 semantic-plan 使用，但职责不同。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：多表 join 很容易错，如何让模型知道正确 join path？
join path 由 Modeling Layer 的 relationships 声明，比如 projects -> funding_rounds -> funding_participants -> organizations。semantic-plan 选择路径，generate-sql 按路径生成，validate 再检查是否引用了授权关系。
Schema linking、schema 变更与 join path：语义映射章主讲 join path，流程和优化章只从生成稳定性角度补充。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：下游报告 Agent 要稳定拿数据，语义层要暴露什么 contract？
它应该暴露任务级 semantic contract，比如 metric、dimension、entity、timeRange、filters、evidenceRequired、outputSchema，而不是直接让报告 Agent 拼表名和字段。这样物理表调整时报告模板不容易断。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：如何评测“用户问题到数据库表结构”的映射是正确的，而不是 SQL 恰好能跑？
评测样本要标注 gold tables、gold columns、gold metrics、gold join path 和 gold evidence。SQL 能跑只是底线，还要看字段、过滤、聚合、时间窗口和口径是否匹配 semantic-plan。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：Entity Resolution 放在架构哪里？
放在 Knowledge/Semantic 层，intake 和 retrieve 都要调用。它先把用户提到的项目名、Token symbol、机构别名解析为候选实体，低置信进入澄清，高置信进入 semantic-plan。
Entity resolution、Token 重名与实体消歧：语义映射章主讲实体解析位置，RAG、优化、澄清和排障章分别补充召回、优化、交互和定位。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：Token 符号重复怎么办？比如同一个 symbol 对应多个项目。
不能只靠 symbol。要结合项目名、链、合约地址、官网、上下文标签和用户历史意图消歧；如果仍然低置信，直接澄清，不生成可能错对象的 SQL。
Entity resolution、Token 重名与实体消歧：语义映射章主讲实体解析位置，RAG、优化、澄清和排障章分别补充召回、优化、交互和定位。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：“顶级投资人”这种主观词怎么治理？
把它变成版本化规则，比如机构类型、历史 lead 次数、portfolio 质量、最近活跃度、是否知名基金等。delivery 要说明当前口径，避免用户以为这是模型主观评价。
业务语义、模糊词与默认口径：语义映射章主讲业务词如何落表，语义层和澄清章主讲默认与追问边界。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：schema 描述要写多细？
要足够让模型和人理解字段含义、单位、更新时间、权限、来源和典型用法。尤其是 amount_usd、valuation_usd、percent_supply、score 这类字段，不写口径很容易答错。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：semanticVersion 为什么重要？
Web3 指标经常变化，比如热度权重、透明度分、顶级投资人名单。如果不锁版本，同一个 runId 回放时可能用到新口径，报告无法复查。
Semantic version 与指标口径回放：语义层主讲口径版本锁，架构和时效章补充 runId 回放与历史报告。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：业务领域和数据库不是一一对应时怎么办？
用 semantic objects 做中间层。一个业务概念可以映射多个表字段，一个表字段也可能服务多个业务概念；planner 根据任务选择具体物理计划。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：如何处理结构化数据和非结构化来源的连接？
结构化字段要带 source_id 或 provenance，RAG 通过 source_documents/news 找来源证据。比如 funding_rounds.amount_usd 对应公告或新闻，delivery 同时给 SQL 结果和来源引用。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：如果业务用户说“优质项目”，系统能直接查吗？
不能直接查，除非语义层定义了优质项目的口径。否则要澄清：按融资、团队、热度、Token、透明度还是生态关系判断。好的系统会给可选口径，而不是擅自解释。
业务语义、模糊词与默认口径：语义映射章主讲业务词如何落表，语义层和澄清章主讲默认与追问边界。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：schema linking 和 RAG 有什么关系？
RAG 负责召回可能相关的 schema、术语、样例和关系，schema linking 负责从中选择真正用于当前问题的表字段和路径。RAG 是候选来源，linking 是决策。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：如何让业务语义被前端、后端、报告 Agent 共同复用？
用共享 semantic registry 和 delivery contract。前端展示指标解释，后端生成查询，报告 Agent 消费 data pack，三者引用同一个语义版本和 evidence。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
面试官：面试里一句话总结这章，你怎么说？
我会说：我不是让模型从问题直接跳到 SQL，而是在中间加 glossary、entity resolution、semantic registry、schema linking 和 join path，把业务语言变成版本化、可治理、可执行的查询计划。
理解与记忆 · 背后工程点
背后工程点：领域语义到表结构的连接要靠 semantic registry、glossary、schema linking、entity resolution 和 join path。
专业术语：Schema Linking 是把问题中的实体和指标连接到表字段；Semantic Registry 是保存指标、维度、关系和版本化口径的注册中心；Join Path 是多表之间可执行的关联路径。
为什么这样回答：这样回答能说明你不是把业务规则塞 prompt，而是把它们做成可治理资产。
小白解析：用户说的是“融资强”，数据库里是金额、轮次、投资人、时间窗口，语义层负责把两边接起来。
关联知识点：Modeling Layer 文档把 MDL 定义为物理数据库和业务语言之间的抽象层，包含 Models、Relationships、Metrics、Dimensions。
PRINCIPLE本章背诵原则
- 别让 prompt 承担语义层：业务规则要资产化、版本化、可评测。
- 实体先消歧：项目、Token、机构不消歧，后面 SQL 再正确也会查错对象。
- 指标要有口径：融资强、热度、解锁压力都要能落到字段和计算逻辑。
- join path 要声明：多表关联不能靠 LLM 猜。
- 评测看映射：不仅看 SQL 能跑，还要看表、列、指标、时间窗口和证据是否正确。