“找出最近 14 天可以加预算的 campaign”是一句自然的业务问题，也是一条危险的 SQL 生成指令。加预算依据什么：ACOS、ROAS、贡献利润还是新品份额？最近 14 天按 profile 当地日还是 UTC？归因窗口是否成熟？campaign 下若有缺货 ASIN，聚合表现还能否代表全部投放对象？如果系统只把表结构和问题交给大模型，模型很可能生成语法正确、业务边界错误的查询。
自然语言问数的可靠性不取决于 prompt 写得多长，而取决于系统是否存在可检查的编译链。问题不能直达 SQL，必须先落成业务意图，再绑定时间和指标契约，选择合法实体路径，生成受权限约束的逻辑计划，执行后验证结果能否支持决策。 五道门中任一道无法通过，正确输出都是拒答或降级，而不是补齐一个看似合理的数字。
背景：问数入口变自然了，错误路径却更隐蔽
传统 BI 把可选指标、维度和筛选项放在界面上，用户的自由度有限，错误常暴露在配置阶段。自然语言把入口变得友好，也把错误推迟到执行阶段。用户不需要知道 search term、targeting、placement 和 advertised product 来自不同报告，模型却可能从相似字段名推断它们可以连接。
自然语言工单拆解台把本节的判断压缩成可检查的关系：把业务问题拆成对象、指标、时间和动作。人物动作对应执行责任。
Amazon Ads Dimensions library给出广告报告维度，Profiles API提供 marketplace、currency 与 timeZone，Reporting FAQ描述报告生成与更新边界。三者合在一起才构成一部分查询语境。只给模型一张宽表，等于把这些制度差异提前抹平。
错误也更难被察觉。一个搜索词与 placement 的查询，模型按 campaign/date 把两张事实表连接，分子和分母同时被复制，ACOS 可能仍然相同。结果没有异常值，业务也未必立刻发现。直到这个数字进入 budget 或 bid 动作，隐藏的粒度错误才变成真实损失。
因此，问数 Agent 的产品目标不能写成“让用户用自然语言查询所有数据”。更准确的目标是：在被治理的业务问题集合内，用自然语言生成可解释、可验证、可拒绝的查询。覆盖率可以逐步扩大，语义边界不能靠模型自信填补。
当下问题：Schema 加 Prompt 为什么仍会答错
第一，schema 只说明列存在，不说明列能怎样使用。sales 可能是广告归因销售、订单销售、净销售或集团换算销售；date 可能是报告日、下单日或快照日；asin 可能是 advertised ASIN、purchased ASIN 或 parent ASIN。字段注释能缓解歧义，不能表达聚合、窗口和路径限制。
对象绑定卡尺阵列把本节的判断压缩成可检查的关系：确认 campaign、target、search term 与 ASIN 身份。人物动作对应执行责任。
第二，示例 SQL 会诱导而不会治理。把十条正确查询放进 prompt，模型可能学会常见 Join，却无法判断第十一条问题是否需要新的 grain。示例过多还会让旧口径继续存活。真正的规则应进入机器可执行的语义模型和验证器，示例只用于帮助意图解析。
第三，生成后修补无法覆盖系统性错误。语法校验能发现列不存在，无法发现 ratio 被平均、归因未成熟、跨币种未换算或库存快照过期。让另一个 LLM 审查 SQL，两个模型仍可能共享相同错误假设。
第四，权限不能只在数据库末端过滤。若模型先看到全部 ASIN、搜索词和利润字段，再由结果层删行，敏感信息已经进入上下文；若行级策略在 Join 后才生效，还可能改变聚合分母。Cube access policies展示成员、行级和掩码策略进入数据模型的方式，值得借鉴的是“查询编译前知道谁能看什么”。
编译机制：问题必须经过五种中间表示
第一种是意图表示，记录决策目的、对象、时间范围、比较方式和预期输出。“可以加预算”不能直接映射成过滤条件，必须解析为 strategy intent，例如 scale_profitable_campaigns，并引用获批的利润、库存和风险策略。
第二种是语义请求，绑定 metric ID、dimensions、filters、time role、timezone、currency、maturity 和 access context。界面仍可显示 ACOS，底层必须知道是哪个广告产品、哪个归因窗口和哪种 ratio-of-sums。
第三种是实体路径计划。它明确从 Campaign 到 AdGroup、Target、AdvertisedProduct、ASIN、Inventory 和 Profitability 的合法关系，标出每段基数、有效期与 fanout 风险。Cube Joins强调 Join 方向、主键和 fanout，Cube Views则用 curated view 固定可用路径。Amazon Ads 需要在此基础上增加报告 grain 禁止表。
第四种是逻辑查询计划，表示聚合顺序、过滤下推、货币换算、时间成熟度和权限策略。它还不包含数据库方言，可以在执行前做静态检查。第五种才是物理 SQL，包括目标仓库、表版本、参数化条件、扫描预算与超时。
这种中间表示不是为了增加层数，而是让不同错误在最接近根因的位置被发现。意图不清在第一层追问，指标不兼容在第二层拒绝，Join 路径不存在在第三层停止，权限冲突在第四层裁剪，数据库语法和成本在第五层处理。
第一道治理门：先绑定业务意图和时间契约
“表现最好”没有稳定含义。新品 campaign 可能看 search term discovery 与新客覆盖，成熟商品看贡献利润与库存周转，品牌防守看流量保护和边际成本。意图解析器先从受控 strategy catalog 选择候选，无法确定时返回澄清项，不允许自己发明 KPI。
指标契约齿轮箱把本节的判断压缩成可检查的关系：校准分子分母、粒度、窗口与币种。人物动作对应执行责任。
时间契约随后确定 profile local date、观察窗口、归因成熟期、比较基线和截止时点。最近 14 天若包含尚未成熟日期，系统可以排除、分层展示或将结果标记 provisional；具体方式由 strategy 决定。用户说“昨天”，系统先确定 marketplace 时区，不使用 Agent 运行机器的本地时间。
dbt Semantic models把实体、维度和时间维度组织成语义图，dbt metrics定义指标组合。可借鉴其结构，但 Amazon Ads 意图还需要广告产品、归因窗口、报告版本和动作风险。
语义请求必须是结构化对象，不能只保存模型解释文本。例如：metric=contribution_after_ads_v3、entity=campaign、time_role=profile_report_date、window=14d、maturity=stable_only、inventory_policy=cover_21d。每个值来自 registry，模型只能选择，不能临时改公式。
第二到四道治理门：实体路径、指标计划与权限
实体路径门先检查问题是否有真实 grain。用户问“每个 search term 在 Top of Search 的利润”时，如果源数据没有 search term × placement 联合事实，系统应明确说明不可直接计算，并提供两个合法替代：分别查看 search term 与 placement 表现，或切换到确实提供联合粒度的数据产品。生成一个近似 Join 不是帮助，而是制造事实。
关系路径道岔图把本节的判断压缩成可检查的关系：选择合法连接路径并阻断扇出。人物动作对应执行责任。
指标计划门检查聚合。ACOS、TACOS、转化率等比值必须聚合分子和分母后重算；库存 snapshot 不能按天求和；COGS 按 SKU 和有效期连接；currency 在聚合前按批准的汇率日期转换。计划还计算 coverage，若只有 70% ad spend 能映射到有效利润版本，结果名称和置信等级都要反映这一限制。
MetricFlow提供语义请求到查询计划的实现参考，Snowflake Semantic Views把 facts、dimensions、metrics 和 relationships 定义为数据库对象，Databricks metric views则提供集中指标与 Agent metadata。产品选择可以不同，治理要求相同：指标与路径先于 SQL。
权限门基于用户、组织、profile、marketplace、字段敏感度和用途生成可见语义子图。投放运营可以看 campaign 与 search term 表现，财务利润可能只给区间或批准指标，外部服务商只能访问授权 profile。权限变化会改变可用指标和路径，不是执行后简单删行。
Wren MDL的 Model、Column、Relationship 与 Cube 提供另一种语义中间表示参考，Cube introduction把建模、访问控制、缓存和 API 放在同一运行时。对 Amazon Ads 而言，任何工具都不能替代业务 owner 对 grain、窗口和策略的审批。
第五道治理门：执行后验证和拒答
SQL 生成后先做静态验证：只允许白名单数据源和只读语句；所有实体必须来自计划；Join 与聚合必须对应中间表示；参数不能拼接；扫描量、超时和结果行数受限。EXPLAIN 用于检查全表扫描、笛卡尔积和意外 Join 顺序。
时间成熟度水位闸把本节的判断压缩成可检查的关系：避免未成熟归因进入决策。人物动作对应执行责任。
执行后再做结果验证。分子分母总量与基准报表对账，维度汇总前后保持守恒，currency 与 timezone 单一，coverage 达到策略要求，结果日期符合成熟规则。若查询返回空，不自动解释为“没有可扩量 campaign”，先区分无数据、无权限、全部被门禁过滤和确实没有候选。
拒答需要结构化。比如：“当前没有 search term × placement 联合粒度，无法计算该问题；可分别查看两类报告。”“最近 2 天归因未成熟，稳定窗口仅 12 天。”“3 个 campaign 下存在无有效 COGS 的 ASIN，不能生成利润扩量建议。”这类回答比一个精确小数更有业务价值。
Text-to-SQL 研究可以用于评测解析能力。Spider关注跨数据库泛化，BIRD引入真实数据库值和效率，DIN-SQL采用分解与自校正。它们不能直接证明生产系统安全，因为 Amazon Ads 还包含权限、归因、版本、动作和错误成本。
从问数到动作：查询正确也不等于可以改预算
问数输出是观察，动作还要经过策略门禁。“找出可加预算 campaign”最多生成候选集合，后续需验证库存、利润、portfolio ceiling、冷却期、当前 API 状态与审批。查询服务不应持有写 Amazon Ads 的权限。
策略权限钥匙板把本节的判断压缩成可检查的关系：让查询与写动作受到不同授权。人物动作对应执行责任。
候选动作携带 query plan ID、data snapshot、metric version、strategy version、结果 coverage 与拒绝项。动作服务重新检查当前 campaign budget 和 state，避免用户审批期间对象已变化。执行采用幂等键，保存请求响应，并在观察窗口结束后对比预期与实际。
这个边界也保护语义模型。若模型直接从自然语言生成 SQL 并调用写 API，团队无法判断事故来自意图解析、数据 Join、指标口径还是执行重试。分层以后，每一步都有独立产物和测试，错误可以归因，改进不会变成整套 prompt 重写。
评测体系：不要只测最终答案像不像
评测集以真实 Amazon Ads 决策问题组织，覆盖 campaign、ad group、target、search term、ASIN、placement、budget、ACOS、TACOS、库存和利润。每个问题标注可回答性、合法指标、时间角色、允许路径、预期拒答和动作边界。
指标分层统计：意图绑定准确率、metric ID 准确率、时间契约准确率、路径合法率、聚合正确率、权限违规数、SQL 执行率、结果对账率、拒答精确率和端到端决策通过率。一个最终数字恰好正确，若使用非法路径，也不能算通过。
故障注入要包含字段同名、比值平均、跨币种、夏令时、迟到转化、库存过期、COGS 缺失、多对多 ASIN/SKU、无权限字段、API schema 变化和恶意提示。验证系统是否在正确层停止，而不是最后统一返回数据库错误。
Reddit 对 headless semantic layer 的讨论提出日期脊柱、NULL 与 Join 语义问题，The Missing Context Layer讨论实体优先与指标优先。两者用于发现实践矛盾，关键能力仍由官方文档、开源实现和本地回归证明。
未来探索：语义编译器会成为 Agent 的控制平面
未来的语义编译器不只服务问数，还会服务预算规划、搜索词收割和库存联动。不同 Agent 共享同一 metric registry、entity graph、policy 与 provenance，避免每个技能重复解释 ACOS 和 campaign 关系。
五门编译流水线把本节的判断压缩成可检查的关系：完整展示语义计划逐门变成 SQL 与动作提案。人物动作对应执行责任。
编译器还可以输出多种后端：SQL 用于数仓，SPARQL 用于图关系，SPARQL 1.1提供属性路径表达；API plan 用于读取 Amazon Ads 当前状态。关键不是统一语言，而是共享中间语义和验证结果。
模型能力提升会减少部分解析错误，却不会消除无联合 grain、归因未成熟和权限不足。未来优化重点应是扩大受治理的意图集合、减少不必要澄清、提高拒答可用性，而不是追求所有问题都执行 SQL。
从三个问题开始，而不是先造通用聊天框
第一批生产问题可以限定为“哪些成熟 campaign 的贡献利润持续低于策略边界”“哪些 search term 满足收割候选条件”“哪些 placement 调整后越过最大可承受 CPC”。三个问题分别覆盖聚合指标、对象迁移和竞价控制，又能使用现有 Amazon Ads 报告、订单、库存与利润数据验证。
每个问题先由投放、财务和数据团队共同写金标准。金标准包括自然语言变体、意图 ID、metric IDs、time role、实体路径、必需筛选、拒答条件、逻辑计划和结果样本。不要只给一条 SQL，因为同一个业务问题在不同仓库方言和物理模型下可以有多种正确实现；真正需要固定的是语义中间表示。
上线时界面同时展示“系统怎样理解问题”和结果。用户能看到当前 profile、marketplace、时间窗口、成熟度、指标版本、过滤条件和数据 coverage，并可修正意图。修正记录进入评测集，但不直接改写 registry。这样既让人参与语义校准，也避免每次反馈即时改变所有查询。
当三个问题的拒答、对账和性能稳定后，再扩展相邻意图。搜索词候选可以延伸到 negative exact 风险评估，placement 调整可以延伸到 budget pacing，利润诊断可以延伸到库存限制。扩展沿已有实体和指标组合前进，比一次开放任意 SQL 更容易证明边界。
缓存、成本和性能也是语义问题
问数 Agent 若每次扫描全部 search term 明细，正确也难以使用。缓存不能只按自然语言字符串做 key，同义问题会重复计算，不同权限又可能误共享结果。更合适的 key 来自规范化语义请求、数据 snapshot、metric version、policy version 与 access context。
预聚合同样受指标契约限制。campaign 日级 spend 和 attributed sales 可以预聚合，ACOS 在查询时由分子分母重算；inventory snapshot 保留最后有效状态，不能像 spend 一样求和；跨币种结果在汇率策略固定后才能缓存。Cube 的架构把预聚合与语义模型放在同一运行时，关键启发是性能优化必须保持语义等价。
逻辑计划在执行前估算扫描量和基数。用户问一年 search term 明细时，系统可以先提供 campaign/ASIN 汇总并提示缩小范围；若任务确实需要全量，转入异步作业，不让聊天请求无限等待。成本策略是产品能力的一部分：什么时候给快速近似，什么时候等待精确结果，必须明确标识。
一份失败目录比更多提示词更有价值
每次错误都应归入失败目录：意图歧义、术语未绑定、时间冲突、指标不兼容、无合法路径、权限不足、数据不成熟、覆盖不足、执行超限、结果对账失败。目录记录触发问题、错误中间表示、期望行为、修复版本和回归样本。
如果错误来自本体缺少 ProductTarget 与 ASIN 的关系，应修本体和路径测试；如果来自 TACOS 分母错误，应修指标合同；如果来自模型把“扩大”理解成 budget 而非 bid，应修意图样本。把所有失败都归入 prompt，会让规则不可测试，也让历史补丁互相冲突。
拒答也进入失败目录，但不都算失败。系统因无联合 grain、无权限或未成熟数据拒绝，是正确控制；只有本可回答却错误拒绝，才是可用性缺陷。评测必须区分安全拒答与能力不足，否则团队会为了提高回答率逐步拆掉门禁。
从 SQL 回到业务决策的最后一公里
查询返回 12 个可扩量 campaign，不等于应生成 12 个相同预算动作。每个 campaign 下的 ASIN 数、利润 coverage、库存风险、当前预算利用、placement mix 与策略角色不同。结果需要进入 Decision Builder，按对象生成证据包和建议区间。
投放负责人看到的不是 SQL，而是：该 campaign 为什么入选，哪些指标已成熟，哪些 ASIN 限制上限，建议预算变化会如何影响 portfolio ceiling，多久复查，什么条件自动回滚。SQL 和逻辑计划作为可展开证据保留，业务解释来自同一结构化语义，而不是另一次自由生成。
执行后，新观察回到评测集。若查询正确但策略效果差，调整 strategy；若实体 coverage 不足，修映射；若执行时 campaign 已变更，修并发控制。只有把错误归到正确层，语义编译器才能随业务演进而不变成新的黑箱。
产品验收可以采用逐层可见的调试视图。投放人员看到业务意图和指标口径，数据团队看到实体路径与聚合计划，平台团队看到权限、SQL、扫描成本和执行 trace。不是每个人都看全部细节，而是同一个 query ID 能贯穿各层。发生争议时，团队讨论的是哪一层解释错误，不是互相截图不同报表。
语义 registry 也要有发布纪律。新增指标先声明 owner、业务目的、分子分母、时间角色、允许维度、数据 coverage 和弃用计划；新增关系先验证基数、有效期和 fanout；自然语言同义词由领域 owner 审核，防止“销量”“销售额”“归因销售”被模型绑定到同一个字段。registry 变更后，所有金标准问题重跑。
问数质量还受源数据可观测性影响。抽取缺日、report request 失败、profile 时区变化和 API 字段漂移都可能让编译链在正确语义上执行错误数据。因此，结果验证不仅检查 SQL，还引用上游 freshness、completeness 与 schema 状态。上游不健康时，系统返回证据状态，不把管道故障解释成 campaign 表现变化。
这套体系会牺牲一部分即兴查询自由，但换来可解释的扩展路径。真正需要任意探索的分析师仍可进入受控 SQL 环境；需要据此调整 Amazon Ads 的业务用户，优先使用经过验证的意图。探索与决策可以共享数据，不必共享同一风险级别。
每个季度应淘汰没有消费者、没有 owner 或长期无法通过对账的意图。语义编译器的成熟度不由支持问题数量决定，而由高价值问题的正确率、拒答质量和动作事故率决定。少量可靠能力比一张能回答任何问题却无法承担后果的聊天界面更有价值。
总结概要：可靠问数依赖可检查编译链
自然语言只是输入界面，不是业务语义。Schema 只描述数据形状，不描述指标、时间、路径和权限。Amazon Ads 问数要经过五道门：绑定业务意图和时间契约，选择合法实体路径，生成正确聚合计划，应用权限，执行后验证并在证据不足时拒答。
可解释计划回执单把本节的判断压缩成可检查的关系：向人展示采用的定义、路径和拒绝原因。人物动作对应执行责任。
落地可以从高价值问题开始：成熟 campaign 利润复盘、search term 收割候选、placement 调整评估、预算耗尽诊断。为每类问题建立金标准中间表示，再接 SQL 生成。查询结果进入动作前，必须再过库存、利润、审批和当前状态门禁。自然语言让入口更轻，语义编译器负责让后果保持可控。