SEC的Ticker字段，骗了多少AI

一个叫 IDENTIFIER_TICKER 的字段，SEC 官方文档只用一个词解释它："Ticker"。无数构建在 SEC 基金持仓数据之上的 AI Agent 照单全收，直接拿去 join 股票代码表。但我们把 SEC 自 2019 年四季度以来公布的每一期 Form N-PORT 量了一遍，发现这 1700 多万行数据里，真正的股票代码只占七成，剩下的全是抵押池前缀、发行人代码、期货合约号甚至货币代码。核心判断只有一句话：AI 时代数据质量的第一杀手，不是脏数据，而是那些"看起来完全正确"的数据。

🔍 字段名叫 Ticker，里面装的未必是 Ticker

最危险的错误，不是报错，而是返回一个看起来合理的答案。

先讲一个会让所有 Agent 开发者后背发凉的场景。你接到任务：分析美国公募基金的持仓结构。你让 Agent 去拉 SEC 的 Form N-PORT 数据——这是共同基金和 ETF 每季度必须提交的持仓申报表。Agent 读到 IDENTIFIER_TICKER 这个字段，看见文档写着"Ticker"，于是理所当然地把它当成股票代码，去关联一张证券主表。

然后，Freddie Mac（房地美）的抵押贷款支持证券池，一夜之间全部变成了 F&G Annuities & Life 这家寿险公司的持仓。

为什么？因为 "FG" 是 Freddie Mac 抵押池的前缀，同时也是 F&G Annuities & Life 在 NYSE 的股票代码。两个风马牛不相及的东西，在这个字段里撞了个正着。

问题的根源藏在意想不到的地方。Form N-PORT 本身的表单说明——Item C.1.e——写得清清楚楚：申报人需要提供"至少一个"其他标识符，优先填 ISIN（国际证券识别码），"如果没有 ISIN，则填 Ticker"，或者其他任何标识符。也就是说，这个字段从来就不是交易所代码的专用槽位，它只是一个兜底字段。而数据集文档只丢下一个词："Ticker"。

字段名是文档，表单才是真相——这条铁律，很多 Agent 开发者还没有真正消化。据多位接近数据供应商的人士透露，业内对这类"字段名与实际语义脱节"的抱怨由来已久，但几乎没有厂商愿意公开承认自家数据存在这类问题，因为承认的代价是下游所有引用都要回溯。

📊 一千七百万行数据背后的四种"假代码"

抽样会骗人，全量统计不会。

为此我们把 SEC 公布的每一期数据都跑了一遍——从 2019 年四季度到 2026 年二季度，覆盖 Form N-PORT 发布以来的全部历史。结果如下：

• 17,361,050 行携带 ticker 字段；
• 其中 72% 出现在普通股行，而且看起来确实是真实代码：MSFT、AMZN、AAPL；
• 在抵押贷款支持证券行（676,336 行），所谓 "ticker" 全是机构池类型前缀：FN 占 161,550 行，GN 占 109,156 行，FNMA 占 55,140 行，FHLMC 占 45,223 行；
• 在债券行（2,312,102 行），字段里填的是发行人的股票代码，而不是债券本身的代码——AT&T 的债券统一挂着它的股票代码 "T"，共 86,298 行；
• 在衍生品行，你会看到期货合约代码（TYZ2、ESZ2）和货币代码（USD、EUR）。

注意一个反直觉的事实：恰恰是因为 72% 的行看起来是对的，剩下 28% 的错才格外致命。任何基于抽样的数据验收、任何"肉眼扫几屏"的人工检查，都会被那 72% 的正常样本安抚，然后放心地把整张表喂给下游。数据质量评估里最经典的陷阱在这里完整复现——多数正确掩盖少数致命。

🤖 Agent 时代，脏数据的杀伤力被指数级放大

人类分析师会皱眉，Agent 只会执行。

在传统工作流里，这类字段陷阱有一个天然的安全阀：人。一位固定收益分析师看到某基金的"持仓"里冒出成排的 "FN" "GN"，大概率会停下来问一句——这是哪国股票？人工校验虽然慢，但它是对语义的校验。

Agent 链路把这个安全阀拆掉了。自动拉数、自动 join、自动聚合、自动生成图表和结论，一夜之间跑完，错误被系统性地固化进下游的模型特征、研报数字和投资看板里。更麻烦的是，Agent 不会主动报告"我没看懂这个字段"——它只会按字面意思执行，然后输出一个格式完美、语义全错的答案。

这张定位图想说明一件事：越是右上角的问题，越不靠测试用例解决，只能靠语义治理解决。抵押池前缀撞车、债券行挂发行人代码这类问题，输入格式全部合法、类型全部对得上，任何 schema 校验都会放行。唯一的拦截手段，是在接入层就理解"这个字段在表单原文里到底是什么意思"。

这也是我们说的 Data for AI 的第一课：当数据要喂给模型和 Agent 时，字段语义必须以协议原文、表单条款为准，而不是以字段名、文档一句话甚至社区惯例为准。前者是契约，后者是传说。

🛠️ 让每个数字可复算，才是真治理

一个好的 dashboard 数字，是别人能亲手复算出来的数字。

字段陷阱只是上半场。下半场的问题是：即便语义理解正确，一个衍生指标凭什么被信任？来自 Binergy / LUNQ 的一线工程笔记给出了朴素但击中要害的答案——在每个衍生数字旁边留下一份小的"证据记录"，而不是把它的含义埋在代码实现里。具体是三个动作：

第一，记录来源。记下生产方、端点或数据集的版本号，以及检索参数，并保留当时的输入快照。URL 会变，内容哈希能定位"某几个字节"，但哈希本身不能证明那几个字节是真实的——这是很多人对"可追溯"的常见误解。

第二，分离抓取时间与统计窗口。抓取时间说的是你的采集器什么时候拿到这条记录，聚合窗口说的是这个数字覆盖了哪些事件。两者要用显式的 UTC 时间戳和边界规则写清楚——比如"起点事件计入、终点事件不计入"。一个刚抓回来的响应，里面装的完全可能是很久以前的观测。

第三，单位与精度显式化。单位要紧贴数值，舍入规则要写明，对精度敏感的小数要用字符串保存原始输入。把一个二进制浮点结果"显示为两位小数"，并不等于记录了原始计算过程——显示值和计算值，是两个东西。

把这三件事连起来看，你会发现数据治理的真面目：它不是建目录、打标签、贴大屏，而是让每一个被引用的数字，都能被第三方独立重建。能做到这一点，前面那个 "FG" 撞车的陷阱根本活不到 Agent 的执行层——因为在证据记录里，这个字段的语义早就被钉死在表单 Item C.1.e 的原文上了。

据多位接近买方数据团队的人士透露，头部机构的 Agent 项目验收标准正在悄然变化：从"能不能跑通"转向"每个关键数字有没有证据链"。这不是流程洁癖，而是被坑出来的共识。

Agent 不会替你理解字段，它只会按字面意思执行。SEC 这一个字段揭开的，是整个 Data for AI 赛道即将集中爆发的老问题：数据供给侧的语义失真，正在被消费侧的自动化无限放大。可以预见，随着 Agent 从演示走向生产，"语义契约 + 可复算证据链"会从加分项变成入场券。下一轮数据平台的竞争，比的不是谁的字段多、谁的接入快，而是谁的语义少骗人、谁的数字敢让人复算。