智慧型身份解析
以最低努力層級解決身份問題，建立可靠答案。僅在現有識別碼、映射或佐證證據不足時才升級。此技能適用於真正模糊的人物與組織記錄，包括競爭的個人檔案或媒體候選；普通的圖片處理與確定性 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 候選項目，以及情境化的短名稱查詢，例如
<群組> <短名稱>。使用每個實體本地的查詢追蹤；全域查詢去重可能會使後續具有常見別名的實體缺乏結果。 -
當確定性檢索為空或薄弱時，考慮使用 LLM 檢索規劃器。規劃與重新排序不同：要求直接 ID、URL Slug、精確名稱探測、別名與情境化搜尋。保持探測有界限且高精度。
-
根據穩定記錄身份合併候選項目。透過個人檔案 ID、Slug、標準 URL、資料庫 ID 或其他穩定鍵進行去重。保留找到候選項目的每個查詢與來源，而不僅僅保留最高分數的路徑。
-
在重新排序前豐富候選項目。收集跨身份、來源、實用性、模糊性與信心的概念性證據。不應要求重新排序器僅從名稱中選擇。
-
僅對真正競爭的候選項目使用有界限的 LLM 重新排序。僅在另一次傳遞能實質改善涵蓋範圍或區分可能身份時繼續。
-
展示有意義的替代方案，當它們能改變決定或啟用修正時；權威的精確 ID 匹配不需要人為製造的亞軍。
-
將未解決與不確定視為首要結果。寧可回傳
needs review、no plausible match或ambiguous，也不要默默填入高實用性的假陽性。
部分名稱與模糊指令
當查詢主要包含名字、短別名、姓名縮寫或部分組織名稱時，不要將原始資料庫命中視為足夠。當分組詞彙、完整個人檔案意圖或大部分為單詞名稱使直接結果不可靠時，進行擴展或分類。
保留查詢的兩種表示法：
originalQuery：完整的使用者指令與上下文。entityHints：要解析的候選名稱或別名提取列表。
擴展模型應同時看到兩者。要求它推斷可能的共享上下文，並回傳具體實體與分組的別名。對每個擴展的實體，保留標籤加上別名，然後在該實體分支內搜尋那些別名。直接搜尋路徑仍可對簡單精確名稱執行，但當涵蓋範圍依賴從部分提示推斷完整身份時，它不應壓制擴展。
涵蓋範圍與結果數量不同。五個要求的提示產生許多原始候選項目並不算是解決，直到每個提示映射到一個選定的實體或明確的未解決/模糊結果。追蹤 expectedCount、resolvedCount、ambiguousCount 與 unresolvedHints 或等效欄位。
檢索規劃與缺口修補
不要依賴重新排序器來拯救檢索從未回傳的記錄。將 LLM 參與拆分為獨立角色：
- 擴展模型：「目標實體是誰或什麼？」
- 檢索規劃器或修補模型：「檢索器應為此目標嘗試哪些確切 ID、Slug、直接 URL、別名與搜尋探測？」
- 重新排序模型：「給定這些豐富的候選項目，哪一個是正確的記錄？」
僅在直接 Slug 或 ID 可能復原缺失記錄時，或當實體沒有候選項目、沒有可用資料或僅有弱/常見名稱匹配時，才使用檢索規劃。提供規劃器原始查詢、分組別名、已嘗試的探測、來源失敗與相關來源限制。它應回傳探測，而非身份決定。
保持修補有界限且相稱。對有用的探測執行確定性檢索，合併復原的候選項目，並在額外搜尋不太可能改變答案時將實體標記為未解決。
日誌記錄與扇出
根據任務記錄來源來源、選定的 ID、模糊性與涵蓋範圍。避免原始私人負載。當獨立實體群組已在並行處理時，保持分支狀態隔離並確定性合併；不要單純為滿足此技能而引入扇出、遙測基礎設施或重試。
證據模型
保持證據概念化且可移植。不要過度擬合到一個網站的欄位。
- 身份證據：精確名稱或 ID 匹配、別名、舞台名、法定名稱、羅馬化變體、共享詞彙、缺失主要詞彙、情境匹配、已知組織/群組關係與衝突名稱。
- 來源證據：哪個查詢找到候選項目，它來自搜尋、精確 Slug、直接 URL、資料庫 ID、API 查詢、網頁結果、使用者提供的來源、檢索規劃器探測或修補傳遞。
- 實用性證據：圖片數量、個人檔案完整性、活動度、人氣、觀看數、投票數、列表數量、員工人數、關係數量、驗證狀態、新近度，以及記錄是否具有任務可用的媒體或元資料。
- 模糊性證據：短/常見名稱、僅姓氏匹配、姓名縮寫、重複記錄、群組/專案頁面、「and the」頁面、稀疏記錄、衝突別名、舊名稱、合併組織、子公司或類似名稱的公眾人物。
- 信心證據：選定候選項目、亞軍候選項目、重新排序原因、未解決狀態、需人工審查標誌，以及原始查詢的涵蓋狀態。
重新排序規則
當真正模糊性需要時，使用 LLM 重新排序，受限於來源證據與適合任務的預算。
- 提供重新排序器原始查詢、已解析的實體標籤、別名、候選名稱/ID/URL、來源、身份證據、實用性證據與模糊性警告。
- 指示它先選擇身份再考慮實用性。如果身份證據薄弱，它不得選擇圖片豐富或受歡迎的候選項目。
- 對可能同一身份的候選項目，讓實用性決定。公開的舞台名或品牌名記錄如果具有更強的任務相關證據，可以優於法定名稱記錄。
- 除非有情境支持、精確 ID/Slug、更豐富的別名重疊或強烈外部證據，否則將單詞別名視為模糊。
- 避免硬接受規則。直接別名命中是訊號，而非證據。
- 避免硬拒絕規則。羅馬化、重新品牌化、稀疏或僅舞台名的記錄可能看起來不完整，但仍可能是正確的。
- 如果一個同等支持的候選項目具有實質更好的任務實用性，將其暴露或進行一次合理的額外比較，而不是默默覆蓋身份證據。
- 記錄或顯示選定候選項目的原因，並使替代方案保持可見。
失敗模式
當解析器「大致可用」但感覺不對時，使用這些作為審查檢查。
- 精確資料庫搜尋可能錯過真實記錄。當可用時，探測精確 Slug、直接 URL、ID 或替代端點。
- 短名稱會產生假陽性。
Lisa、Rose、Sunny、Tiffany、Yuri與類似的單詞名稱需要情境化搜尋與模糊性警告。 - 法定名稱可能是較差的實用性記錄。公開/舞台名或品牌名可能具有更完整的個人檔案、更多圖片或更新的元資料。
- 實用性訊號很強大，但單獨使用不安全。計數、投票數、觀看數與人氣僅應在身份可能性之後用於打破平局。
- 複合別名是有用的上下文，但往往是糟糕的字面搜尋字串。將它們拆分為別名，同時保留群組身份。
- 硬直接接受邏輯是脆弱的。它可能因為一個別名匹配而抓取通用的重複項。
- 硬身份閘門是脆弱的。當名稱稀疏、翻譯、羅馬化、重新品牌或僅有舞台名時，它們可能隱藏正確的記錄。
- 涵蓋數量不等於正確性。如果一個選定的記錄是錯誤的人或組織，找到 6 個實體中的 6 個不是成功。
- 全域查詢去重可能使後續實體缺乏結果。常見別名應按實體群組追蹤。
- 來源不穩定性是結果的一部分。逾時、403、404、重試與部分資料應在來源或除錯日誌中呈現。
- 重新排序器無法修復缺失的候選項目。如果一個目標分支沒有候選項目，在重新排序之前插入檢索規劃或修補，而不是期望重新排序器推斷隱藏的記錄。
- 指令文字可能污染字面搜尋。從查詢字串中剝離任務短語，同時保留它們作為擴展與重新排序的上下文。
- 快速的直接結果可能壓制更廣泛的擴展。僅在具有高確定性時信任直接 ID 與 Slug；否則，繼續擴展與搜尋以確保涵蓋範圍。