
2025.02.06
ポンコツ期、孤独期、成果独り占め期を経て… サイボウズのプロマネが振り返る、マネージャーの成長の「4フェーズ」
リンクをコピー
記事をブックマーク
中村龍矢氏:では具体的に、精度評価と改善にいければと思います。
まず精度評価というと、パッとイメージしやすいのが、「どういうスコアをやるか」というところで。これは最近はツールもノウハウもいろいろ出ているので、あまり悩むことはないんじゃないかなと思っています。LLMが吐いた答えが正しいかどうかを判定する方法ですね。
一番シンプルなのは、完全一致というかたちです。人間はこれを出してくれる。LLMはこれを出す。それが完全に一致するかどうかというやつですが、これをやるとあまりにも厳しすぎて。
例えば、数字や金額を出力する時に、カンマがあるかないかみたいなフォーマットの違いすらもバツになってしまったりするので、このあたりは少し厳しすぎるかなと思います。
その次に考えられるのが部分一致みたいなもので、これは古典的な機械学習や自然言語処理の領域として、ROUGEとかいろいろな便利な指標があるので、そのあたりが使えるんじゃないかなと思います。ほかにも、もっと理論的な方法としてEmbedding、その出力の意味をベクトルで表して、それが近いかどうかを判定したり。
あとは、採点自体をLLMにやらせる方法もあります。LLMに採点させる方法に関しては一番柔軟なのですが、それ自体に改善が必要になるので、個人的にはこのうちの真ん中2つ(単語の部分一致、Embedding)ぐらいでやっていくのがベーシックかなと思います。
このあたりはいろいろな資料が既存で出てたりするので、今日は割愛できればと思います。
(スライドを示して)ここは簡単なのですが、その次が問題です。採点できました。どれぐらい合っているか、まず分かってきましたというところの次のステップとして、うまくいかないところをどういうふうに改善するのかという時に、その原因を突き止めるのが非常に大事なのかなと思っています。
原因を突き止めるという時に、LLM特有のありがちなところを今日は紹介できればと思います。
いろいろなLLMの使い方があると思いますが、すごく一般的なちょっと抽象的な使い方の流れとして、テキストでもPDFでも「Word」でもなんでもいいのですが、なんらかの食わせたい文章のファイルがあります。
それを検索などで取ってきて、プロンプトにしてLLMに食わせて何かを出力させます。この出力において、先ほど期待したい正解があって、その正誤判定をするケースを考えています。
(スライドを示して)この時に注意がいきがちなのが、④と書いてあるLLMの処理のところで。これが一番花形っぽく見えるので、そこに原因を求めたり、そこばかり改善をやりがちかなと思います。
しかし、我々の観測範囲だと意外と(原因が)そこじゃないこともけっこう多いかなと思っていて、それを①②③として今日紹介できればと思います。特に、プロンプトばっかりやりがちというか、プロンプトばっかりいじりがちだけど、プロンプト以外が問題だったりするかなと思っています。
(スライドを示して)1個目が前処理のところで、基本的に今のLLMはテキストしか食えないので、完全にテキストじゃないものを入れる時は、テキストに変換したりして入れるわけですよね。
「LangChain」とかの既存の便利ツールにも、抜き出すツールがいっぱいあるので、使っている方がけっこう多いんじゃないかなと思いますが、あれをよく分析すると、意図しない抜き出し方をしていることもけっこうあるかなと思います。
すごくシンプルな例だと、文字化けしているとか、英単語が謎に分割されているとか、よく見ると「あれ?」となることがけっこうあったりするかなと思います。
(スライドを示して)ちょっと高度なレベルで例に記載しているものとしては、論文で縦割りの文章になった時に、人間、論文を読める人は「こういう順番で読む」とわかるのですが、人間が読むとおりにテキストが抽出されていないこともけっこうあったりします。
順番が食い違うというところの狭間で意図しない答えが作られている可能性があるので、①番の前処理のところで勝負が決まっている可能性があるので書いています。
2点目が検索での欠損というところで、基本的にコンテキストサイズに限界があるので、なんらかの……。呼び方はなんでもいいですが、チャンクに分割して、そこから検索して取ってくることがけっこう多いんじゃないかなと思います。
この時に、正しい答えを作る上で必要な情報が入っているチャンクと、それ以外に分かれるわけですね。その検索の時に、必要なチャンクが選ばれていない場合は、プロンプトをどうがんばっても答えは出ないので、この検索部分でしっかり答えが入っているものが取られているかをしっかりチェックすることが大事かなと思います。
3番目が、結果をまとめる際の欠損・毀損です。先ほどの話で、文章が大きいのでチャンクに分割した場合、基本的にLangChainなどいろいろな既存のツールでも、その結果をまとめる処理はやってくれる、もしくは作ってくれます。
1個1個のチャンクに対して答えが得られました。ということを全部のチャンクに対してやって、最後どうまとめるかというのがあったりします。
この時のまとめ方の戦略がいっぱいあって、map_reduceとかrefineとか、いろいろなものが作られているわけですが、合体する過程でグチャってなったり消えたりしていることがあります。1個1個のチャンクでしっかり取れているんだったらLLMのプロンプトは悪くなくて、まとめ部分が悪いので、まとめる部分を改善しようとなります。
これを見極めるために、LangChainとかだと、最後のまとめられた結果しか返ってこないこともあるので、その途中の中間結果をしっかり出力して確認することが大事かなと思います。
(スライドを示して)というところで3つ挙げました。この3つがどれも違ったら初めてLLMの本丸のところが怪しいかということを見るのがいいんじゃないかなと思っています。
このあたりのチューニングは、LLMに限らず、アルゴリズム改善など一般的な話がかなりあるのかなと思っています。「いろいろ変えると訳がわからないから1個ずつ変更しよう」とか「問題を分解しましょう」とか。あとは、解きたい問題、業務で本番で使う本丸のやつは難しかったりするので、ちょっと恣意的で簡単な例を作って、それでそれどおり動くかをチェックして、だんだん難しくしていくとか。このあたりの一般的なところに取り組めるといいんじゃないかなと思います。
というところで、精度改善をがんばっていければと思うので、みなさん、よろしくお願いします。以上です。
関連タグ:
2025.01.30
2月の立春までにやっておきたい手帳術 「スケジュール管理」を超えた、理想や夢を現実にする手帳の使い方
2025.01.29
社内会議は「パワポ」よりも「ドキュメントの黙読」が良い理由 Amazon元本社PMが5つのポイントで教える、資料の書き方
2025.01.28
適応障害→ニート→起業して1年で年収1,000万円を達成できたわけ “統計のお姉さん”サトマイ氏が語る、予想外の成功をつかめたポイント
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
2025.01.31
古い手帳から新しい手帳への繰り越し方 手帳を買い換えたら最初に書き込むポイント
2025.02.03
手帳に書くだけで心が整うメンタルケアのコツ イライラ、モヤモヤ、落ち込んだ時の手帳の使い方
2025.01.30
若手が「長く働きたい」と思える職場の3つの要素 データから見る、部下を伸ばす関わり方
2025.01.30
とりあえず60点の資料で議論、不要な文章は「容赦なく削る」 Amazon元本社PMが語る、ドキュメント作成の7ステップ
2025.01.29
何でもできるはNG? CTOが語るエンジニアの成長戦略とキャリア展望
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由