智能实体解析
以建立可靠答案所需的最低努力来解析身份。仅当现有标识符、映射或确证证据不足时，才进行升级。此技能适用于真正模糊的个人和组织记录，包括竞争性简介或媒体候选人；常规图像处理和确定性ID连接不需要此技能。
核心原则
将实体解析视为分阶段调查，而非简单查找。精确搜索、slug查找、流行度和LLM判断都是有用的信号，但都不应默默地主导其他信号。
区分三个问题：
- 覆盖范围： 我们是否列举了所有请求的实体？
- 身份： 此候选人是否代表所请求的个人或组织？
- 效用： 这是否是该任务的最佳可用记录？
具有薄弱身份证据的高效用记录是误报风险。身份优先级高于流行度、个人资料完整性、图像可用性和搜索排名。
解析级别
选择最低的足够级别；更高级别不是强制性的先决条件。
- 第0级 — 直接识别： 匹配权威的稳定ID、规范URL或已验证的账户标识符。当此操作能解决任务时停止。
- 第1级 — 确定性对账： 使用显式交叉引用、已审别名、文档化的来源特定ID或已验证的身份链接。切勿发明映射。
- 第2级 — 上下文识别： 使用事件、会话、适时隶属关系、个人简介、项目所有权或独立验证的来源标识符来确证姓名。当候选人或证据冲突时升级。
- 第3A级 — 官方简介发现： 查找自控网站和社交账户、官方演讲者页面、雇主目录或项目和作者简介。优先选择链接自其他可信来源的简介。
- 第3B级 — 独立确证： 跨独立来源比较标识符、别名、事件、项目、隶属关系和日期。同一篇传记的联合副本不算作单独确认。
- 第3C级 — 别名与历史对账： 使用显式映射或独立确证来解析艺名、拼写变体、音译、历史雇主、收购以及跨事件的出现。保持隶属关系的时间范围。
- 第3D级 — 候选人恢复： 搜索别名和上下文化名称，探测直接ID、URL和slug，并且仅在普通查找遗漏可能记录时使用LLM建议针对性的检索探针。生成的候选人不是经过验证的身份。
- 第3E级 — 高保真裁决： 比较身份证据、来源权威性、历史一致性、冲突记录和有意义的替代方案。LLM可以总结或重新排名候选人，但不能替代来源支持的身份识别。
- 第4级 — 敏感或未解决： 当身份仍然模糊、持久合并或发布会产生重大后果、会暴露私人信息或需要进行生物识别时，要求显式审查。返回
ambiguous、needs_review或unresolved。
首选来源
对于身份和当前自我展示，优先考虑自控来源：
- 个人网站、博客或已验证的个人域名。
- X/Twitter帐户。
- LinkedIn简介。
- GitHub简介。
- Hugging Face简介。
- Google Scholar、Semantic Scholar、ORCID或arXiv作者简介。
- 个人YouTube频道。
- Substack、Medium或Dev.to简介。
- Bluesky或Mastodon帐户。
相互链接、一致的用户名、共享域名、项目所有权和发表历史可以加强身份验证。仅凭匹配的显示名称或平台徽章并不能确立帐户所有权。
当问题变更时，更改来源优先级：
- 事件参与和历史隶属关系： 组织者发布的ID、官方演讲者页面和日程、特定事件的传记、Sessionize或Accelevents记录以及同期演示材料的优先级高于后来的简介。
- 当前角色或自我展示： 最近维护的个人网站、已验证的社交账户或当前雇主页面的优先级高于旧的会议传记。
- 规范头像： 优先选择个人验证的自选简介图像、经批准的组织者头像或与稳定ID关联的官方活动肖像。公共URL不授予图像再分发或训练权利。
- 一般搜索： 使用网页结果来发现候选人或确证事实；不要将搜索排名视为证据。
切勿将猜测的缩略图、邻近会话照片、面部相似性或生物特征嵌入视为已验证的身份证据。
工作流程
-
在搜索前对查询进行分类。检测它是单个实体、实体列表还是模糊的群体/演员/成员/团队/组织查询。诸如
members、cast、lineup、team、company、subsidiaries和leadership等术语通常意味着需要扩展。 -
在查找前解析类似指令的查询。用户经常将实体提示包装在任务文本中，例如
find the full profiles for...、guess the grouping that includes...或resolve these partial names...。提取实体提示区域，保留原始指令作为上下文，不要将整个指令字符串作为字面数据库查询发送。 -
仅当直接识别或文档化的映射不足时，将模糊查询扩展为实体组。在确实需要枚举个人或组织时使用LLM或搜索工具。保持别名归入一个实体下。
-
对每个实体组进行广泛搜索。对于每个实体，搜索多个别名、清理后的变体、精确slug或直接ID候选（当目标数据库支持时）以及上下文化的短名称查询，例如
<group> <short name>。使用本地每个实体查询跟踪；全局查询去重可能会使后续具有通用别名的实体挨饿。 -
当确定性检索为空或薄弱时，考虑使用LLM检索规划器。规划与重新排名是分开的：询问直接ID、URL slug、精确名称探针、别名和上下文搜索。保持探针有界和高精度。
-
通过稳定记录身份合并候选人。按个人资料id、slug、规范URL、数据库id或其他稳定键进行去重。保留找到候选人的每个查询和来源，而不仅仅是保留最高分的路径。
-
在重新排名前丰富候选人。收集身份、来源、效用、模糊性和置信度等方面的概念性证据。永远不应该要求重新排名器仅凭名称进行选择。
-
仅对真正竞争的候选人使用有界的LLM重新排名。仅在另一次遍历可以显著改善覆盖范围或区分出可能身份时继续。
-
当有意义的替代方案可能改变决定或允许更正时，将其展示出来；权威的精确ID匹配不需要制造出来的二流选手。
-
将未解决和不确定视为首要结果。优先选择
needs review、no plausible match或ambiguous，而不是默默地填写一个高实用性的误报。
部分名称和模糊指令
当查询主要包含名字、短别名、首字母缩写或部分组织名称时，不要将原始数据库命中视为足够。当分组术语、完整个人资料意图或大部分是单token的名称使直接结果不可靠时，进行扩展或分类。
保留查询的两种表示形式：
originalQuery：完整的用户指令和上下文。entityHints：要解析的候选名称或别名的提取列表。
扩展模型应该看到两者。要求它推断出可能的共享上下文并返回具体的实体，并带有分组的别名。对于每个扩展的实体，保留一个标签加上别名，然后在该实体分支内搜索这些别名。对于简单的精确名称，直接搜索路径仍然可以运行，但当覆盖范围依赖于从部分提示推断出完整身份时，它不应抑制扩展。
覆盖范围与结果数量是分开的。五个请求的提示产生了许多原始候选对象，在每個提示映射到一个选定的实体或显式的未解决/模糊结果之前，这些提示并未得到解决。跟踪expectedCount、resolvedCount、ambiguousCount和unresolvedHints或等效字段。
检索规划与差距修复
不要依赖重新排名器来挽救检索从未返回的记录。将LLM参与分为不同的角色：
- 扩展模型：“目标实体是谁或什么？”
- 检索规划器或修复模型：“检索器应该为该目标尝试哪些精确的id、slug、直接URL、别名和搜索探针？”
- 重新排名器模型：“鉴于这些丰富的候选人，哪一个是正确的记录？”
仅当直接的slug或ID可能恢复丢失的记录，或者实体没有候选人、没有可用数据或只有弱/通用名称匹配时，才使用检索规划。给规划器提供原始查询、分组的别名、尝试过的探针、来源失败和相关的来源约束。它应返回探针，而不是身份决定。
保持修复的有界性和相称性。对有用的探针运行确定性检索，合并恢复的候选人，并在额外搜索不太可能改变答案时将实体标记为未解决。
日志记录与扇出
根据任务的比例记录来源出处、选定的ID、模糊性和覆盖范围。避免原始私有负载。当独立的实体组已经同时处理时，保持分支状态的隔离并确定性合并；不要仅为满足此技能而引入扇出、遥测基础设施或重试。
证据模型
保持证据的概念性和可移植性。不要过度拟合到一个站点的字段。
- 身份证据： 精确名称或ID匹配、别名、艺名、法定姓名、音译变体、共享token、缺失的主要token、上下文匹配、已知的组织/组关系以及冲突的名称。
- 来源证据： 哪个查询找到了该候选人，是来自搜索、精确slug、直接URL、数据库id、API查找、网页结果、用户提供的来源、检索规划器探针还是恢复遍历。
- 效用证据： 图像数量、个人资料完整性、活跃度、流行度、浏览量、投票数、列表数量、员工数量、关系数量、验证状态、时效性，以及该记录是否具有用于任务的可用媒体或元数据。
- 模糊性证据： 短/通用名称、仅姓氏匹配、首字母缩写、重复记录、组/项目页面、“and the”页面、稀疏记录、冲突别名、旧名称、合并的组织、子公司或相似名称的公众人物。
- 置信度证据： 选定的候选人、亚军候选人、重新排名理由、未解决状态、需要人工审查标志以及原始查询的覆盖状态。
重新排名规则
当真正的模糊性需要时，使用LLM重新排名，受来源证据和任务适当预算的约束。
- 给重新排名器提供原始查询、已解析的实体标签、别名、候选人名称/ID/URL、来源、身份证据、效用证据和模糊性警告。
- 指示其在效用之前优先选择身份。如果身份证据薄弱，它不得选择图像丰富或流行的候选人。
- 对于看似相同身份的候选人，让效用决定。如果艺名或品牌名称记录具有更强的任务相关证据，它们可以优于法定名称记录。
- 除非有上下文、精确ID/slug、更丰富的别名重叠或强大的外部证据支持，否则将单token别名视为模糊。
- 避免硬性接受规则。直接别名命中是一个信号，不是证据。
- 避免硬性拒绝规则。音译、更名、稀疏或艺名记录可能看起来不完整但仍然是正确的。
- 如果一个同样受支持的候选人在任务效用方面明显更好，将其暴露出来或进行一次合理的额外比较，而不是默默地覆盖身份证据。
- 记录或显示所选候选人的理由，并保持备选方案可见。
失败模式
当解析器“大多工作正常”但感觉不对时，将这些作为审查检查点。
- 精确数据库搜索可能会遗漏真实记录。在可用时探测精确slug、直接URL、id或备用端点。
- 短名称会产生误报。
Lisa、Rose、Sunny、Tiffany、Yuri和类似的单token名称需要上下文搜索和模糊性警告。 - 法定名称可能是效用更低的记录。公共/艺名或品牌名称可能具有更完整的个人资料、更多的图像或更新的元数据。
- 效用信号强大但单独使用不安全。计数、投票、浏览量和流行度应该在身份合理性判断之后才用于打破平局。
- 复合别名是有用的上下文，但通常是不好的文字搜索字符串。将它们拆分为别名，同时保留组身份。
- 硬性的直接接受逻辑很脆弱。它可能仅仅因为一个别名匹配就抓取了一个通用重复项。
- 硬性的身份门控很脆弱。当名称稀疏、已翻译、音译、更名或仅限艺名时，它们可能会隐藏正确的记录。
- 覆盖数量不等于正确性。找到6个实体中的6个并不算成功，如果其中一个选定的记录是错误的人或组织。
- 全局查询去重可能会饿死后续实体。通用别名应按实体组进行跟踪。
- 来源的不稳定性是结果的一部分。超时、403、404、重试和部分数据应在来源或调试日志中体现。
- 重新排名器无法修复缺失的候选人。如果目标分支没有候选人，在重新排名之前插入检索规划或修复，而不是期望重新排名器推断出一个隐藏的记录。
- 指令文本可能毒害字面搜索。从查找查询中剥离任务短语，同时将它们保留为扩展和重新排名的上下文。
- 快速的直接结果可能会抑制后续扩展。
[截断以供翻译]