スコアを検証可能な判断に変える。

要約する前に出力を保存する

分析は、入力・参照・予測の突き合わせから始まります。期待される各識別子がちょうど一度だけ現れることを確認してください。誤った回答と、未完了のリクエスト、重複、判読不能な出力を区別してください。これらの問題は対処法が異なり、平均値の計算で見えなくなってはいけません。

生の出力を、正規化したバージョン、モデルのリビジョン、プロンプト、設定、判定理由と並べて保存します。曖昧な日付を無言で変換すると、見かけ上の成功を生む可能性があります。探索は検証セットから始めます。最終テストが次の修正を考案するために使われるなら、別に保管した新たな確認が必要になります。

技術的な出典: scikit-learn 1.9 — モデルの選択からテストを切り離す

混同行列を件数とともに読む

エントリごとに1カテゴリを分類する場合、マトリクスは参照クラスと予測クラスを交差させます。ここで使用する慣例およびscikit-learnでは、行が参照を、列が予測を表します。正規化する前に生の件数を保持してください。サンプル数なしのパーセンテージは、結論の堅牢性を誇張する可能性があります。

次の例は架空のもので、純粋に算術的なものです。100件のチケットが「請求書」「アクセス」「削除」に振り分けられています。対角線上には54 + 24 + 5 = 83件の正解、つまり83%が含まれています。この合計は「削除」クラスを覆い隠しています。期待される10件のチケットのうち、認識されたのはわずか5件です。これらの数値を生成したモデルやGPUは存在しません。

技術的な出典: scikit-learn 1.9 — 混同行列の定義

適合率、再現率、実務上の結果を結び付ける

Suppression の場合、適合率は 5/8 = 62.5% です。このカテゴリに送られたチケットのうち、5件が正しいものです。再現率は 5/10 = 50% です。このカテゴリのチケットの半数が正しく検出されています。F1 は 2 × 5 / (2 × 5 + 3 + 5) で、約 55.56% です。3件の偽陽性と5件の偽陰性は、それぞれ異なる問題を表しています。

請求、アクセス、削除の各クラスのF1は、それぞれ88,52 %、80 %、55,56 %です。これらの重み付けなしの平均、マクロF1は約74,69 %です。これは83 %の正解率を補完するものであり、件数に代わるものではありません。あるクラスが参照または予測に存在しない場合、一部の指標が未定義になることがあります。そのケースを平均に隠すのではなく、使用した慣例を明示してください。

技術的な出典: scikit-learn 1.9 — 適合率、再現率、F1、平均、ゼロ除算

アクションに結び付いた短い分類体系を構築する

エラーのカテゴリは、何を調べるべきかを判断する助けになるべきです。まずはいくつかのカテゴリと、定義、代表的な例から始めましょう。二重計上せずに件数を数えるための主ラベルを追加し、複数の現象が併存する場合は副ラベルを追加します。説明を無理に当てはめるのではなく、「要確認」のカテゴリを残しておきましょう。

この分類体系は作業上の提案であり、自動診断ではありません。切り詰められた文書にも、参照の曖昧さが含まれている可能性があります。ラベルの頻度が示すのは再確認した件数であり、まだ原因を証明するものではありません。解釈を裏付ける入力箇所を保存し、観察された原因、仮説、欠落している情報を区別しましょう。

抽出では、フィールドと文書を数える

有効なJSON形式であっても、値が正しいことは保証されません。許可する正規化を定めましょう。正規の日付、小数点記号、空白、カテゴリコードなどです。フィールドの欠落、でっち上げた値、許可された棄権を区別します。文書に存在しない値を、充足率を上げるために推測で置き換えてはなりません。

次に、分類表とは独立したもう一つの例示的な計算を示します。50件のドキュメントにそれぞれ3つの必須フィールドがあり、合計150個の値があるとします。38件が完全に正しく、6件が2フィールド正しく、6件が1フィールドのみ正しいと仮定します。これにより、38 × 3 + 6 × 2 + 6 × 1 = 132個の正しい値、つまり88%となります。しかし、3つのフィールドすべてが必須であれば、完全に許容できるドキュメントはわずか38/50 = 76%です。

18件の誤った値が12件のドキュメントに影響しています。これを18件のドキュメントが不合格だったと表現しないでください。慣例に従えば、有用な単位は検証済みのフィールドか、承認されたドキュメント全体のいずれかになります。比較の前にどちらを使うか定義してください。フィールド単位の結果を保持しておけば、困難が日付から来るのか、金額から来るのか、カテゴリから来るのかがわかります。

キャンペーンを再実行する前に修正を選ぶ

優先順位は、行数だけでなく、影響の大きさと範囲に基づいてつけてください。架空のマトリクスでは、プロジェクトがこのカテゴリを重要と定義していれば、Facture の6件のエラーより Suppression の5件のエラーの方が先にレビューする価値があるかもしれません。この優先順位はプロジェクトの契約に属するもので、表からビジネス上の重大度を勝手に決めることはできません。

検証可能な仮説を立てましょう。「長い入力は準備の段階で決定的な箇所を失う」。それを調べられる変更を1つ選び、それ以外は一定に保ちます。同時に例を追加し、モデルを変更し、コンテキストを増やせばスコアは上がるかもしれませんが、その効果を1つの修正に帰属させることはできなくなります。

• エラーに加えて成功例もいくつか再確認し、基準が一貫して適用されているか確かめましょう。
• 同じ識別子と参照でバリアントを比較し、コーパスの変更は別途報告しましょう。
• 修正されたエラー、残存するエラー、新たなエラー、変化のないケースを区別しましょう。
• 対象カテゴリ外の例も再実行し、リグレッションを探しましょう。

リグレッションを消さずに改善幅を確認する

対応のある計算は、正味のスコアが隠してしまうものを示します。100件の架空のチケットで、9件のエラーが修正された一方、以前の成功4件が誤りになったと想像しましょう。集計は83から83 + 9 − 4 = 88の正解へと変わります。改善幅は5ポイントで、4件のリグレッションを検討する必要があります。これは9件の修正が代償なしに得られたことを意味するものではありません。

決定メモには、前後の表、修正されたケース、新たに生じた誤り、修正版のバージョン、および合格した基準を残します。重要なルールが依然として違反されている場合、平均値が高くてもそのバリアントを採用する根拠にはなりません。コストと所要時間は、その後、許容可能な選択肢間で比較します。不合格となった結果を高速化しても、品質の問題は解決しません。

結論は検討した範囲に限定する

目立つ誤りが必ずしも代表的とは限りません。長い入力やまれなカテゴリの失敗を重点的に見直す場合は、その選択方法を明記し、その頻度をコーパス全体の頻度として提示しないでください。また、判定が確定していないケースも残しておきます。それらは評価における不確実性を定義します。

あなたの分析は、別の読者がその入力を特定し、判定を理解し、提案された修正を検証できるものであれば活用できます。ただし、生成された回答の内部的な原因や、将来の品質を保証するものではありません。修正を選択した後、最終的なホールドアウトセットに進み、その限界を結論とともに記録します。

実用的な質問