【ITニュース解説】Do You Actually Need an LLM?

近年、AI技術の進化、特に大規模言語モデル（LLM）の台頭は目覚ましく、多くの人が様々な課題解決にLLMを使おうと考えている。しかし、本当にLLMが必要なのか、そしてそのタスクに対して最適な「最小の計算量」は何なのかという疑問は、見過ごされがちだ。今回の実験は、この問いに答えるべく、週末を使って実際のワークフローにLLMを適用し、その結果を検証したものである。

実験では、Raspberry Pi 4という小型コンピュータを使い、2種類の小型LLM（smollm2:360mとqwen2.5:1.5b）をOllama経由で実行した。これらのモデルは、大規模なデータセンターで動くモデルに比べるとはるかに小さいが、身近なハードウェアで動かせるのが特徴だ。テストには架空のワイナリーに関する95の質問を用意し、人間が正否を判断できる環境を整えた。検証したワークフローは、「テキストからの情報抽出」「メッセージの分類」「文書に基づく質問応答」の三つである。

まず、「テキストからの情報抽出」タスクでは、メッセージの中から特定の形式（ORD-に続く6桁の数字）の注文番号を見つけ出すことを試みた。比較対象として、一般的なプログラミングで使われる「正規表現」も用意した。結果は驚くべきものだった。正規表現は30件中30件を正しく抽出し、処理時間はほぼゼロだった。一方、高性能な方のLLM（qwen2.5:1.5b）は28件正解したが、処理に5秒かかった。さらに、LLMの誤答の中には、正規表現では構造上発生し得ないようなタイプのエラーが含まれていた。例えば、注文番号が存在しないと誤って判断したり、正しい注文番号から不要な部分を削除したりするケースである。より小さなLLM（smollm2:360m）は、注文番号の場所は特定できたものの、指示された出力形式に従えず、形式を無視して数字だけを返してしまうことが多かった。このタスクにおける結論は、「不必要」であった。単純で明確な形式の情報を抽出するなら、確定的なコードである正規表現が圧倒的に優れている。

次に、「メッセージの分類」タスクでは、顧客からのメッセージを「予約」「請求」「在庫」「苦情」「質問」「エスカレート」の6つのカテゴリに振り分けることを試みた。「エスカレート」は、人間による対応が必要な場合に指定する。ここでもLLMの性能は芳しくなかった。高性能なLLMでも正答率は46%（23/50件）にとどまり、自信を持って誤ったカテゴリに分類するケースが26件もあった。特に問題だったのは、怪我報告や法的通知、アレルギーに関する質問といった、人間による緊急対応が必要なメッセージが、安全な「エスカレート」ではなく「苦情」に分類されてしまうことだった。詳しく分析すると、LLMは「苦情」や「質問」のようにメッセージの「内容（トピック）」に関する分類は比較的得意な一方で、「エスカレート」や「請求」のように「次に何をすべきか（行動）」や「どの部門が対応すべきか（ルーティング判断）」といった要素を含む分類はほとんどできなかった。つまり、小型LLMは「これは何についてか」は答えられるが、「これについて何をすべきか」という判断は苦手だということが分かった。このタスクの結論は「不十分」であり、特に人間による判断が必要なメッセージの振り分けはLLMに任せるべきではない。

最後に、「文書に基づく質問応答」タスクでは、ワイナリーに関する4つの文書（約650トークン）を基に15の質問に答える能力を検証した。結果、単一の文書から答えが見つかる質問に対しては、高性能なLLMが8問中8問すべてに正しく答えることができた。これは、小型のローカル環境でも、正確な情報検索ができるという点で非常に有望な結果だった。しかし、二つの文書の情報を組み合わせて答えを導き出すような、簡単な推論や計算が必要な質問になると、両モデルともほとんど正しく回答できなかった。例えば、試飲料金の計算問題では、複数の要素を考慮した正確な計算ができなかった。さらに懸念すべきは、文書内に回答がない質問に対して、両モデルとも「情報がない」と正しく判断するのではなく、もっともらしい「捏造」を行う傾向が見られたことだ。特に高性能なLLMは、関連する事実（例えば、アルコール度数の質問にBrix値を答える）を使って、誤っているにも関わらず専門知識があるかのように見える回答を生成し、人間が間違いに気づきにくい危険性を示した。このタスクの結論は「許容範囲」であり、人間による出力の確認が必須であることが示された。

これらの実験結果は、LLMをシステムに導入する際の重要な教訓を与えてくれる。LLMの利用を検討する際には、以下の4つの特性を満たしているかを確認すべきである。

1. 回答が入力に既に存在しているか: 推論ではなく、テキスト内に明確に答えがあるか。
2. 回答が一つだけであるか: 複数の事実を組み合わせる必要がなく、単純な答えであるか。
3. 出力が短いか: 長い回答は処理の遅延や捏造のリスクを高める。
4. モデル以外の何かが、出力の妥当性を判断できるか: 例えば、正規表現やデータベース、あるいは人間が最終的なチェックを行う仕組みがあるか。

これら4つの条件のいずれかが欠ける場合、小型LLMにそのタスクを任せるべきではないという結論が導き出される。また、これら4つの条件を全て満たしているなら、そもそもLLM自体が不要で、よりシンプルな確定的なコードで十分な場合もある。 筆者の実験前の予測は、実際の結果と大きく異なることもあった。特に「直感」に基づいた予測は、客観的なデータに基づかないコイントスよりも悪い結果となった。これは、最新のAI技術であっても、その振る舞いを予測することは難しく、実際に検証することの重要性を示唆している。

結論として、LLMは強力なツールではあるが、その得意不得意を理解し、適切なタスクに適切に適用することがシステムエンジニアには求められる。LLMは「何であるか」は教えてくれるが、「何をすべきか」という判断は、多くの場合、人間や確定的なルールに委ねるべきである。