Utopia 实体身份（Identity）设计解析：名字即证据，证据定身份

后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载Utopia 是开源的企业级世界模型enterprise world model项目本仓库为ont/utopia的镜像。本文以 docs/design/identity.md 为骨架结合 0041 号决策记录 与utopia-store、utopia-server源码及迁移脚本系统讲解 Utopia 如何判定「一个名字到底指谁」名字如何作为事实进入账本、召回如何提出候选、证据如何决定归属、合并如何可撤销以及这条设计线的评测基准与未竟事项。读完你将掌握 Utopia 身份解析entity resolution的完整链路从抽取契约里的names字段到known_as名字事实、name_vectors向量召回、shared_name裁决队列再到可回滚的entity_merges并能读懂 identity 基准 的评测口径。核心结论先行Utopia 对实体身份的答案只有一句话——身份由证据决定而不是由字符串决定。名字是实体的一条事实可以错、可以改、可以带时间召回只是「报个到」地提出候选证据共享边、互斥值、类型不相交才做决定不确定时拆开并送审绝不静默合并。一、身份问题的两种失败方式以及一个统一解释设计文档开篇就给出了问题框架以表面字符串为键的身份会以两种方式失败重名namesake一个字符串对应多个事物。同一家公司里两个「张伟」、两家公司各自的「技术中心」、探测器的「1 号」和「2 号」——字符串一样人/物不同。多名alias / 别名多个字符串对应一个事物。海洋探测器 1 号在发射通告里写作「海洋探测器1号」之后的每篇报告都只写「海探1」一个名字有中文和英文两种写法。老方案里这两种失败会进一步被入库顺序放大解析是贪心的、永不回头的——先到的文档给实体播种画像profile后到的文档要么贴上去、要么裂开。0041 记录里那句探针写得很直白今天探测仪会变成两个实体Review 里什么也没有两个张伟会变成一个实体或者一个永远等不到人的平局——取决于哪篇文档先到。而docs/design/identity.md的核心段落What it does today说明这条线已经推进到了什么程度名字已经是事实召回有了双通道合并可以在两个时钟上都撤销裁决器以证据为先。下面逐节展开。二、名字即事实known_as值事实与账本化名字2.1 名字进账本不再进entities.aliases0041 决定 1 的落地方式是迁移 0055_a_name_is_a_fact.sql旧结构entities.canonical_name一个标签 entities.aliases一串别名。别名只有合并会写没有出处、没有时间、撤不回单个抽取读到的「简称海探1」根本进不来。新结构每个名字都是内建属性known_as上的一条值事实value factobject_value {value: 名字}object_id为空——名字是值不是节点。这条设计有四个刻意为之的性质不成节点不产生边、不占计数画布只画带object_id的边名字事实与数量值走同一条通道#586/#587。因此名字不撑大图计数、不冒充证据。时态引擎天然放行temporal只对声明了 functional / inverse-functional 的状态关系收口、记冲突known_as两者都不是重名本来就存在所以第二个名字不会关掉第一个也不会打开一个冲突。两个时钟俱全名字事实带recorded_at/invalidated_at记录轴我们何时知道与valid_from/valid_to世界轴该名字何时在世界上有效——「2019 年它叫什么」「我们何时学到海探1 海洋探测器1号」都可回答。可撤回、可合并搬动名字事实随合并一起搬、撤回合并时一起搬回不需要任何特判。2.2canonical_name的保留与迁移的工程细节canonical_name保留为界面显示的标签同时它本身也是一条名字事实迁移第 2 步为每个存活实体插入本名事实。迁移脚本对已合并实体做了细致处理第 3 步用递归 CTEname_walk沿merged_into链走到存活者把链上每个名字事实挂到存活者身上并把事实 id 追加进链上每条未撤回合并的moved_subject_facts——这样撤回链上任何一环名字都跟着那一环回去同名去重「Apple」并入「Apple」则记入invalidated_facts撤回时一并复活。脚本注释里还记录了性能教训临时表无索引、逐行相关子查询的写法在 20 万实体、4.5 万合并的库上要跑八分钟以上因此每一步都写成「一次扫描加连接」。从 crates/utopia-store/src/names.rs 可以看到运行时对应物ensure_known_as按需创建内建属性与is_a同一做法builtin TRUE建库时不铺第一次用时建record写名字事实 证据chunk 引文同名同实体只有一行按主语、谓词、值去重再被提到只是多一条证据has_name_in/not_a_name分别给召回与列事实用——实体面板、审阅卡、度数、规则这些地方名字不算「一条事实」不能冒充证据、不能把计数撑大。2.3 抽取侧模型报名字服务端只核对「在不在原文里」0041 决定 2 的契约是一份names: [{ref, name, quote}]。服务端的核对只做两件事且没有词表名字在它的引文里、引文在 chunk 里 → 保留同一响应或本文档更早的 chunk 已把这个字符串声明给另一个实体 → 丢弃name_claimed_by_one之外的name_claimed_by_another信号——一个字符串不能同时命名两个东西这不需要任何词汇表。「简称」「又名」「aka」「formerly」这些词服务端一概不认也不需要认是否把某个词视为名字是模型的职责写进契约服务端的职责只是字符串在场校验。names.rs中is_name_attribute的注释点明了另一层防线名字走自己的通道抽取回复里的names不能当一条普通属性被模型直接写进来——那样就绕过了核对。设计文档还记录了一个已知缺口模型把描述报成名字而不声明实体时仍会漏过「海探1项目」在每轮 cut-1 运行中都成了海洋探测器1号的别名这是 0041 的开放问题之一。三、召回Recall两条通道只出候选、永不决定3.1 通道一字面精确匹配名字事实召回的第一条通道是精确字符串匹配mention 的名字及其去掉泛用后缀的键与同类型实体的名字事实精确相等。注意三个细节曾用名照样召回names.rs的has_name_in只看记录轴invalidated_at IS NULL不看世界轴——更名之前的旧文档还在用旧名字所以世界轴上已结束的名字仍然认得出它。只认现行名字事实查询带上facts_value_text_idx迁移 0055 末尾为(kb_id, lower(value)) WHERE invalidated_at IS NULL建的索引names.rs注释特别强调要用不相关子查询 按库过滤否则规划器用不上索引每次召回都要扫全表 facts。同类才配类型是候选的门槛e.type_id IS NULL OR me.type_id IS NULL OR e.type_id me.type_id之类的约束在共享名排队逻辑里。3.2 通道二名字向量name_vectorscut 2 已建通道一有个结构性的洞「海探1」在一篇从没写过全名的文档里谁也碰不上一个名字写成两种文字也永远是两个实体#709。0041 决定 3 的通道二——名字字符串的向量——正是为此在同类家族内取最近的几条名字事实向裁决器提议一个name_vector|cosine对从不自动挂接。短称、另一种文字的名字通过一个问题而不是一个静默的第二实体与它的实体相遇。落地迁移是 0080_a_name_has_a_vector.sql一张从表name_vectors一条名字事实一行embedding不定维随所选嵌入模型与chunks.embedding同一条规矩HNSW 由vector_index按第一次写下的维度排任务去建复合外键把「事实存在」和「事实同库」合成一条约束0070 §1bkb_id落定后不可改——但合并搬名字事实时entity_id要能改所以触发器只禁改 kb名字事实作废时向量留着查询那头按事实是否现行过滤——作废是可撤的向量不必重算。从 crates/utopia-store/src/name_vectors.rs 的注释看这条通道的相似度阈值设在 0.4 上下「所以这条线比画像的SIM_ATTACH高。同样是待测量的临时值」——即阈值是显式标注的临时值等待基准来校准。3.3 通道三共享显著邻居cut 3未建第三条通道是邻居与 mention 在同一响应中解析出的事实共享一个显著邻居的实体——同谓词、同解析对象、且对象不被其他候选指向。这条通道在 0041 中是 cut 3 的内容尚未实现属于「Proposed and not built」。3.4 第一通道才做决定画像向量的三档阈值设计文档的关键表述是只有第一通道决定任何事情。这里的「决定」指上下文向量profile_embedding实体被提及的 chunk 向量的运行均值的阈值判断实现在 crates/utopia-store/src/resolution.rsSIM_ATTACH 0.55候选余弦 ≥ 0.55 →挂接attachSIM_NEW 0.35 0.35 →新建实体中间地带0.35 ~ 0.55→新建实体 送一对给裁决器两个同名候选分数贴着最高分差 ≤SIM_TIE_MARGIN 0.02→ 送人#270除非corroborating_candidate在 chunk 里找到某个候选的对象名#331 让事实打破平局CONFUSABLE_TYPE_KEYS [organization, project, product]三键硬表给没装包的库兜底声明了disjointWith时它让位见下节。注意设计文档的原话——「上下文向量只用来打破平局不做别的事」——这是 0044 提议阶段的立场当前实现中画像向量仍是通道一内的裁决依据。四、类型与不相交重名实体「先分开后裁决」两个重名实体能不能共存取决于类型声明的不相交优先owl:disjointWith现在有表、有导入、有编辑端点0016 B3解析时declared_disjoint_from用一条递归查询收集与 mention 类或其祖先声明不相交的类再展开到它们的后代——先于一切启发式同名实体直接判Disjoint亲属类送审同名实体属于 kin 类祖先、后代或共享非根祖先→ 送 Review#226无声明时兜底CONFUSABLE_TYPE_KEYS三键硬表没有包时这层不命中跨类型同名一律Disjoint——更严格不会错并0009无类型可共存entities.type_id自 0009 起可空无类型同名实体允许共存——NULL ≠ NULL唯一索引拦不住它们而这是故意的无类型时我们知道得更少更没有理由合并。这条线在 0001 里还有配套决策名字冲突是提示而不是 409——改名/改类型时 UI 提示「已存在同名实体是否合并」让用户继续唯一约束或 409 会打破解析的地基两个张伟正是「不确定就分开」的产品形态。五、合并可撤销、有闸门、审计留痕5.1 两个时钟上的可撤销entity_merges记录合并把什么搬走了带created_at/reverted_atrevert_merge把事实、名字事实、限定词搬回去。读取端带as_of记录轴回放时合并发生之前的瞬间显示两个节点——这正是 0019 的「第二时钟可以被倒拨」。名字事实随合并走、随撤回回靠的就是迁移 0055 里moved_subject_facts/invalidated_facts的追加机制无需特判。5.2 谁有资格合并合并是人的动作、裁决器在 0.8 置信时的动作、或治理闸门governor放行后的动作。自动合并当它会让图「离开」时某一时刻的 functional 冲突、一条推导、一个被引用的答案会被扣住等人0027错误合并会把两个实体的事实混在一起而撤回并不能召回此后在它之上建起的推导、违规与答案。5.3 改名、改型与审计entity.retyped/entity.renamed进审计账本带前后快照改名撞名是合并的提示不是 409。归属裁决器 / 治理闸门详见 governance.md。六、裁决器Adjudicator一对十二证据线与机械规则设计文档给出的裁决器工作方式每次调用给12 对每对带名字、类型、顶部事实、「又名」行与账本先例未决的对会带工具再看一遍身份规则identity rules只写一次、两个提示词共用版本/版次/分部后缀是不同事物含名字的短语不是名字列表不是其成员被丢弃的限定词、公司后缀、姓氏、缩写是同一事物一份文档历经修订仍是同一事物两条机械规则name_shape英文词缀与介词分类与type_family类型族。机械规则name_shape是 0041 决定 6 的退役对象一旦基准证明闸门抓不到证据抓不到的东西name_shape与CORPORATE_SUFFIX就离开闸门。它现在仍挡着Version/Phrase形状的合并——因为模型会对「Claude 和 Claude 4」「Sam Altmans efforts 和 Sam Altman」说same0041 的证据规则预期会用 functional 冲突两个发布日期分开前者、用 span 校验#582让后者根本不成为实体。七、先例shared_name排队与「又名」行0041 决定 5修订版解决的是到达顺序问题cut 1 曾让倒序更糟——只有缩写的文档先建了「海探1」写着「简称海探1」的文档最后到把名字记在新建的全名实体上结果没有任何东西把两者配成对。修订后的规则在 crates/utopia-store/src/names.rs 的pair_shared_name中实现一个名字另一个兼容类型的实体已经持有 → 排队shared_name|名字对给裁决器永不合并类型一方为空或两边相同才配对已经判过「不是一个」的对不再排队否则同一个简称每出现一次就重排一次等于没记住分开的决定裁决器与 Review 卡片看到实体的非本名作为「also known as」行本名不列出——两个重名者因此不会显得共享证据没有那行时裁决器在 0.90–0.95 置信度下仍把对拆开。pair_shared_name的查询注释还写明了一个防御细节同名候选路径在相似度 ≥SIM_ATTACH时只出候选、永不自动合并resolution.rs 第 647 行附近的注释排队时用resolution_reviews的kept状态做去重。八、评测identity 基准与双向 F1docs/design/identity.md的 Bench 一节给出了评测口径脚本在 scripts/bench/identity.mjs语料scripts/bench/corpora/identity/双语含一家公司里的两个重名、一篇文档里的两个重名、一个跨无关文档的人、全名缩写两种到达顺序、带日期的更名、一个名字的中英文两种写法、必须分开的相似物两家公司的技术中心、产品与其下一版本、公司与同名水果真值scripts/bench/truth/identity.json锚点分组「这篇文档里、引文含这段话的事实、这个类型那一侧的实体是真实世界的哪一个」打分以锚点解析到的实体 id两两比较是否相同计 pairwise precision / recall / F1同实体对。名字不参与打分——否则别名与重名会先把打分本身搅乱到达顺序是被量之物同一轮正序、倒序各建一个库新建 → 种本体冻结自动扩本体/类型消解/治理/物化 → 逐篇灌入并等任务停 → 打分两边的判定差异作为数字报告附属报告split_in_doc同一篇内拆开、false_merges/false_splits、每个真实实体落成几个系统实体、lookalikes 是否被错误合并、pending_reviews送审队列分布。历史数字0041 记录头均为一轮或数轮的实测非承诺cut 0 基线 forward F1 0.43、reverse 0.54cut 1 后 forward 0.68、reverse 0.68210 对两个顺序一致各一轮两轮 cut-1 运行 forward 差 0.07在 DeepSeek-V3 上重测dev 0.46 / 0.4021 个锚点中 2 个未决cut 1 为 0.61 / 0.44–0.53三轮。ai-timeline.duplicates.jsongovern.mjs背后的真值作为回归一并跑。九、为什么这么设计身份设计的原则清单docs/design/identity.md的 Why 一节浓缩了整套设计动机可作为阅读决策记录的索引表面字符串为键必败重名与别名就是同一把键的两种失效方式主题向量记录的是段落「关于什么」不是「谁在里面」且结果依赖到达顺序0041。名字必须能错、能改、能带时间这正是账本对一切其他事实做的事单独建表等于把有效性、出处、撤回在账本旁边重建一遍0041。服务端核对的是「文本在场」不是词表迄今每张词表都只覆盖作者想到的说法且name_shape看不见中文名字的形状0041、0044 d8。不确定就分开错误合并把两个实体的事实混在一起而撤回不召回此后建起的推导、违规与答案0001、0027。两个同型张伟必须可分存名字索引是普通索引NULL 类型不冲突0001、0009。共享名去裁决绝不合并倒序到达曾让全名落在新实体上、无人配对0041 d5 修订。子句不是实体名按词数与定式动词判定——57 字的法院名与 65 字的子句无法按长度区分0012。十、现状边界与未竟事项Proposed and not built设计文档明确区分了「已建」与「提议未建」已建名字即事实cut 1迁移 0055name_vectors通道二cut 2迁移 00802026-09-23shared_name先例排队两个时钟上的合并撤销disjointWith先于一切启发式。未建0041 cut 2 通道三与 cut 3/4邻居通道证据决定共享显著边 / 反函数值重叠有效 / 共享名不算证据 / 上下文向量只打破平局响应解析后再解析 mention、删除doc_cache名字或边到达时重评估cut 4name_shape与后缀词表的退役等基准证明闸门抓不到证据抓不到的东西。跨文档身份0044 d6文档内合并实体、以名字/类/属性/邻居/时间跨度为画像跨文字脚本的候选确定性打分与 cannot-links只有未决对才送裁决器裁决器看两份画像约束聚类使 A≈B、B≈C 永不违证并 A、C更名是一个实体、名字在不同时间有效角色不是实体。#725 退役清单写时解析resolve_mention、阈值、containment_reviews、resolve_type_drift、doc_cache、无嵌入回退、批裁决器与resolution_verdicts、词表退役要等设计通过 identity 基准与 Linked-Re-DocRED 对。开放问题被报为名字的描述「海探1项目」能否不用词表挡住0041两个无类型重名只靠画像相似度0009确定性证据在裁决器介入前能解决多少0044跨库重名先例0025。附深入阅读路径设计总览与领域索引docs/design/README.mdidentity 域的现状说明、相关决策记录状态表决策记录核心为 0041-a-name-is-a-claim-about-an-entity.md配套 0001、0009、0019、0025、0027、0028迁移0055_a_name_is_a_fact.sql、0080_a_name_has_a_vector.sql实现crates/utopia-store/src/names.rs、crates/utopia-store/src/name_vectors.rs、crates/utopia-store/src/resolution.rs阈值常量SIM_ATTACH/SIM_NEW/SIM_TIE_MARGIN、CONFUSABLE_TYPE_KEYS基准scripts/bench/identity.mjs 与 scripts/bench/truth/identity.json、scripts/bench/corpora/identity/ 语料治理侧细节docs/design/governance.md时间轴/双时钟docs/design/time.md、docs/decisions/0019-the-second-clock-can-be-rewound.md赞分享后端前端人工智能RAG知识图谱知识管理搜索引擎【免费下载链接】utopiaWorlds first open-source enterprise world model.项目地址https://gitcode.com/gh_mirrors/ont/utopia点击查看免费下载相关推荐Material-UI数字签名数据完整性验证与身份认证Material UI数字签名数据完整性验证与身份认证 引言 在当今数字化时代数据安全至关重要。数字签名Digital Signature作为一种重要的前端UI组件设计系统Wasp 邮箱认证身份数据深度解析email identity 字段、存储原理与访问实践Wasp 邮箱认证身份数据深度解析email identity 字段、存储原理与访问实践 导读 在 Wasp 全栈框架中启用邮箱Email认证后每个用户Web框架后端前端CLI开发工具mlx-lm深度解析AI开发者必知的LLM本地部署新范式mlx lm深度解析AI开发者必知的LLM本地部署新范式 还在为LLM本地部署的高额硬件成本发愁mlx lm正以革命性的方式改变这一现状。作为专为Apple密码学网络通信上一篇在 Cursor 中通过 Gong MCP 插件拉取账户摘要、交易洞察与通话简报下一篇HCCL Star 算法解析星型拓扑一步完成有根通信的原理、适用场景与耗时模型创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考