スマートエンティティ解決

信頼できる回答が得られる最小限の労力で同一性を解決します。既存の識別子、マッピング、または裏付けとなる証拠が不十分な場合にのみ、解決レベルを上げます。このスキルは、真に曖昧な個人や組織のレコード（競合するプロフィールやメディア候補を含む）に適用されます。通常の画像処理や決定論的なID結合には必要ありません。

基本原則

エンティティ解決はルックアップではなく、段階的な調査として扱います。完全一致検索、スラッグルックアップ、人気、LLMの判断はすべて有用なシグナルですが、いずれも暗黙的に他のシグナルを支配してはなりません。

次の3つの質問を分離します：

網羅性 (Coverage): 要求されたすべてのエンティティを列挙しましたか？
同一性 (Identity): この候補は要求された人物または組織を表していますか？
有用性 (Utility): これはタスクに最適な使用可能なレコードですか？

同一性の証拠が弱いのに有用性が高いレコードは、偽陽性のリスクがあります。同一性は、人気、プロフィールの充実度、画像の有無、検索ランキングよりも優先されます。

解決レベル

最も低い十分なレベルを選択してください。高いレベルが必須の前提条件というわけではありません。

レベル0 — 直接識別: 信頼できる安定したID、正規URL、または検証済みアカウント識別子と一致させる。タスクが解決した時点で停止します。
レベル1 — 決定論的調整: 明示的なクロスウォーク、レビュー済みの別名、文書化されたソース固有のID、または検証済みの同一性リンクを使用する。マッピングを発明してはなりません。
レベル2 — 文脈的識別: イベント、セッション、時間的に適切な所属、個人プロフィール、プロジェクト所有権、または独立して検証されたソース識別子を使用して名前を裏付ける。候補や証拠が矛盾する場合はレベルを上げます。
レベル3A — 公式プロフィール発見: 自己管理型のウェブサイトやソーシャルアカウント、公式スピーカーページ、雇用者ディレクトリ、プロジェクトや著者のプロフィールを見つける。別の信頼できるソースからリンクされているプロフィールを優先します。
レベル3B — 独立した裏付け: 識別子、別名、イベント、プロジェクト、所属、日付を独立したソース間で比較する。同一の経歴のコピーを複数のソースで見つけても、別々の確認としてはカウントしません。
レベル3C — 別名と履歴の調整: 芸名、スペルバリアント、翻字、過去の雇用主、買収、イベント間の登場を、明示的なマッピングまたは独立した裏付けを使用して解決する。所属は時間的にスコープを限定します。
レベル3D — 候補の復旧: 別名や文脈化された名前を検索し、直接ID、URL、スラッグを調査し、通常の検索で見つからない場合にのみ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は画像の再配布やトレーニングの権利を付与しません。
一般検索: 候補の発見や事実の裏付けにはウェブ検索結果を使用します。検索ランキングを証拠として扱ってはなりません。

推測されたサムネイル、近くのセッションの写真、顔の類似性、または生体認証の埋め込みを、検証済みの同一性証拠として扱ってはなりません。

ワークフロー

検索前にクエリを分類します。単一エンティティか、エンティティのリストか、または曖昧なグループ/キャスト/メンバー/チーム/組織のクエリかを検出します。「メンバー」「キャスト」「ラインナップ」「チーム」「会社」「子会社」「リーダーシップ」などの用語は、通常、拡張が必要であることを意味します。
ルックアップの前に、指示のようなクエリを解析します。ユーザーはエンティティのヒントを、「...の完全なプロフィールを見つけて」「...を含むグループを推測して」「これらの部分的な名前を解決して」などのタスクテキストでラップすることがよくあります。エンティティヒント領域を抽出し、元の指示をコンテキストとして保持し、指示文字列全体をリテラルなデータベースクエリとして送信しないでください。
直接識別または文書化されたマッピングが不十分な場合にのみ、曖昧なクエリをエンティティグループに拡張します。個人や組織を列挙するために本当に必要な場合にのみ、LLMまたは検索ツールを使用します。別名は1つのエンティティの下にグループ化します。
エンティティグループごとに幅広く検索します。各エンティティについて、複数の別名、クリーニングされたバリアント、ターゲットデータベースがサポートしている場合は正確なスラッグや直接ID候補、およびコンテキスト化された短い名前のクエリ（<group> <short name>など）を検索します。エンティティごとにローカルなクエリ追跡を使用します。グローバルなクエリ重複排除は、後のエンティティで共通の別名が不足する原因になり得ます。
決定論的検索が空または弱い場合、LLMによる検索プランナーを検討します。プランニングは再ランキングとは別です。直接ID、URLスラッグ、完全名プローブ、別名、文脈検索を要求します。プローブは範囲を限定し、高精度に保ちます。
安定したレコードの同一性によって候補をマージします。プロフィールID、スラッグ、正規URL、データベースID、または別の安定したキーで重複排除します。最高スコアのパスのみを保持するのではなく、候補を見つけたすべてのクエリとソースを保持します。
再ランキングの前に候補をエンリッチします。同一性、出典、有用性、曖昧性、確信度にわたって概念的な証拠を収集します。再ランカーに名前だけで選択させることは決してあってはなりません。
真に競合する候補に対してのみ、範囲を限定したLLM再ランキングを使用します。別のパスで網羅性を実質的に改善できるか、可能性のある同一性を区別できる場合にのみ続行します。
決定を変更したり修正を可能にしたりする可能性がある場合、意味のある代替案を示します。権威ある正確なIDマッチには、作り物の次点候補は必要ありません。
未解決および不確実を第一級の結果として扱います。静かに高有用性の偽陽性を埋めるよりも、needs review、no plausible match、またはambiguousを優先します。

部分的な名前と曖昧な指示

クエリに主にファーストネーム、短い別名、イニシャル、部分的な組織名が含まれている場合、生のデータベースヒットを十分なものとして扱わないでください。グループ化用語、完全プロフィールの意図、またはほとんどが1トークンの名前で直接結果が信頼できない場合に、拡張または分類します。

クエリの2つの表現を保持します：

originalQuery: 完全なユーザー指示とコンテキスト。
entityHints: 解決する候補名または別名の抽出されたリスト。

拡張モデルは両方を見る必要があります。推定される共有コンテキストを推論し、グループ化された別名を持つ具体的なエンティティを返すように要求します。拡張されたエンティティごとに、ラベルと別名を保存し、そのエンティティブランチ内でそれらの別名を検索します。単純な正確な名前に対しては直接検索パスを依然として実行できますが、部分的なヒントから完全な同一性を推論することに網羅性が依存する場合、拡張を抑制してはなりません。

網羅性は結果の量とは別です。5つの要求されたヒントが多くの生の候補を生成したとしても、各ヒントが選択されたエンティティまたは明示的な未解決/曖昧な結果にマッピングされるまでは解決されません。expectedCount、resolvedCount、ambiguousCount、unresolvedHintsまたは同等のフィールドを追跡します。

検索計画とギャップ修復

再ランカーが、検索が決して返さなかったレコードを救うことに依存しないでください。LLMの関与を別々の役割に分割します：

拡張モデル: 「ターゲットエンティティは誰、または何ですか？」
検索プランナーまたは修復モデル: 「このターゲットに対して、リトリーバーが試すべき正確なID、スラッグ、直接URL、別名、検索プローブは何ですか？」
再ランカーモデル: 「これらのエンリッチされた候補を考慮すると、どれが正しいレコードですか？」

直接スラッグやIDが欠落しているレコードを復旧できる可能性がある場合、またはエンティティに候補がなく、使用可能なデータがなく、弱い/一般的な名前のマッチのみがある場合にのみ、検索計画を使用します。プランナーに、元のクエリ、グループ化された別名、試行されたプローブ、ソースの失敗、関連するソースの制約を与えます。プランナーはプローブを返すべきであり、同一性の決定を返すべきではありません。

修復は範囲を制限し、釣り合いを保ちます。有用なプローブに対して決定論的検索を実行し、復旧した候補をマージし、追加の検索が答えを変える可能性が低い場合はエンティティを未解決としてマークします。

ロギングとファンアウト

タスクに比例して、ソースの出典、選択されたID、曖昧性、網羅性を記録します。生のプライベートペイロードは避けます。独立したエンティティグループがすでに同時に処理されている場合、ブランチの状態を分離して維持し、決定論的にマージします。このスキルを満たすためだけに、ファンアウト、テレメトリーインフラストラクチャ、またはリトライを導入しないでください。

証拠モデル

証拠は概念的で移植可能に保ちます。1つのサイトのフィールドに過剰適合しないでください。

同一性の証拠: 完全名またはIDの一致、別名、芸名、実名、ローマ字化バリアント、共有トークン、欠落している主要トークン、コンテキストの一致、既知の組織/グループ関係、矛盾する名前。
出典の証拠: どのクエリが候補を見つけたか、検索、正確なスラッグ、直接URL、データベースID、APIルックアップ、ウェブ結果、ユーザー提供ソース、検索プランナープローブ、または復旧パスのいずれから来たか。
有用性の証拠: 画像数、プロフィールの充実度、アクティビティ、人気、閲覧数、投票数、リスト数、従業員数、関係数、認証ステータス、最近の更新、レコードがタスクに使用可能なメディアやメタデータを持っているかどうか。
曖昧性の証拠: 短い/一般的な名前、姓のみのマッチ、イニシャル、重複レコード、グループ/プロジェクトページ、「and the」ページ、まばらなレコード、矛盾する別名、古い名前、統合された組織、子会社、または類似した名前の公人。
確信度の証拠: 選択された候補、次点候補、再ランカーの理由、未解決ステータス、人間レビューフラグ、元のクエリの網羅性ステータス。

再ランキングルール

真の曖昧性がそれを正当化する場合、ソースの証拠とタスクに適切な予算によって制約されて、LLM再ランキングを使用します。

再ランカーに、元のクエリ、解決されたエンティティラベル、別名、候補の名前/ID/URL、出典、同一性の証拠、有用性の証拠、曖昧性の警告を与えます。
同一性を有用性よりも優先するように指示します。同一性の証拠が弱い場合、画像が豊富または人気のある候補を選択してはなりません。
同一である可能性が高い候補については、有用性を決定させます。公的な芸名やブランド名のレコードは、タスクに関連するより強力な証拠がある場合、実名のレコードよりも優れていることがあります。
1トークンの別名は、コンテキスト、正確なID/スラッグ、より豊富な別名の重複、または強力な外部証拠によってサポートされない限り、曖昧として扱います。
ハードな受け入れルールを避けます。直接の別名ヒットはシグナルであり、証明ではありません。
ハードな拒否ルールを避けます。ローマ字化、リブランド、まばら、または芸名のレコードは不完全に見えるかもしれませんが、正しい場合があります。
同等にサポートされている候補が実質的に優れたタスク有用性を持っている場合、それを公開するか、同一性の証拠を静かに上書きするのではなく、正当化された追加の比較を1回実行します。
選択された候補の理由をログまたは表示し、代替案を表示可能に保ちます。

障害モード

これらを、リゾルバーが「ほとんど機能する」が、何かおかしいと感じる場合のレビューチェックとして使用します。

正確なデータベース検索は実際のレコードを見逃す可能性があります。利用可能な場合は、正確なスラッグ、直接URL、ID、または代替エンドポイントをプローブします。
短い名前は偽陽性を生み出します。「Lisa」「Rose」「Sunny」「Tiffany」「Yuri」および同様の1トークン名には、コンテキスト検索と曖昧性の警告が必要です。
実名は有用性の低いレコードになる可能性があります。公的な芸名やブランド名の方が、より充実したプロフィール、より多くの画像、またはより最新のメタデータを持っている場合があります。
有用性シグナルは強力ですが、単独では安全ではありません。カウント、投票、閲覧数、人気は、同一性の可能性の後にのみ同点を破るべきです。
複合別名は有用なコンテキストですが、多くの場合、リテラル検索文字列としては不十分です。グループの同一性を保持しながら、別名に分割します。
ハードな直接受け入れロジックはもろいです。別名の1つが一致したという理由だけで、一般的な重複を取得する可能性があります。
ハードな同一性ゲートももろいです。名前がまばら、翻訳、ローマ字化、リブランド、または芸名のみである場合、正しいレコードを隠す可能性があります。
網羅性のカウントは正確性ではありません。6つのエンティティ中6つを見つけることは、選択された1つのレコードが間違った人物または組織である場合、成功ではありません。
グローバルなクエリ重複排除は後のエンティティを飢えさせる可能性があります。共通の別名はエンティティグループごとに追跡する必要があります。
ソースの不安定性は結果の一部です。タイムアウト、403、404、リトライ、部分データは、出典またはデバッグログで表面化されるべきです。
再ランカーは欠落している候補を修正できません。ターゲットブランチに候補がゼロの場合、再ランキングの前に検索計画または修復を挿入します。再ランカーが隠れたレコードを推論することを期待しないでください。
指示テキストはリテラル検索を汚染する可能性があります。ルックアップクエリからタスクフレーズを取り除き、拡張と再ランキングのコンテキストとしてそれらを保持します。
高速な直接結果は拡張を抑制する可能性があります。名前が短い、エンティティが複数ある、またはタスクテキストがグループ/チーム/メンバーシップを含む場合、最初のヒットで停止せず、拡張を確認します。
未解決または曖昧な結果は見逃されやすいです。特にグローバルなスコアリングがそれらを埋める場合、それらを無視したり、マスクしたりしないでください。

スマートエンティティ解決（swyxio/skills）

skills）とは？

お気に入りのAIに質問する

ドキュメント