Amazon Ads 团队引入本体和图推理，通常不是因为查不到数据。真正的障碍是：报表可以证明某个搜索词带来过订单，却不能独立回答它应迁入哪个广告组；可以显示某个 placement 的回报较好，却不能证明 campaign 内每个 ASIN 都承受得起进一步加价；可以找出高花费低销售的查询，却不能说明把它否定之后会切断哪些探索路径。
这些问题都不是一行事实的问题。它们跨越了顾客查询、target、ad group、campaign、广告商品、成交商品、库存、利润、广告位、时间窗口和权限。一次策略动作还会改变后续流量分配，使动作前后的数据不再来自同一个环境。传统数仓能够保存这些事实，语义层能够统一指标口径，规则表能够执行局部判断；但当决策依赖对象之间的多跳关系、非局部影响和状态传播时，团队需要一种更明确的表达方式。
本体与图推理的价值正在这里。它不是给报表加一层关系可视化，也不是把 SQL 改写成 Cypher 或 SPARQL。它要交付的是一份可以检查的决策证明：结论适用于哪个账户和 marketplace，使用了哪个时间窗口，依赖哪些对象关系，哪些事实支持它，哪些约束反对它，动作可能影响谁，证据何时失效。
图存储关系，本体规定关系意味着什么，推理计算结论在什么条件下成立；三者只有接到可审计的策略提案，而不是直接接到广告写接口，才构成可用的投放决策系统。
先给结论：什么情况下才值得引入图推理
并不是所有投放优化都需要图。计算 campaign 日花费、按周汇总 ACOS、检查预算是否耗尽，用事实表和语义指标完成得更直接。即使是按单个 target 的成熟点击数触发提醒，只要规则不需要穿过其他对象，也没有必要为了“智能”改造成知识图谱。
图推理适合三类问题。第一类是影响范围：一个动作会沿关系影响多少对象，例如 campaign 级 placement adjustment 会改变其中所有可参与竞价的 targets。第二类是冲突与可达：搜索词迁入新的精准结构后，会不会与已有 broad、phrase、exact target 或 negative target 形成不希望的流量路由。第三类是跨域资格：即使广告表现达到阈值，商品库存、Featured Offer、价格、毛利或合规状态是否仍允许放量。
图 1：决策复杂度不是随着数据量线性增长，而是在跨越对象、时间与治理边界后出现断层。
可以用一个简单门槛判断：如果一个策略的输入和输出都能稳定落在同一粒度的一张事实表上，优先使用 SQL、指标合同和普通规则；如果判断必须穿过两个以上业务域，需要计算动作传播半径，并且需要向审批人解释完整路径，再考虑图推理。这个门槛很重要，因为本体、实体解析、图存储、规则治理和回放测试都有真实成本。
需要特别防止一种倒置：先买图数据库，再寻找“适合上图”的业务。数据库擅长保存和遍历关系，不会自动产生正确的对象身份、业务约束和因果解释。没有投放问题定义的图，节点再多也只是另一种数据集市。
平面报表为什么接不住跨对象决策
Amazon 对 Sponsored Products targeting 的说明清楚地区分了 customer shopping query 与 keyword：前者是顾客用于寻找商品的词语，后者是广告主在手动 campaign 中参与匹配和竞价的配置。二者文本可能相同，业务身份却不同。搜索词报告是观察结果，keyword 是未来流量资格的一部分。
把带来订单的 search term 复制成 exact keyword，至少改变了四件事。它获得了独立 bid，进入新的 campaign 或 ad group 预算边界，可能与原有 target 竞争，也可能需要在探索结构里增加 negative exact 才能形成路由。如果只把两边按字符串连接，系统看不到它们各自的 profile、marketplace、ad product、有效时间和商品集合，最危险的情况不是查不到，而是连上了不该连的对象。
图 2：文本相同不代表业务身份相同，四种身份必须通过显式关系衔接。
placement 判断也有相同问题。报告能显示 Top of Search、Rest of Search 或 Product Pages 的阶段性表现，但 placement adjustment 通常在 campaign 边界发挥作用。某个位置的历史 ROAS 较高，不等于 campaign 内任意 target 都应得到同样放大；历史数据还受到基础 bid、动态竞价策略、预算时段和入选流量的共同选择。把 placement 行和 target 行按 campaign、date 连接，很容易制造看似精确、实际上发生 fanout 的指标。
因此，平面报表的局限不是“没有关系”，而是没有把关系的业务含义和动作方向写进合同。外键只说明两行可以连接，不说明连接结果可以支持何种决策。语义层可以阻止错误聚合，却仍需要另一个层次表达“若修改 A，哪些 B 会受影响”“若 X 缺失，动作是拒绝、等待还是降级”。
先定义决策图，而不是建设知识大全
适合 Amazon Ads 的图不应从“把所有数据都变成节点”开始，而应从决策最小闭包开始：要证明一个动作成立，必须看到哪些对象、状态、规则和证据。只有进入证明链的内容才进入决策图，其余明细继续留在成本更合适的仓库和指标引擎中。
决策图可分成五个域。投放配置域包含 profile、campaign、ad group、target、ad、portfolio 和 placement policy；流量观察域包含 search term observation、impression、click、conversion 和 attribution window；商品零售域包含 advertised ASIN、purchased ASIN、库存、Featured Offer、价格和内容状态；经营约束域包含毛利底线、目标、预算上限、风险级别和权限租约；决策记录域包含 proposal、evidence snapshot、approval、execution receipt 与 outcome review。
五个域之间的边不能只写一个 RELATED_TO。事实边描述来源可以直接证明的关系，例如 target 属于 ad group；策略边描述业务规则，例如某个 retail state 限制某类 bid increase；证据边描述一个 proposal 使用了哪个报告版本、规则版本和对象快照；执行边描述动作请求、远端回执和回查结果。若把这些边混成一种，图遍历会把“观察到相关”误读成“策略上允许”。
图 3：这是一张为决策闭包服务的图，不是一张试图收纳所有企业数据的知识大全。
决策图还有一个刻意的限制：它不是企业知识的唯一真相源。销售和点击事实的权威仍是版本化报告，库存事实有自己的系统记录，策略提案也只是某个时点的判断。图保存的是可追踪引用、受治理关系和需要参与推理的状态，而不是复制所有系统成为另一个无法对账的大平台。
本体究竟应该定义什么
本体首先定义对象身份。一个 campaign ID 脱离 profile 和 marketplace 没有足够业务含义；一个 ASIN 脱离 marketplace 也不应被默认当成全球同一商品。target 还必须携带 ad product、target type、match type、state 和有效期。身份键若没有这些作用域，跨账户或跨站点误合并会沿图传播，最终产生看似完整的错误证明。
其次定义关系的方向、适用域和基数。Campaign contains AdGroup 与 AdGroup belongsTo Campaign 可以互为反向关系，但 SearchTerm observedUnder Target 不能反向解释为 target 由该搜索词定义。AdvertisedASIN ledTo PurchasedASIN 是带归因窗口的观察，不是永久产品关系。把时间化观察写成静态边，会使一个节日促销期间的偶然关联长期影响投放。
第三定义状态和生命周期。Campaign 的 enabled、paused、archived 不是三个互不相关的字符串；Proposal 的 drafted、validated、approved、submitted、confirmed、expired、rejected 也应有合法迁移。状态机能够阻止过期批准继续生效，并让“Amazon 远端结果未知”成为独立状态，而不是简单归类为失败后重试。
第四定义动作不变量。创建 exact keyword 之前，目标 ad group 必须存在且商品集合适用；增加 negative exact 之前，系统必须计算受影响路径；提高 placement adjustment 之前，必须确认 campaign 级影响和最大可承受点击成本；所有写操作都必须限定 profile、marketplace、对象 ID、期望基线和幂等身份。
图 4：本体的边界止于可共享的业务含义与约束，不替代指标计算、概率预测或执行编排。
第五定义概念治理。名称、定义、负责人、版本、废弃策略、可复用模式和能力问题需要进入本体资产。Ontology Development 101强调从领域范围、重要术语和能力问题出发迭代建模；OBO Foundry 的治理原则虽然来自生命科学，也提供了范围、定义、关系、版本、维护和术语稳定性的通用启发。不能照搬领域本体，但可以复用治理纪律。
稳定知识与易变事实必须采用两种速度
OWL 讨论中常用 TBox 与 ABox 区分术语、公理与实例断言。落到广告系统，可以把稳定的业务类型、关系、约束和规则视为模式知识，把具体账户里的 campaign、target、ASIN 和观察视为实例事实。这个区分的意义不是背术语，而是避免用同一种发布机制处理两类变化。
本体版本变更通常需要评审、兼容性检查和回归测试。例如把 ExactKeywordTarget 重新定义为允许某种产品投放表达式，会影响大量既有查询和规则。实例事实却每小时甚至更快变化，点击、预算、库存和 Featured Offer 都可能刷新。若每次实例更新都触发完整本体发布，系统无法运营；若模式变更像普通数据刷新一样静默发生，历史证明无法重放。
生产上至少要保存四个版本：ontology version、rule version、fact snapshot 和 model version。一个 proposal 指向这四者，才能解释同一 search term 为什么昨天被判定为观察不足，今天成为迁移候选。报告回填后可以生成新的评估，但不能修改昨天的决策快照，让历史看起来像当时已经知道后来才到达的订单。
图 5：低频语义发布与高频事实更新在 Proposal 快照处会合，历史判断因此可以重放。
高频数值也不必成为海量 RDF 断言。广告日事实、小时流和 AMC 结果适合留在列式数据或专用计算引擎，本体对象保存指标引用、窗口、粒度和版本。推理需要某个数值时，通过受控函数读取固定快照。这样既保留形式关系，也避免为了图而牺牲成本和性能。
六类推理必须分账
“图推理”经常把性质不同的能力混在一起。对于投放系统，至少要把六类责任分账，因为它们的证据强度、失败方式和可执行权限不同。
第一类是归一与分类。系统可以依据明确映射把某种 targeting expression 分类为 keyword target 或 product target，也可以通过人工确认的主数据把广告 ASIN 与内部 SKU 对齐。实体解析模型给出的高相似度只能产生合并候选，不能直接声明两个对象相同。错误的身份合并会污染其后所有路径。
第二类是可达与影响分析。它回答一个动作沿确定关系能触达谁，例如 negative exact 在特定作用域可能阻断哪些 search term routes，campaign budget 修改会覆盖哪些 ad groups。这类计算可以用属性图遍历、SPARQL property path 或关系递归完成；“能走到”只说明结构影响，不说明动作值得做。
第三类是规则蕴含和资格判断。若候选满足成熟证据、利润、库存、冲突和权限条件，规则可推导 EligibleMigrationProposal。这里的结论依赖清晰前提，任何前提变化都会使资格失效。OWL 2 Profiles提供了表达力与可计算性的不同取舍，其中 OWL 2 RL 面向规则式实现，但实际业务规则仍要评估是否适合 OWL、公理规则、Datalog 或普通策略引擎。
第四类是约束验证。SHACL 检查的是一个数据图是否满足形状，例如 Proposal 是否带 profile、marketplace、对象基线、时间窗口和来源；它与 OWL 的开放世界语义不是同一个问题。W3C SHACL定义了 shapes 与 validation report。验证通过意味着结构满足声明约束，不意味着策略一定赚钱。
图 6：六类能力共用同一对象图，但必须分别声明输入、输出和证据强度。
第五类是时间和来源推理。它判断状态在何时有效、来源如何派生、决策当时可见什么。OWL-Time提供时间实体和关系的标准词汇，PROV-O提供 entity、activity、agent 与 derivation 表达。真正落地还需要业务有效时间和系统记录时间，不能只给边加一个 created_at。
第六类是概率与排序。向量模型、GNN 或 LLM 可以发现语义近似查询、估计转化倾向、总结证据和排序候选。神经符号知识图谱推理综述展示了符号与表示学习的组合方向，但概率分数不是逻辑真值。模型可以说“这两个查询可能表达同一购买意图”，决定它们能否合并投放仍需对象作用域、商品适配和策略门禁。
关系可达、逻辑蕴含、约束通过和概率较高是四种不同结论。系统只有把结论类型写进数据合同，才不会让 Agent 用一个相似度分数越过业务权限。
策略一：搜索词迁移需要一条证明链
Amazon 的搜索词报告说明指出，报告展示产生过至少一次点击的顾客搜索词，并可用于识别表现较好的查询或创建 negative target。这个入口提供观察，却没有替广告主完成迁移决策。成熟度、目标结构、商品适配和流量治理仍是账户自己的问题。
一条可审计的迁移链从 Observation 开始。系统先固定 profile、marketplace、ad product、source campaign、source target、advertised ASIN、search term、date range 和 attribution snapshot。它再计算点击、花费、订单、销售和利润相关指标，但指标不直接触发动作，只形成支持或反对证据。
第二步是身份与意图检查。搜索词是否只是文本相同，还是词序、语言、品牌、规格和使用场景也适合目标商品；成交是否来自被广告商品，还是经由 cross-sell 落到另一个 purchased ASIN；目标 ad group 中多个商品是否共享同一购买意图。LLM 可以辅助解释，但输出必须保留候选和不确定性。
第三步是目标结构搜索。图沿 belongsTo、containsProduct、targetsExpression 和 governedByObjective 找到可接受的 ad groups，再排除 marketplace、品牌、产品线或目标不一致的结构。若没有合适目标，正确结果可能是“建议新建结构”，而不是把词塞进距离最近的 campaign。
第四步是冲突和路由模拟。系统查找完全相同、词形相关或范围重叠的 existing targets，检查 campaign/ad group 级 negatives，计算迁移后搜索词可能进入哪些路径。若计划在探索结构增加 negative exact，还要确认这条否定不会覆盖其他变体，不会使探索 campaign 失去应保留的发现职责。
图 7：迁移不是把一行报告复制为一条配置，而是让支持证据、反证与动作边界共同收敛。
第五步是经营与动作门禁。库存不足、Featured Offer 不稳、毛利低于阈值或预算已处于风险状态时，即使历史 ACOS 好，也只能生成等待或小额试验候选。Proposal 需要记录目标 match type、初始 bid 边界、计划否定、证据窗口、冲突集合、失效时间和回查计划。
这一串判断说明，图推理真正减少的不是写 SQL 的数量，而是跨对象决策中隐含的假设。投手仍可以不同意建议，但系统必须把分歧定位到具体关系或规则，而不是给出一段无法复算的“综合判断”。
策略二：否定投放是流量路由，不是黑名单
Negative targeting 看起来像删除无效流量，实际是在改变未来查询到广告结构的可达路径。否定词或否定商品的作用范围、匹配方式和层级不同；同一文本在品牌防守、竞品拓展、新品探索和收割 campaign 中也可能承担完全不同的任务。
把高花费低销售查询直接放入全局否定列表，等于把局部观察升级成全域结论。系统至少要回答：样本是否成熟；归因是否仍在回填；该查询是否属于探索预算；它是否在其他商品或 marketplace 上有效；否定范围会覆盖多少变体；是否存在一个更窄的否定表达；若流量被阻断，是否有另一条结构负责承接。
决策图可以把流量路由表示为 SearchTermPattern -> MatchingRule -> Target -> AdGroup -> ProductSet。加入 negative 后，先在影子图上移除或标记相应路径，再比较被阻断节点集合。这里需要的是影响分析而不是因果预测：图能证明某条配置路径会被规则遮挡，不能保证遮挡之后预算一定流向更高收益的查询。
图 8：否定策略要先看阻断半径，再讨论节省了多少无效点击。
冲突可以分为五类。自我阻断是新增 target 同时被上层 negative 覆盖；兄弟竞争是多个 ad groups 对同一查询保留资格却目标不同；探索断路是收割结构增加后把探索入口完全封死；品牌缺口是否定泛词时连带丢失品牌防守；跨域误用是把一个 marketplace 或商品线的否定结论复制到另一个作用域。
NegativeProposal 因而需要包含 blocker、blocked routes、scope、match semantics、evidence maturity、expected purpose、owner 和 rollback。执行后不能只确认 API 返回成功，还应在下一数据周期验证路径是否按预期变化，并观察是否出现异常流量缺口。否定可撤销，不代表撤销没有学习成本和机会成本。
策略三：竞价和预算必须穿过零售就绪约束
竞价系统最常见的模型是把历史转化率、平均订单价值和目标广告成本组合成最大可承受 CPC。这个计算有用，但它只描述财务上界。现实中一个 ASIN 可能库存不足、失去 Featured Offer、价格异常、详情页受限或毛利刚刚变化；继续买流量会把广告效率问题扩大成经营损失。
零售就绪不应是一个永久布尔字段，而应是带来源、有效时间和原因的状态集合。InventoryRisk、FeaturedOfferUnstable、MarginBelowFloor、DetailPageSuppressed 的严重程度和恢复条件不同。规则可以推导 AccelerationBlocked 或 BidIncreaseCapped，但需要保留触发它的具体状态，不把“不可放量”压成一个无解释标签。
placement adjustment 的传播半径尤其需要图表示。一个 campaign 连接多个 ad groups，每个 ad group 又连接一个或多个 ASIN。Top of Search 历史表现较好，可能主要由其中少数 exact targets 和一个高转化 ASIN贡献；campaign 级加价会同时放大其他对象。系统要沿图枚举暴露集合，再用每个商品的零售约束和最大 CPC 检查最坏情况。
图 9：竞价信号从上向下放大流量，库存、利润和 Featured Offer 风险则从商品向上收紧动作边界。
预算也不是孤立的日限额。调整 campaign budget 会改变其内部对象获得流量的机会，还可能影响 portfolio 或账户级资源分配。若归因延迟尚未成熟，短期花费增长先出现、订单后到达。决策图应把 budget proposal 连接到证据成熟度、pacing 状态、库存覆盖天数和其他候选 campaign，使审批人看到机会成本。
这类推理的输出通常不是“加价 20%”。更稳妥的是产生一个受约束动作：基础 bid 或 placement multiplier 的允许区间、最大增量、适用对象、试验时间、累计花费上限、暂停条件和回滚基线。图帮助计算范围，策略服务计算数值，Harness 管理执行；不能把全部责任塞进一条本体规则。
开放世界与运营闭世界怎样共存
OWL 2 Overview所代表的形式语义建立在开放世界思路上：没有声明某个事实，并不等于这个事实为假。这对于跨来源知识整合很重要，却与生产动作需要确定输入的要求产生张力。库存状态缺失，不能推导库存充足；也不能因为没有 FeaturedOfferLost 断言，就认定商品稳定拥有 Featured Offer。
解决方法是在动作边界引入局部完整性合同，而不是把整个知识层改造成闭世界。对某种 action，合同声明哪些来源必须存在、刷新时间不得早于何时、哪些字段允许 unknown、unknown 对应等待还是拒绝。这个完整性合同可以用 SHACL、数据质量规则和普通代码共同实现。
例如 IncreasePlacementBid 要求 campaign 当前配置快照、最近库存、利润底线、目标商品集合和成熟 placement observation 齐备。只要一个强制事实缺失，系统就不生成可执行 proposal；它可以生成 NeedsEvidence 任务，引导运营人员补充数据。这样既没有把未知误判成 false，也满足了动作的确定性要求。
图 10：知识平面允许未知，执行平面必须把未知转化为补证、降级或拒绝。
本体推理和约束验证的先后也要明确。某些形状依赖推导后的类型或属性，执行顺序会影响验证结果。团队必须把 entailment regime、规则版本和验证顺序写进构建与测试，不接受“同一数据在不同环境偶尔通过”。
从对象清单到决策本体：一份可以落地的模型
本体设计最容易在对象清单阶段失控。团队把 Campaign、AdGroup、Keyword、Product、Customer、Order 依次画出来，关系补得越来越多，却没有说明哪个业务问题因此变得可回答。更可行的做法是先写能力问题，再只为能力问题补足对象和关系。例如“为什么这个搜索词可以迁移到目标广告组”需要观察、来源 target、目标商品集合、已有 targets、否定规则、证据窗口和经营约束；模型能够回答这个问题，才算完成一个切片。
Profile 是第一层边界对象。它连接 advertiser identity、region、marketplace、currency、timezone 和授权主体。Campaign、AdGroup、Target 等外部 ID 都在 Profile 作用域内解释。很多数据工程实现直接以 campaignId 作为全局键，在单账号阶段看不出问题，扩展多站点或多代理账户后才出现碰撞。本体不应修补一个坏主键，而应把作用域本身建模成身份的一部分。
Campaign 不是装所有指标的容器，而是投放配置与控制范围。它拥有 ad product、targeting strategy、bidding strategy、budget policy、state 与有效时间，并包含 AdGroup。Placement adjustment 和部分预算动作在这个边界传播。Campaign 与 Objective 的关系也应显式存在，因为同一 ACOS 在新品发现、品牌防守和利润收割下没有同一解释。
AdGroup 表达一组商品和 targets 共享的投放上下文。若一个 ad group 中商品购买意图差异很大，任何 search term 的迁移和 bid 都难以解释。图推理可以识别商品集合，却不能替代错误结构的治理。模型应允许产生 StructureSmell 或 TargetDestinationUnavailable，而不是在所有情况下都返回一个目标 ad group。
Target 是可竞价的配置对象，至少区分 keyword、product 和自动 targeting expression。KeywordTarget 的 text、match type 与 normalized form 是属性，SearchTermObservation 的 query text 即使相同也不是同一实例。二者通过 supportsCandidateFor 或 observedUnder 之类的有方向关系连接。这样，系统可以表达“一个观察支持创建一个配置”，而不是用 sameAs 抹去二者的生命周期差异。
ASIN 模型必须分 advertised 与 purchased 角色。广告点击发生在 advertised ASIN 上，归因销售可能包含 purchased ASIN；两者关系受广告产品、报告定义和归因窗口约束。把 purchased ASIN 的销售完全归给 advertised ASIN 的商品适配，可能误判 cross-sell。内部 SKU、变体、品牌和类目关系可以补充，但所有映射都需要来源与有效期。
Observation 是本体落地成败的关键中间层。它不是 Target 上不断覆盖的最新 clicks、spend 和 sales，而是引用某个事实快照、粒度和窗口的对象。SearchTermObservation、PlacementObservation 和 RetailObservation 分别声明观察对象、时间、数据版本、口径和成熟状态。由此产生的 HighEfficiency 也只能在明确目标和窗口内成立。
Proposal 是决策本体的中心。它把推荐从一句文本提升为受治理对象，包含 action type、target objects、before state、after state、evidence references、supporting claims、blocking claims、risk tier、owner、expiresAt、approval 和 execution plan。即使最终不执行，Proposal 也保存为什么拒绝，成为后续规则和 Agent 评测的样本。
最后是 Decision 与 Outcome。Decision 记录人或 Agent 对 Proposal 的处理，不等于 Action 已成功；ExecutionAttempt 记录每次远端提交；Receipt 记录回执和回读；OutcomeReview 在数据成熟后评价后果。把这几个对象拆开，系统才能区分“建议正确但被拒绝”“批准正确但执行失败”“执行成功但业务假设不成立”。
这套模型不追求形式上的绝对完备。它只要求每个对象有负责人、身份、时间和来源，每条关系说明允许的决策用途，每个推导结论知道自己属于逻辑、约束、路径还是概率。模型一旦无法回答能力问题，就补充最小概念；一旦概念不再参与任何决策，就评估是否从运营本体移出。
规则应该描述策略边界，而不是复制投手经验
把投手经验改写为 if ACOS < 20% then bid +20%，并没有形成高质量本体规则。它遗漏了目标、利润、样本、归因、库存、广告位和作用域，也把账户经验伪装成普遍规律。规则的第一项元数据应是适用范围，至少包含 marketplace、ad product、strategy purpose、object type 和 effective time。
第二项是证据要求。规则不直接读取“最新指标”，而读取已声明粒度、口径和成熟度的 Observation。规则可以要求最低信息量，却不应把通用点击数写成跨账户阈值。样本是否足够应结合转化基线、决策损失和归因延迟，由账户策略定义并记录来源。
第三项是结论类型。EligibleForReview 只代表进入人工队列，EligibleForExecution 表示所有确定性门禁已通过，BlockedByRetailState 表示存在明确阻断，NeedsEvidence 表示事实不完整。结论类型决定它能进入哪个后续工具，避免“推荐”在应用里被误当成“可执行”。
第四项是反例。每条规则至少保存一组正例、边界例和反例。搜索词有订单但成交商品与广告商品意图不一致，是迁移规则的反例；Top of Search 回报高但库存覆盖不足，是 placement 加速的反例；低销售查询属于明确的新品探索预算，是否定规则的反例。没有反例的规则往往只是口号。
第五项是冲突处理。两条规则可能分别推出 IncreaseBid 与 BlockAcceleration。系统不应依靠执行顺序决定谁覆盖谁，而应声明风险规则优先、范围更窄者优先、人工批准优先或返回冲突。对预算和写操作，无法确定优先级时宁可停止，也不把冲突压成一个平均分。
第六项是失效机制。事实刷新、对象状态改变、本体升级、规则更新或批准过期都会使结论失效。Proposal 不能只保存创建时间，还要保存它依赖的 snapshot IDs 和 invalidation conditions。当库存由稳定转为风险时，相关加速建议应主动过期，而不是等运营人员再次打开页面。
规则治理也应像代码治理：提案、评审、测试、影子运行、分批发布、观测和回滚。业务负责人评审策略含义，数据负责人评审事实与口径，平台负责人评审性能和执行边界。任何人都不应在生产图中直接修改一条全局规则，然后依赖第二天报表判断是否出事。
一份搜索词迁移提案应该长什么样
可以把一次迁移提案拆成六部分。第一部分是身份：proposal ID、profile、marketplace、source target、source ad group、candidate query 与 target ad group。第二部分是观察：报告窗口、attribution snapshot、clicks、spend、orders、sales、advertised/purchased ASIN 关系和数据成熟度。所有指标都保留引用，不复制成脱离口径的数字。
第三部分是支持结论。可能包括“查询意图与目标商品集合一致”“在指定窗口内贡献满足账户的收割标准”“目标结构与策略目的匹配”“目标广告组没有同等 exact target”。每个结论标注由规则、图路径、模型还是人工产生，并能回到输入。
第四部分是反对结论。系统列出可能的 broad/phrase overlap、上层 negative、库存风险、利润不足、预算拥挤、归因未成熟和模型不确定性。反对结论不应被一个总分隐藏。审批人需要知道哪些是硬阻断，哪些只影响排序或初始 bid。
第五部分是动作计划。计划可以是“在目标 ad group 创建 exact keyword，初始 bid 不高于给定上界；保留原探索 target 的 bid；观察一个成熟窗口后再决定是否增加 negative exact”。这比“迁移并否定”更符合证据逐步成熟的过程。
第六部分是恢复与验证。Proposal 声明幂等身份、预期基线、远端确认查询、部分成功处理、撤销方式和 outcome review 时间。若创建 target 成功但 negative 失败，系统应保留新 target，暂停第二步并重新评估竞争，而不是删除后盲目重试整个动作。
面对多义查询，模型可以生成意图说明，例如区分品牌、规格、材质和使用场景；但说明必须绑定原始 query 与产品属性证据。模型不确定时，Proposal 进入人工分类队列。把“不确定”保留下来，比用流畅解释强行补全更专业。
一份这样的提案看起来比一行推荐重，却把原本散落在人脑、表格和聊天记录里的判断收拢到同一对象。随着规则和工具成熟，系统可以自动填充大部分字段；但它不应省略字段来追求表面自动化率。缺少关键证据时返回 NeedsEvidence，本身就是正确的系统行为。
否定路由需要先计算最坏影响
否定策略的常见误区是只评估被否定查询本身。系统看到一段时间内花费高、无订单，就把该 query 或词根加入 negative。真正的风险在作用域：negative exact、phrase 或 product target 可能在 ad group 或 campaign 层阻断一组未来匹配，而这些匹配并不等同于历史报告中的那一行。
决策图首先建立候选匹配关系。它不是预测 Amazon 内部全部匹配逻辑，而是根据广告主可见的 target、match type、negative scope 和历史 observations，构建可验证的近似路由。对无法由公开接口确定的匹配，边标记为 uncertain，系统不会把模拟结果包装成平台真相。
然后计算三种集合：明确被阻断的 routes、可能受影响的 routes、仍有其他结构承接的 routes。明确集合支持硬性检查，可能集合要求人工审查或小范围实验，替代集合帮助判断流量是否只是迁移还是完全消失。没有替代路径的品牌防守或探索查询，风险级别更高。
最坏影响不是预测最差销售，而是把所有确定结构风险列全。例如 campaign 级 negative 会同时影响三个 ad groups，其中一个承担新品探索；目标 exact 已创建但状态尚未生效；另一个 ad group 有相同 exact，却指向不同商品集合；原 broad target 仍在更高 bid 下竞争。任何一项都可能使“收割”变成内部竞价或断流。
系统还要检查可逆性。移除 negative 可以恢复资格，但被阻断期间的展示机会无法补回，学习窗口也被切断。高风险否定可以先降 bid、缩小作用域或设置人工复核时间，而不是立即做全局永久判断。Proposal 应记录为何选择某种范围，便于后续验证。
OutcomeReview 不只看被否定查询花费是否下降。还要观察目标收割结构是否获得预期流量、探索结构是否仍能发现新查询、相关词的总销售和利润是否变化、是否出现异常流量空洞。若只看“浪费减少”，系统会天然偏向不断扩大否定。
竞价传播必须从 campaign 边界反推
基础 bid 通常属于 target，placement adjustment 作用于 campaign，动态竞价策略又会在拍卖时调整。一个最终竞价机会由多层控制共同决定。若图只连接 Target hasBid，就无法解释 campaign 级倍率如何同时影响多个 targets，也无法计算最坏的有效竞价暴露。
建模时可以把 BidPolicy、PlacementPolicy 与 DynamicBiddingPolicy 分开，Campaign 连接后两者，Target 连接基础 bid。EffectiveBidEnvelope 由策略函数在指定配置快照下计算，输出区间而不是伪精确单值。Amazon 实际拍卖结果仍由平台决定，内部模型只用于风险边界。
对 placement proposal，影响分析从 Campaign 展开到所有 enabled AdGroups、Targets 和 AdvertisedASINs。每个对象连接自己的 performance observation、retail state、margin policy 和 risk tier。若任一高花费 target 在最大竞价情形下超过损失上界，系统可以限制 campaign 级 adjustment，或建议先拆分结构以获得更细控制。
这揭示了本体对结构治理的另一项价值：当一个 campaign 聚合了目标、商品和风险差异很大的对象，系统经常返回“无法安全执行统一动作”。这不是推理失败，而是广告结构没有提供足够控制粒度。正确建议可能是重构 campaign，而不是计算更复杂的平均数。
预算传播同样从 Campaign 展开，但还要向上连接 Portfolio、AccountBudgetPolicy 和资金约束，向下连接 pacing 与 targets。一个 campaign 获得更多预算，意味着其他候选可能失去机会；即使没有共享 portfolio budget，账户也存在经营资源约束。图可以展示候选之间的互斥或依赖，策略优化器再求解分配。
广告位和预算决策最后都要回到可承受损失。历史回报是证据，库存与利润是约束，campaign 结构决定传播半径，目标和实验计划决定观察方式。任何单一关系都不能推出“应该加价”，但这些关系合起来能说明一个动作为什么可被审查。
概率模型与因果判断不能借图混为一谈
知识图谱经常与 embedding、GNN 或 GraphRAG 一起出现，容易让系统把“图上的相关”描述成“业务因果”。Amazon Ads 报表是平台归因结果，能够按其定义连接广告触点与转化，却不自动证明广告带来了增量销售。图推理能沿归因关系查询，也不能越过实验设计得到因果结论。
概率模型适合三个位置。第一是候选发现：识别语义相近查询、相似商品或异常流量模式。第二是排序：在已通过确定性门禁的 proposals 中估计优先级。第三是预测：为 scenario 提供销售、成本或库存风险区间。三个位置都必须保存模型版本、特征窗口和不确定性。
模型不适合替代对象身份、权限、硬性经营约束和远端状态。两个 product title 高度相似，不代表是同一 ASIN；模型预计 ROAS 上升，不代表可绕过预算上限；LLM 认为 API 调用成功，不代表远端已经确认。确定性事实与概率判断要使用不同类型、不同颜色和不同审批规则。
因果问题需要更高证据。若团队要判断 placement 加价是否真正提高增量利润，需要随机或准实验、清晰干预、对照和成熟结果。决策图可以保存 ExperimentPlan、Treatment、Control、Assignment、Outcome 和假设，帮助治理实验；它不能凭连接结构创造反事实。
因此，所谓“神经符号”在投放系统中最务实的解释，是让模型负责发现和估计，让本体与规则负责身份、约束和可解释资格，让实验负责增量因果，让 Harness 负责动作。四者各自承担失败，不把一个综合模型分数当成全部真相。
数据存储、查询与推理如何分工
原始和明细事实继续存放在湖仓或专用数据平台。它们需要批量扫描、聚合、分区和低成本保留，列式格式更合适。语义层在这里提供稳定指标、聚合规则和访问接口。图不应成为替代这些能力的默认存储。
关系图保存高价值对象、长期身份、受治理关系、状态和决策引用。若使用 RDF，可以借助标准语义、命名图和现成本体；若使用属性图，可以更直接地服务工程团队的遍历和图算法。选择之前，应先写出查询：多跳深度、更新频率、预计节点边规模、需要何种 entailment、是否跨组织交换。
规则引擎处理明确策略与资格。部分规则适合 OWL RL 或 Datalog，部分涉及数值、窗口和外部函数，更适合普通代码或决策表。不要强行把所有逻辑写进同一语言。关键是统一输入输出：规则读取版本化 facts，输出 typed claims，并附 rule ID 和证据。
搜索和向量存储服务非结构化资料与语义候选，例如解释商品标题、广告文案和查询意图。它们返回文档片段、相似度或分类候选，随后由身份和规则层验证。向量库不承担 sameAs 的权威关系，也不成为动作状态源。
缓存和物化层服务常用影响集合与派生属性。每个缓存结果都带依赖键；Campaign 配置、本体或规则变化后，相关结果失效。对高风险 proposal，在提交前仍重新读取关键远端状态，不能因为缓存命中而跳过基线检查。
最终，用户不需要知道一次建议用了几种数据库。产品 API 返回的是 Proposal、Evidence、Impact、Conflict 和 ActionStatus。存储与计算的多样性被边界吸收，业务语义保持一致。若系统把底层查询语言直接暴露给 Agent，换存储会变成业务破坏性变更。
决策解释应当是证明对象的投影
一个可审计解释至少回答五个问题：建议做什么；为什么适用于这些对象；使用了哪些数据和窗口；有哪些反对条件；执行后如何验证。它不能只给“综合考虑历史表现、相关性和库存”的模糊总结。
证明对象可以包含结论节点、支持 claims、阻断 claims、关系路径、事实快照和规则。渲染层根据读者角色生成不同视图：投手看到策略与风险，数据工程师看到粒度与来源，本体工程师看到公理和形状，审计人员看到批准和版本。它们引用同一底层对象，不各自生成一套真相。
最短解释不一定是最充分解释。搜索词迁移的最短路径可能只有 query—target—ad group，但批准动作还需要商品适配、冲突、利润和库存。系统应定义最小充分证据集，并允许展开次要路径。把整张图全部显示只会增加认知负担。
自然语言生成可以把技术关系转成中文，但必须受到结构约束。生成器只能引用证据对象中的事实，不允许补充未登记数字或因果。最终文本保存模板、模型和来源引用；如果生成失败，界面仍能展示结构化证明，不留下空白。
解释也要能表达未知和分歧。“库存数据已超过刷新时限，因此无法确认放量资格”比“当前不建议加价”更有操作价值；“模型认为查询意图接近，但商品负责人尚未确认”比确定语气更可信。系统的专业性经常体现在它怎样拒绝给出过度结论。
Amazon Ads 本体与图推理参考架构
第一层是事实与快照。Amazon Ads 报告、配置、Marketing Stream、AMC、库存、价格和财务数据进入各自受治理的存储，保留原始来源、时区、币种、粒度和提取版本。这里不追求统一成图，而追求可重算和可对账。
第二层是语义与身份解析。语义层定义 spend、sales、orders、ACOS、ROAS、TACOS、利润贡献和成熟度口径；identity service 生成带 profile、marketplace 和对象类型的稳定引用。任何跨域映射都要记录方法、置信度和人工确认状态。
第三层是领域本体与规则。OWL/RDFS 可以表达概念、子类、属性和部分公理，SHACL 或等价约束描述数据与 action 形状，策略规则表达资格与禁止条件。是否采用 RDF 栈取决于互操作和推理需求；属性图加版本化 schema、规则服务同样可以承载决策图，只要语义合同不被数据库标签替代。
图 11：每一层只承担自己的责任；任何写回都必须先经过 Proposal、审批与 Harness。
第四层是推理与影响分析。它接收固定事实快照和版本化本体，分别运行分类、路径、规则、约束、时间和概率任务。每个结果必须声明 conclusion type、supporting evidence、opposing evidence、rule version 和 expiresAt。不同引擎的结果在这一层汇合，但仍保持证据等级。
第五层是策略提案与模拟。系统把推理结果组装为类型化 Proposal，在影子状态中模拟新增 target、negative、bid、placement 或 budget 变化，计算影响范围和最坏暴露。LLM 可以生成面向人的解释，却不能修改结构化结论。
第六层是审批和执行 Harness。它验证 proposal 基线、风险额度、权限、幂等键和批准租约，再调用 Amazon Ads 适配器。API 返回后进入 submitted 或 unknown，独立回读确认远端状态，最后写入 execution receipt。推理服务没有写凭据，执行服务也不能自行改写业务规则。
这套架构最重要的不是组件数量，而是单向责任：事实层不背策略结论，推理层不拥有执行权限，解释层不篡改结构化证据，动作层不接受无版本的自由文本。边界清楚后，具体选用 Jena、Stardog、Neo4j、关系数据库或自研规则引擎才有意义。Apache Jena inference与 Neo4j neosemantics分别展示了 RDF 推理和属性图接入 RDF/SHACL 的工程入口，但都不是完整投放方案。
生产架构的硬边界是：任何推理结果只能创建策略提案，不能直接取得 Amazon Ads 写权限。只有经过基线校验、影响分析、批准、幂等执行和远端回读，结论才成为业务动作。
产品功能怎样切：不要把推理器做成万能后台
面向投手的第一个功能不是“图查询”，而是策略候选队列。每个候选显示动作、目标对象、证据成熟度、预计影响、反对理由、风险等级和失效时间。运营人员能够按 campaign、ASIN、策略目的或风险过滤，并明确选择批准、拒绝、补证或修改方案。
第二个功能是影响范围。它用可读的路径解释为什么某个 negative 可能阻断多个结构，为什么 placement 调整会影响 campaign 内其他 targets，为什么预算增加会与库存和利润约束冲突。用户可以展开到证据对象，但默认只展示决定结论的最短充分路径，避免把整张图当作答案。
图 12：三类角色看到不同工作面，但共享同一份受版本约束的 Proposal。
第三个功能是方案模拟。运营人员在影子图中比较“不动作、迁移但不否定、迁移并精确否定、降低原结构 bid”等方案。模拟只能计算结构和规则层面的确定影响；对转化和销售后果使用区间或模型预测，并明确标注假设，不能展示伪精确收益。
第四个功能是冲突与治理工作台。本体工程师和投放负责人共同处理未映射对象、规则冲突、过期概念、违反 shape 的 proposal 和反例。概念定义变更要显示受影响规则、查询、应用和历史测试；没有影响分析的“本体编辑器”只会让治理风险藏在后台。
第五个功能是执行与回查。审批页展示 before/after diff、授权作用域、幂等身份和回滚方案；执行页区分已提交、远端已确认、结果未知、部分成功和已补偿；复盘页把成熟业务结果连接回原 proposal。这样，决策图才从知识展示走向运营系统。
工程落地：不要每次把全图重新推一遍
广告事实持续变化，全量推理既昂贵，也会让大量无关 proposal 抖动。更合理的做法是从变更集计算影响域。一个 ASIN 库存状态变化，只让包含该 ASIN 的 ad groups、targets、campaigns 以及相关未过期 proposals 失效或重算；本体中一个上位概念变化，则通过依赖图找到受影响规则和能力问题。
推理结果需要物化策略。稳定、重复查询且计算成本高的分类或影响集合可以物化；高度依赖最新指标的资格判断更适合按需计算；模型分数应携带模型版本和生成时间，不能永久固化成对象属性。物化结果要有 invalidation key，避免事实刷新后旧结论继续服务。
一致性也应按作用域管理。全局图中出现一个坏实例，不应让所有账户停止推理。可以按 profile、marketplace、策略域和版本建立命名图或逻辑分区，错误进入隔离区。发布规则前先在影子分区运行能力问题和历史回放，通过后再逐步提升覆盖。
图 13：增量重算的重点是可解释的失效传播，而不是把整张图重新计算一遍。
工具选择应服从工作负载。Stardog inference engine展示了查询时推理，OWLAPI提供 OWL 程序化处理接口，pySHACL适合把 shapes 放入 CI。若团队的核心只是两跳影响分析和数十条策略规则，成熟关系库或属性图可能更简单；若需要开放本体复用、描述逻辑分类和标准交换，RDF/OWL 栈才有更明确的理由。
失败模式：图越大，错误传播半径越大
最严重的失败通常来自身份。把两个 marketplace 的 ASIN、两个 profile 下的 campaign，或文本相同但意图不同的 search terms 合并，会使所有后续路径合法地推导出错误结论。强同一关系必须有来源和人工确认，模糊匹配只能产生候选边。
第二类失败来自关系建模。把“曾经购买”当成“适合投放”，把“属于 campaign”当成“由 campaign 单独控制”，把历史 observation 当成当前属性，都会让图看起来连接丰富却语义失真。每条关键边应有定义、方向、来源、时间和允许用途。
第三类失败来自规则。规则循环可能造成推理不终止，过宽的上位类可能让局部策略传播到全账户，默认值可能把 unknown 伪装成安全。规则必须有 scope、priority、effective time、owner 和 counterexamples；发生冲突时，系统返回冲突而不是偷偷按加载顺序覆盖。
第四类失败来自解释。很多系统在结构化判断之后调用 LLM 生成理由，却只保存最后一段文字。若解释没有引用真实 fact、rule 和 path ID，它只是流畅复述。可审计解释应由证明对象渲染，LLM 只负责压缩和翻译，不负责发明缺失的因果关系。
第五类失败来自自动化。一个推理任务在测试数据上准确，不代表可以写生产账户。API 限流、批量部分成功、人工并发修改、权限变化、报告延迟都会破坏假设。动作 Harness 必须在提交前重新读取基线，在结果未知时先回查，不把普通重试当作恢复。
验证证明链，而不是验证一张图
第一组测试是 competency questions。它们不是“图里有多少节点”，而是系统必须可靠回答的问题，例如：这个 search term 为什么是迁移候选；新增 negative 会阻断哪些仍承担探索职责的路径；这个 placement proposal 会影响哪些库存风险 ASIN；结论使用了哪个归因快照。每个问题都要有预期路径和反例。
第二组是本体与规则单元测试。检查类是否可满足、关系方向和基数是否正确、非法状态是否被 shape 捕获、规则在边界值和 unknown 输入时是否给出预期结论。对 OWL 推理，测试 entailment 和 consistency；对 SHACL，测试 validation report；对路径规则，测试影响集合。
第三组是历史决策回放。冻结某一天运营人员当时能看到的事实，重放本体、规则和模型，比较 proposal 与真实评审。后到归因不得进入当时输入。失败要分类为身份、数据、语义、规则、模型、权限或执行，不用一个准确率掩盖机制差异。
图 14：验证越接近真实写回，所需证据、隔离和授权越严格。
第四组是动作契约测试。在模拟和沙箱中注入远端超时、部分成功、重复请求、权限拒绝和人工并发修改，验证系统能否停在正确状态、避免重复写、生成补偿方案并保留审计记录。对高风险动作，任何未经批准写入都属于硬失败，不能被平均业务收益抵消。
最后才是线上业务实验。影子 proposal 先比较人工判断，再开放小范围可撤销动作，观察成熟转化、利润、库存和流量结构。图推理提升的是决策一致性和可解释性，不直接保证 ROAS。若没有受控实验或可靠反事实，就不应把相关改善归因给本体。
从推荐系统走向可证明的决策系统
第一阶段只做只读影响分析。系统回答对象关系、冲突和证据来源，不产生动作建议。验收重点是身份正确率、关系覆盖、能力问题和证据追溯。这个阶段能尽早发现本体是否真的比现有 SQL 和语义层提供增量价值。
第二阶段运行影子提案。系统生成 MigrationProposal、NegativeProposal、BidProposal 或 BudgetProposal，与投手实际操作比较，不进入 Ads API。团队收集拒绝原因和遗漏条件，把它们转成规则、shape 或模型样本。
第三阶段开放人工批准的受限动作。每种 action 有对象范围、数值上限、有效期和回滚方式；先选小账户、低风险对象和可逆动作。执行后必须远端回读，结果进入决策图形成完整轨迹。
第四阶段才允许小范围自动闭环。自动化不是移除人，而是把经过重复验证、影响半径有限、损失上界明确的动作交给系统。任何本体、规则、模型或 API 版本变化都可触发降级回影子模式。
组织责任也要同步明确。投放负责人拥有策略目的和反例，数据团队拥有事实粒度、时间与对账，语义或本体团队拥有概念和关系，平台团队拥有推理、执行和恢复，安全团队拥有权限与审计。没有业务 owner 的本体会变成技术分类表，没有工程 owner 的规则会变成无法运行的政策文档。
结语：让每个结论都能沿图走回证据
Amazon Ads 的困难不在于找不到更多优化规则，而在于规则经常跨越不同对象、粒度、时间和组织边界。搜索词迁移同时改变观察与收割结构，否定词改变流量路由，placement 与 budget 改变整个 campaign 的暴露；任何单行指标都无法独立承担这些动作。
本体给这些对象、关系、状态和不变量一个明确名称，图让非局部影响可计算，推理把支持与反对证据组织成可重放的结论。数仓仍保存事实，语义层仍负责指标，模型仍负责概率判断，Harness 仍负责权限和可靠执行。它们不是被图替代，而是通过决策对象连接起来。
本体与图推理真正落地的标志，不是知识图谱上线，也不是 Agent 能回答更多问题；而是一次投放动作发生后，团队能够从远端结果沿着执行、批准、规则、关系和事实，一步步回到当时的证据。