スコアの組み合わせ

複雑な判断をアトミックなスコアに分解し、完全に制御可能な重みでコード内で結合します。

本文はzh-CNからの機械翻訳です。校正は未実施で、参考情報としてのみご利用ください。

このパターンが解決する問題

私たちはしばしば、複数の次元に基づいて一連の項目を同時にソートする必要があります。「総合スコア」を単一の質問として直接出力させると、非常に望ましくない結果になります。モデルが出力するスコアは説明不可能であり、なぜそのような順序になったのかを理解することができません。

コンポジット・スコアリング（複合スコアリング）のアプローチでは、判断を独立した次元に分解し、それぞれを個別にスコアリングしてから、コード内であなたが完全に制御できる重みを用いてそれらを統合します。

例：履歴書フィルタリング

エンジニアリング職の履歴書を処理しており、複数の基準に基づいて候補者をソートし、最終的に上位 X 名を次のラウンドに進めたいとします。

ステップ 1: 各次元を独立してスコアリング

1回の呼び出しで、4つの Score（python_depth、team_leadership、system_design、generalist）を問いかけ、各次元に独自のグレード定義を用いてスコアリングします。

ステップ 2: 重みを用いて統合

py      = response.answers["python_depth"].score / 4
lead    = response.answers["team_leadership"].score / 4
arch    = response.answers["system_design"].score / 4
general = response.answers["generalist"].score / 4

# Senior IC（シニア個人貢献者）
ic_score = (0.40 * py) + (0.10 * lead) + (0.40 * arch) + (0.10 * general)

# Engineering Manager（エンジニアリングマネージャー）
em_score = (0.15 * py) + (0.40 * lead) + (0.20 * arch) + (0.25 * general)

各次元はまず 0–1 の範囲に正規化され、その後重み付けされます。

このパターンの真の価値

重み付けによるソート結果の取得は表面的な利点に過ぎません。真の価値は説明可能性にあります。

上記の2つの異なる役割で同じ一連のスコアを用いながら異なる重みを適用している点に注目してください。これは以下を意味します。

1回の呼び出しで2つの採用方向を同時に処理できるため、コストが2倍になりません。
排名結果が期待通りにいかない場合、プロンプトを再調整する必要はなく、重みだけを直接調整できます。
「なぜこの候補者が1位なのか」という疑問に対して、各次元のスコア分布と重みを示して説明できます。

各次元の詳細は失われません。 Python の実力が強くチームリーダーシップが弱い候補者が、IC 役職では上位に、EM 役職では下位にランク付けされるという差異は、モデルが再判断したのではなく、重みによってエンコードされたものです。

ブレークポイントでのデバッグ

重みにはもう一つ実用的な利点があります。単一次元でソートすることで異常を調査できる点です。 総合的なランキングがおかしい場合、まず python_depth だけでソートし、直感と一致するかどうかを確認します。一致しない場合、問題は重みではなく、その次元のグレード定義にあります。この分解性は、「1つの大きな問題をモデルに直接質問する」ことでは達成できません。

ある次元の識別度が不十分である（全員が同じグレードに集中している）ことが判明した場合、重みを調整するのではなく、グレード定義を再作成する必要があります。

信頼度との連携

各次元の Score には confidence が伴います。信頼度が低い次元は、以下のいずれかを示すシグナルです。つまり、グレード定義に曖昧さがあるか、state に判断に必要な情報が不足しているかです。

実用的な手法として、高重み次元の信頼度が閾値を下回る場合、その候補者を「人間のレビューが必要」としてマークし、信頼性の低いスコアがランキングを支配させないようにします。

デザイン上のポイント

次元は直交（独立）していなければなりません。 2つの次元が強く相関している場合（例：「Python の深さ」と「プログラミング能力」）、重み付けによって同じ事柄が重複して計算されてしまいます。次元を設計する際には、自問してください。「この次元は独立して変化できるか？」

重みの合計を 1 に正規化する。 理解と調整が容易になります。

正規化してから重み付けする。 異なる次元のグレード数は通常異なるため、正規化しないと、グレード数が多い次元が不均衡な影響を持つことになります。

重みはビジネス上の判断であり、技術的な判断ではありません。 IC 役職と EM 役職の重みの違いを決定するのは誰でしょうか？それはエンジニアではなく、採用を依頼する側（ビジネスサイド）です。重みは設定可能な項目として実装してください。