A name in another script or a former name never meets its entity

[WaylandYang]

Cut 2 of 0041.

What happens

The identity bench (21 anchors, 19 same-entity pairs), on dev plus #699 with DeepSeek-V3.2:

order	precision	recall	F1
forward	0.846	0.579	0.688
reverse	0.800	0.211	0.333

All 8 pairs forward misses are names that share no string:

• a rename: 东海海洋研究所 → 澜海研究院
• the same name in two scripts: 澜海研究院 / Lanhai Research Institute, 李娜 / Li Na
• a transliteration: 海洋探测器2号 / Haitan-2

Recall is an exact match on name facts (0041 decision 1), so none of these pairs ever reached the review queue. The rename notice ("东海海洋研究所自2021年6月1日起更名为澜海研究院") came back as two entities, each carrying one known_as fact.

What a name vector can and cannot do

A probe embedded the bench names and a few from the other corpora with the configured model (BAAI/bge-m3) and listed each name's nearest neighbours:

name	the same entity: rank, cosine	ranked above it
李娜	Li Na: 1st, 0.579	—
张伟	Zhang Wei: 1st, 0.504	—
NVIDIA	英伟达: 1st, 0.676	—
Haitan-2	海洋探测器2号: 1st, 0.591	—
Microsoft Copilot	Copilot: 1st, 0.889	—
Lanhai Research Institute	澜海研究院: 3rd, 0.500	OpenAI 0.510
澜海研究院	东海海洋研究所: 2nd, 0.533	澜海研究院技术中心 0.892
海洋探测器1号	海探1: 2nd, 0.780	海洋探测器2号 0.856

• No threshold separates the pairs. Same-entity pairs across scripts score 0.50–0.68, unrelated names score around 0.50, and look-alikes score highest (a department and its institute 0.89, a product and its next version 0.86).
• A vector does not find a former name. Only the sentence that states the rename can.

Plan

1. Channel 2 proposes mutual nearest names. Within compatible types, A's nearest name is B's and B's nearest is A's. Such pairs go to the adjudicator and are never merged directly. The condition is structural and needs no threshold. On the probe it pairs 李娜/Li Na, 张伟/Zhang Wei, NVIDIA/英伟达 and Copilot, and also look-alikes that evidence has to keep apart. A background job embeds new name facts after a document is extracted, so extraction does not wait on it.
2. The extraction rules say a rename is one entity with two names: list it once under the current name and put the former name in names.
3. Measure:
   • identity bench, both orders; the target is recall ≥ 0.9 without losing precision;
   • regressions: lease bench, govern.mjs, recall on the NVDA filings, Chinese statistics and FDA approvals.

The cross-script institute ("Lanhai Research Institute", ranked 3rd) is left for channel 3, neighbours: it shares edges with 李娜 and 海探2.

[rollroyces]

Picking this up. The plan in the issue body is concrete — channel 2 is mutual-nearest-neighbour pairing by name embedding — but the implementation has a moving part I want to confirm before writing code.

What I see in the code today

• entities.profile_embedding exists and is the entity-level running-mean of chunk vectors (per vector_index.rs and resolution.rs). The current resolution path uses it.
• There is no per-name embedding column or table — name pairs are matched on lower(canonical_name) = lower(canonical_name) (graph::same_name_peers, graph.rs:1713). Issue body says the probe embedded names directly with BAAI/bge-m3, which is a separate signal from the entity profile.
• There is align_phrases (the queue for the adjudicator) but no align_names background job that would consume the matcher output.

Two questions before I write the patch

1. Where does the name embedding live? Adding a new names.embedding column with a new background job to populate it is one shape. Reusing the entity's profile_embedding (under the assumption that "an entity whose profile is similar to another's tends to be the same entity") is another. The first is faithful to the probe in the issue body; the second is faithful to what the codebase already has. My read: do the column + job, because the issue body's probe says the cross-script pairs (李娜 / Li Na) only show up at the name level, not the entity level — the entity profile averages across the document and dilutes the signal. But you may know otherwise.

2. Is the matcher a single PR, or is the embed pipeline its own cut? If it's one PR, the change spans: a new column + migration, a new background job to populate it, a new query function for mutual-nearest pairs, the integration into the adjudicator queue, and tests. That is a 600-800 line diff across 4 crates. If it's two PRs, I can do the matcher in isolation (against names that already have an embedding in the column) and the pipeline is a separate cut you or I pick up next.

I would rather do the matcher in isolation. That way the cut is reviewable on its own and the embed pipeline is a separate concern you can shape the way you want (single-pass on extraction, batch embed on a job, third-party, etc.).

What I would do in this PR

• A pure function mutual_nearest_name_pairs(pool, kb_id) -> Vec<NamePair> that reads from names.embedding (or whatever column you settle on) and returns the pairs.
• A test that constructs a known fixture (e.g. the issue body's 9 pairs) and asserts the function returns exactly those pairs.
• A PR description that points at the embed pipeline as a follow-up.

I will wait for answers to the two questions before writing code. The bench measurement (target: recall ≥ 0.9 on the 21-anchor corpus) is your validation step, not mine — I do not have a base with these fixtures in it and the existing bench_100k.rs is a different shape.

[rollroyces]

接手这件事。Issue 里的方案很具体——通道 2 是按名字 embedding 的互最近邻配对——但在写代码前我想确认一个变动部分。

我在代码里看到的现状

• entities.profile_embedding 存在，是文档块的运行均值（见 vector_index.rs 与 resolution.rs）。当前的消解路径在用它。
• 没有逐名字的 embedding 列或表——名字配对靠的是 lower(canonical_name) = lower(canonical_name)（graph::same_name_peers，graph.rs:1713）。Issue 里的探测是直接用 BAAI/bge-m3 嵌入名字，这跟实体的 profile 是两回事。
• 有 align_phrases（给裁决方排队的那个），但没有 align_names 后台任务去消费配对器的输出。

写补丁前先问两个问题

1. 名字的 embedding 放哪？。新增一列 names.embedding + 一个新后台任务去填充是一种形态；复用实体的 profile_embedding（假设"profile 相近的实体就是同一实体"）是另一种。Issue 里的探测走第一种。我倾向第一种，因为跨字脚本的配对（李娜 / Li Na）只在 名字 层信号才有，实体 profile 是文档均值，会把这个信号冲淡。但你可能另有判断。

2. 配对器是一个 PR，还是嵌入管线单独切一刀？。一个 PR 的话，改动覆盖：新列 + migration、新的填充后台任务、互最近邻的查询函数、接入裁决队列、再加测试。跨 4 个 crate，600-800 行 diff。分两个 PR 的话，我单独做配对器（对着已经有 embedding 的列），管线作为下一刀你来或我来切。我倾向分两个。

我在这个 PR 里做的事

• 纯函数 mutual_nearest_name_pairs(pool, kb_id) -> Vec<NamePair>，从 names.embedding（或你定下的列）读，返回配对。
• 用已知 fixture（Issue 里的 9 对）造一组断言：函数返回的就是这 9 对。
• PR 描述里写明嵌入管线是 follow-up。

我会等这两个问题的回答再写代码。基准测试（目标：在 21 个锚点的语料上 recall ≥ 0.9）是你那边的验收步骤，不是我的——我手上没有这些 fixture，现成的 bench_100k.rs 是另一种形态。