レバレジーズ株式会社の技術ブログ

全141件

2026/08/17

「評価するAIを、評価する」― 就業型インターンでLLM as a judge に挑んだ9日間

はじめに「AIがちゃんと仕事をしているか」を、そもそも測る手段がありませんでしたレバレジーズが運営する「レバテック」は、ITエンジニアやクリエイター向けの転職・フリーランス支援サービスです。レバテックブランドの一部である「レバテックキャリア」では、キャリアアドバイザー（CA）が求職者の方と面談し、その内容をもとに求人や案件を提案しています。このレバテックキャリアでは、CAと求職者の方のやり取りが記載されたテキストデータからLLMを使って求職者の技術スキルを自動で抽出し、求人のレコメンドに試験的に活用しています。人が自由に書いた文章を、機械が扱えるデータに変える仕組みです。この仕組み自体はすでに動いていました。一方で、「抜き出したスキルが本当に合っているのか」を自動でチェックする仕組みは、これから実装するところでした。 3週間（実働9日間）の就業型インターンで私が取り組んだのは、この抽出結果を自動で採点する評価の仕組み—— LLM as a judge をゼロからつくることです。さらに、つくった評価の仕組みそのものが信用できるのかを検証し、プロンプトを改善して採点の精度を高めていきました。はじめまして。早稲田大学基幹理工学研究科情報理工・情報通信専攻修士1年のASと申します。大学院では、脳波や心拍といった生体情報から人の「興味」を推定する研究に取り組んでいます。人の関心をデータから捉えるという点で、今回扱った「推薦」や「その評価」とも通じるテーマかもしれません。趣味は旅行・テニス・スキー・お笑い、そしてAIを触ることも好きなことの一つです。この記事では、9日間で何を考え、どこでつまずいたのかを、できるだけそのまま書いてみます。背景: 非構造化データを「使える形」にした、その先にある課題もう少し詳しく仕組みを説明します。CAと求職者のやり取りを記載したテキストデータから、LLMで技術スキルを抽出する。抽出されたスキルは、対応するスキルのマスタデータに名寄せされた上で、特徴量としてデータベースに保存され、レコメンドの精度向上に使われています。図1: テキストデータから特徴量ができるまでこれは、これまで人の目でしか読めなかった非構造化データを、機械が扱える形に変換する取り組みです。インターンでは、この周辺システムの暫定版のリリース作業も担当させていただきました。学生の立場で本番環境に乗せるところまで経験できたのは、大きな財産です。一方で、抽出結果を眺めていくと、気になる出力も見つかりました。同じスキルを延々と繰り返す「ループによる異常抽出」や、数十文字の短いテキストから大量のスキルを吐き出す「短文への過剰出力」です。こうした出力を人の目だけで拾い続けるのには限界があります。非構造化データを構造化できたことがゴールではなく、その変換品質を測り続けられて初めて、安心して運用に乗せられる。ここが今回のスタート地点でした。まず現状を疑う: 実データ分析でわかった3つの事実いきなり評価システムを作りたくなる気持ちを抑えて、最初の数日は実データと向き合いました。設計の前に、現場で語られている前提が本当に正しいかを自分の手で確かめたかったからです。実際、当時のメモには「"1人あたりのスキルは1〜5件がほとんど"って、本当にそう？」などと書き殴っていました笑。全件を集計した結果、3つの事実が見えてきました。 ① 入力の性質が、極端に二極化していたテキストデータの文字数は平均775文字に対し、中央値は146文字。500文字以下の短文と1,000文字以上の長文にくっきり分かれ、中間がほとんどありません。原因は、テンプレートを使って書かれたテキスト（全体の約25%・平均2,709文字）と、使わずに書かれたテキスト（約75%・平均139文字）の混在でした。性質の異なる入力が同居していることは、評価の設計を考えるうえで前提として押さえておく必要があります。図2: テキストデータの文字数は「短文」と「長文」に二極化していた ② 異常出力は、統計的にはっきり検出できた 1人あたりの抽出スキル数は平均5.4個。95%が16個以下、99%が39個以下に収まる一方、最大では676個というデータが存在しました。そもそも676個という出力は名寄せ対象のマスタデータの件数を超えており、その時点で明らかにおかしいと判断できます。 ③ マスタとの整合が、半分しか取れていなかった抽出結果のうちマスタに合致したのは45.3%で、残る54.7%はマスタ外。原因は表記ゆれ・英語表記・資格名の部分不全などです。抽出そのものはできていても、そのままではマスタと突き合わせられないデータが半数以上あるという状態でした。余談ですが、オフィスでの時間そのものが刺激的でした。作業していると、近くで進んでいるミーティングの話し声が自然と耳に入ってきます。AIエージェントの設計の話だったり、出たばかりのAIモデルをどう使うかという話だったり。手を動かしながらそういう会話が聞こえてくる環境は、学生の自分にとってかなり贅沢な時間でした。設計: なぜ「2層構造」にしたのか分析を踏まえ、評価パイプラインは 2層構造に落ち着きました。狙いは、計算コストと検知精度の両立です。図3: 評価パイプラインの2層構造第一層は、プログラムによる決定論的な形式監査です。 LLMを使わず、機械的に落とせるものを落とします。JSONの構造チェックに加え、「出力スキル数が上限を超えたら0点」という足切りを設けました。上限の設定は悩みどころで、統計上は99%が39個以下に収まります。しかし39個ちょうどでは目視でまだ異常が残る一方、ごく稀にいる"超優秀層"の正常データまで切り捨てたくない。機会損失を防ぐため、安全を取って上限は50件としました（51件以上は全体のわずか0.86%です）。ここでNGなら、コストの高いLLM評価に回さず即終了します。第二層は、LLMによる意味監査です。第一層を通過したデータについて、評価用LLMがテキストデータの原文と抽出結果を突き合わせ、文脈から抽出の過不足を判定します。つまりここでやっているのは、 LLMの出力を、別のLLMに採点させるということです（これが「LLM as a judge」と呼ばれる手法です）。「未経験と書かれているのに拾ってしまった」といった文脈の読み違いは、決まったルールでは判定しきれません。同じく言葉の意味を扱えるモデルに任せるのが現実的でした。 4分類は、見た目以上に悩んだ判定にあたっては、スキル1件ごとにエラーを4種類へ分類する決定木を設計しました。エラー種別原点設定理由マスタ外 -15点 DB連携が不可能になる致命的エラー過剰（無根拠） -10点原文に根拠がないハルシネーション過剰（文脈誤認） -8点「未経験」などの文脈の読み飛ばし不足 -5点網羅性は下がるがリカバリ可能並べてしまえば単純な4分類ですが、ここに至るまでがいちばん頭を使ったところでした。分類の切り口も粒度も、選択肢は無数にあります。細かく分ければ分析はしやすくなる一方、判定はブレやすくなる。粗くまとめれば安定はしますが、改善のヒントが得られません。意識したのは、説明可能であることと、論理的にMECEであることの2点でした。最終的には「まずマスタに存在するか」で切り、存在するものについて「不足か・過剰か・正常か」を判定し、過剰をさらに「原文に根拠がない（無根拠）」と「原文の文脈を読み違えた（文脈誤認）」に分ける、という決定木に落ち着きました。この構造なら、どのエラーがどこに分類されるかを人に説明できますし、原因の切り分けにも直結します。図4: 抽出されたスキル1件ごとに、エラーを4種類へ分類する決定木減点の幅は、業務影響度（システムへの実害の大きさ）に応じてグラデーションをつけました。ここで効いてきたのが、先ほどの実データ分析です。 1人あたりの平均スキル数は約5個しかないため、1件あたりの減点を大きくしすぎると、数件の誤りですぐ0点に張り付いてしまい、精度の"差"が測れなくなります。マスタ外を−15点、不足を−5点としたのは、影響度の順序を保ちつつ、スコアが飽和しない幅に収めるためでした。「まず単純な形で動かす」という判断じつは当初、もっと複雑な指標を構想していました。減点方式そのものに弱点があるからです。スキル数が多い人ほど減点される機会が増えて不利になり、逆にスキル数が少ない人の1件の間違いは、相対的に軽く扱われてしまう。これを補正するために、1件の誤りが重く効くF1スコアと掛け合わせた合成指標を組み立てられないか、と考えていました。しかし現場の社員の方に相談したところ、返ってきたのは「いきなり複雑にする必要はない」という助言でした。まず単純な形で動かし、必要になったら足していく。実際、F1スコアの算出には「完全に正しい正解データ」を大量に用意する必要があり、正解づくり自体が難しい今回のケースでは、そこで手が止まってしまう可能性も高いものでした。結果として「まずは自前の減点スコアで、素直に差分を見られる形から始める」と割り切りました。この判断は、9日間で得た学びの中でもかなり大きいものでした。設計として"正しそう"なものと、限られた時間の中で"前に進むもの"は、必ずしも一致しない。「なぜこの配点なのか」を自分の言葉で説明できる状態を保ちながら、まず動かすことを優先しました。評価者は、正しく評価できているのかここも大きな山場でした。評価基盤を作っても、その評価者であるLLMが信用できなければ意味がありません。そこで用いたのが、答えを先に仕込んでおくという手法です。たとえば「正解率80%になるよう意図的に崩したデータ」を評価者にかけ、本当に80%前後を返してくるかを見る。返ってくれば、その評価者はある程度信用できると判断できます。実際、100%・80%・20%相当に作ったデータに対し、評価スコアは100%・83%・21%と狙いに近い挙動を示しました。この考え方を土台に、ゴールデンデータ100件を用意しました。内訳は、実データから目視で正解を定義したもの25件と、文字数の偏りやマスタ表記のばらつきといった実データの特徴を踏まえて作成した合成データ75件です。プロンプト改善で、評価の誤りは102件から67件へあとは、ひたすら試行錯誤です。ゴールデンデータ100件に対して評価LLMを走らせ、正解との食い違いを数え、プロンプトを書き換えてはまた回す。文言レベルの調整を何度も繰り返し、その中から方針として大きく異なる3つのバージョンを比較しました。結果、食い違いの総数は 102件 → 75件 → 67件と着実に減っていきました。図5: 3回の試行で、評価の誤りは102件から67件へここで数えている「エラー」は、抽出LLMのミスではなく、評価者であるLLMが正解と違う判定をしてしまった件数です。そもそも評価の仕組みがなかったので、この102件という数字自体、物差しを作って初めて見えるようになったものでした。正解スコアとの差分（Delta Score）の分布も、試行を重ねるごとに「差ゼロ＝完全一致」の山が高くなり、評価が正解に寄っていく様子が数字で見えたときは素直に嬉しかったです。図6: プロンプト改善で、評価が「正解との一致」に寄っていった一方で、すべてがうまくいったわけではありません。内訳を見ると、文脈誤認（19→0→2件）や無根拠の過剰抽出（11→1→5件）は大きく改善したのに、「取りこぼし（不足）」だけは69→71→57件となかなか減らない。ここは最後まで残った宿題です。学びと今後技術面での最大の学びは、「LLMを評価すること」は「LLMを使うこと」と同じくらい難しいという実感でした。正解の定義、評価者の妥当性検証、指標選び——そのどれもが、決まった正解のない設計判断の連続です。そしてそれ以上に大きかったのが、「なぜその数字なのか」を説明できることの重要性です。「閾値が妥当かどうかは、最後は現場の肌感でしか判断できないドメインもある」ということも学びました。数字を出して終わりではなく、その理由を言葉にして初めて他の人と議論できる。当たり前のようで、実務の現場で強く実感したことでした。やり残した課題も明確です。プロンプトのさらなる改善（トークン効率、長文・短文を分けた処理）、評価対象である抽出プロンプトやマスタデータそのものの改善、そして評価基盤をダッシュボードとして常時監視できる形につなげること。ここから先は、ぜひ挑戦してみたい領域です。おわりに非構造化データを構造化できたことはゴールではなく、その品質を測り続けられて初めて運用に乗る。これが9日間で得たいちばんの結論です。 LLMをプロダクトに組み込む事例が増えるほど、「その出力が正しいかをどう測るか」という問題は必ずついて回ります。LLM as a judge という手法に、実際のプロダクトのデータを使って取り組めたことは、とても良い経験になりました。モデルを作って終わりではなく、運用しながら品質を測り続ける——いわゆるLLMOpsの入口にあたる部分を、実務として体験できたのも大きな収穫です。チームの雰囲気も印象的でした。方針に迷って相談すると、一緒に考えたうえで「まずは単純な形から始めてみよう」と具体的な指針をもらえる。学生の自分に対しても、判断の理由まで含めて丁寧に議論してもらえたことが、最もありがたく感じた点でした。ランチにもよく連れて行っていただきました。毎日違う社員さん4人ほどと、渋谷のいろいろなお店へ。中でも釜飯のお店は強く印象に残っています笑。日替わりでいろいろな方とお話しできたので、単純に楽しかったですし、キャリアの選び方や仕事の進め方についても興味深い話をたくさん聞けました。短い期間でしたが、"答えのない問題"に現場の方と一緒に向き合えたことは、大きな財産です。

キャリア, データ分析, 人工知能, データベース, 設計, 統計, 大規模言語モデル（LLM）, 学生

レバレジーズ 株式会社 の技術ブログ

コンテンツ

レバレジーズ株式会社の技術ブログ