A quantity is never an entity

[WaylandYang]

上一刀（#586）把「整体是一个量」的宾语改走字面值通道，但只在谓词未知时生效。这一刀补上剩下的路，并把端到端真跑通。

一、已知谓词那一格漏着

判据前面挂着 !known_predicate：谓词一旦在本体里，整段判断跳过。实测的不对称就在同一个库里：

hasAmount  ← FIBO 包带进来的，抽取前已知  →  $1 billion 造成了节点
invested   ← 语料自己长的，当时还未知      →  被拦住了

两处补：is_entity_name 拦纯量值（主语宾语一视同仁，不问谓词）；宾语整体是量时一律走字面值通道，原词进 proposed_predicate。

二、值换不动，属性挂着 0 条事实

employeeCount (number) 在本体里、事实写着 employee_count → "1,250 people"，词对得上、属性也在，只因为模型把单位写进了值里就永远换不动。

加 parse_leading_quantity：开头是量、后面还有词也读得出那个数。它与 parse_quantity 的严格是两件事——后者要判「这串字是不是一个东西」，判错会吃掉真实体；这里调用方手上已经有一条声明了 datatype = number 的属性，问的只是「那个数是多少」。严的那套一点没松，测试里钉着。

三、键被同名关系占着，采纳直接放弃

冷启动建属性失败 key="valuation" error=Relation key 'valuation' already exists

占着键的关系常常是空的（本体包带来的、或早先按票数建的），一条事实都没挂。空关系改判成属性不破坏任何东西。有事实的一律不动——判据写在 SQL 的 NOT EXISTS 里，invested、raised 这类既连实体又带数额的照旧报错留给人看。

四、入口门槛不数值候选

够格的信号太少，跳过自动扩本体 predicates=0 types=0

12 条待认领的值事实摆在库里，proposed_predicates 只数宾语是实体的，于是算出 0，整个自动扩本体一次都没跑。把值候选也算进信号数。

五、datatype 由数据定，不听模型的

模型给 valuation 报的是 text，而等它的四个值全是 $12 billion 这样的量——存成 text 就比不了大小，而「能比大小」正是它们不该当节点的理由。手里有事实就不必去问判断题（keep_forms 那里已经是同一个原则）。

端到端

隔离库 + 六篇虚构语料，先手工把 pledged / valuation / investment_amount 等六个说法种成关系，造出「谓词已知」这个漏掉的条件，再整套跑一遍。

	修之前	修之后
纯量值实体	有	0
待认领事实	12	8
有谓词事实	10	13
valuation 的 datatype	text（存字符串）	number, 单位 $

Northwind | valuation | 12000000000.0
Northwind | valuation |  2000000000.0
Kestrel   | valuation |  7500000000.0
Kestrel   | valuation |   750000000.0
Kestrel   | employee_count | 1250.0
Northwind | employee_count | 3400.0

extraction_drops 全程为空，没有任何一条被代码挡掉。剩下的 8 条待认领是说法只出现在一篇文档里（MIN_DOCS，故意不动）或本体与语料的真分歧（pledged、raised 既当关系又带数额）——数、证据、时态都在库里，只差一个谓词。

一处如实说明

第一条那个 match 分支没有单测：它在 run() 那个上千行的 async 函数里，不重构抽不出来。is_entity_name、parse_quantity、parse_leading_quantity 三处都有测试钉着两侧边界（3M、7-Eleven、23andMe、2025 Atlantic hurricane season 一个都不误伤）。

🤖 Generated with Claude Code