ChatGPTのおさらい、その2
さて、前回のブログでは、ChatGPTの回答が「必ずしも正確ではない」という話で終わっていました。今回は以下のことに触れていきます。
✅AIには人間のような意図はなく、言語パターンを学習しているだけ
✅人間も不正確な情報を伝えることがあり、100%の正確性を求めるのは現実的ではない
✅言葉をベクトル（数値の並び）に変換して処理している
✅類似性を数値で表現できるようになる
✅特定の情報源（例：法律事務所の過去の契約書）を参照させることができる
✅一度に処理できる情報量に制限がある
意図した嘘？
先のChatGPTの解答例で起こったことは、ハルシネーションと呼ばれています。「AIは根の葉もない嘘をつく」と非常にネガティブな意見を耳にすることがありますが、このハルシネーションと呼ばれる現象を誇張したものです。LLM（大規模言語モデル）は言語パターンを学習しているだけで、物事の関係性を真に理解しているわけではないことを、もう一つ別の例をあげてみたいと思います。
LLMには「Reversal Curse（逆転の呪い）」という課題があります。例えば、「甲社は乙社に対して1000万円の債務がある」という情報を正確に処理できても、「乙社の1000万円の債権者は誰か？」という質問に正確に答えられない可能性があるのです。この記事の例が分かりやすいでしょう。"Who is Tom Cruise's mother?"（トム・クルーズの母親は誰？）という質問には"Mary Lee Pfeiffer"と答えられるのに、"Who is Mary Lee Pfeiffer's son?"（メアリー・リー・ファイファーの息子は誰？）には正しく答えられないのです。
前回のブログをお読みの方には復習になりますが、ChatGPTなどの大規模言語モデルは「文に対して次の単語を予測する」システムです。これらのモデルには、人間のような意図はありません。「イーロン・マスクの母親に関しては正しく答え、世良英誉の母親に関しては間違えて答えよう」などという意図を持っているわけではないのです。「イーロン・マスクの母親は…」に続く単語で最も適切そうな単語を並べた結果、前回のような回答になっており、これが事実と一致したに過ぎません。
問題は、我々人間側が「ChatGPTは知識を持っている」と誤って期待してしまうことです。実際のところ、人間の方が様々な先入観や偏見、不正確な情報に基づいて「ハルシネーション（幻覚）」を起こしがちです。仕事でも「人によって言っていることがバラバラ」ということはよくあります。普段から"悪気はないにせよ"不正確な情報を他人に伝えているのです。AIはそんな我々が作ったデータを学習材料にしているのですから、AIに対して常に100%の正確性を求めるのはお門違いだと私は思います。
"似ている"を数値化する（ここ重要）
ここまでが私の意見ですが、次は「文に対して次の単語を予測する」システムをもう少し詳しく理解しましょう（今回のブログで最も皆さんに知ってほしい内容です。気張ってついてきてください）。そのためにLLMの基礎となるText Embedding技術について中島聡さんブログを参照しながら触れます。
私たち人間は日常的に「AさんとBさんって正反対の性格だよね」や「この音楽は昔流行ったあの曲に似ている」というように、漠然と物事の類似性を比較します。これらは非常に曖昧で、定量的に数値化されたものではなく、いわゆる"なんとなく似ている"程度のものです。機械にこの類似性を判断させるには、この"なんとなく似ている"を数値化する必要があります。一例として「色」を考えてみましょう。人間は色を見ただけで、似ているかどうかをおおよそ判断できます。コンピューターに同じことをさせるには、色の情報を数値化しなければなりません。「赤・緑・青」の三原色に分解する方法を使うと、それぞれの色は以下のような数値に変換できます。
赤：(1.00, 0.00, 0.00)
橙：(1.00, 0.64, 0.00)
黄：(1.00, 1.00, 0.00)
緑：(0.00, 0.50, 0.00)
青：(0.00, 1.00, 1.00)
藍：(0.00, 0.00, 1.00)
紫：(0.50, 0.00, 0.50)
このように、いくつかの数字で表現されたデータをベクトル（括弧内の数字）と呼びます。同じようにあらゆる言葉をベクトル化し、数値的に前の単語と次の単語の類似性を計算し、より類似性が高いものを次の単語として生成しているのです。法律用語を例に挙げてみましょう。例えば、「契約書」と「合意書」という単語があるとします。これらの単語をコンピュータが理解するためには、数値のベクトルに変換する必要があります。以下は仮の数値例です：
契約書：0.45,0.30,0.75,...
合意書：0.46,0.29,0.74,...
このように、各単語を数値ベクトルに変換することで、コンピュータはこれらの単語の「意味の近さ」を計算することができます。具体的には、ベクトルの類似度を求めることで、二つの単語がどれだけ似ているかを判断します。
契約書⋅合意書 = 0.98
この結果が1に近いほど、二つの単語は意味的に近いことを示します。
次に少し幅を広げて考えてみましょう。弁護士の方が扱う「契約書」の文面を例に挙げてみます。まず、契約書全体をチャンク（小さなセクション）に分割します。例えば、「序文」「目的」「契約期間」「解約条件」など、各セクションに分けます。次に、各チャンクをベクトルに変換します。ここで、ベクトルとは、単語やフレーズを数値の集合に変換したものであり、その数値がその単語やフレーズの意味を表します。
序文：0.12,0.45,0.67,...
契約の目的：0.34,0.56,0.78,...
契約期間：0.23,0.45,0.89,...
解約条件：0.67,0.56,0.45,...
このようにして、各チャンクが数値ベクトルに変換されます。そこで例えば、ユーザーが「この契約の目的は何ですか？」と質問した場合、その質問もベクトルに変換されます：
質問：0.31,0.52,0.71,...
この質問ベクトルと、契約書の各チャンクのベクトルとの類似度を計算します。
序文・質問 = 0.65
契約の目的・質問 = 0.92
契約期間・質問 = 0.58
条件・質問 = 0.47
署名欄・質問 = 0.35
この結果から、「契約の目的」セクションが最も関連性が高いと判断され、そのセクションに書いてる文章を参考にしてLLMが回答を生成します。
RAG（Retrieval-Augmented Generation）
ここまで "似ている"を数値化するEmbedding について説明してきましたが、この技術を実際にどのように活用するのでしょうか。その一つの方法が RAG (Retrieval-Augmented Generation) です。RAG について説明しましょう。
まず、LLM（大規模言語モデル）について復習します。LLM は膨大な量のテキストデータを学習しているので、優れた言語予測能力を持っています。しかし、ユーザーからの質問によっては前回の例（世良英誉の母親は？）のように、とりあえず可能性のある単語を続けた結果、事実とは異なることを生成してしまうことがあります。RAG は、この LLM の弱点を補うために使われる技術です。
我々にとってRAGの恩恵が受けられる場面は、LLM が知らない新しい情報や特定の情報を参照させたいときです。例えば、ある法律事務所で過去取り扱ってきた契約文書は当然LLMの事前学習には含まれていません。そこでRAGの技術を使用すると次のようなことが実現可能となります。
まず、事務所が保有する全ての契約書を電子化し、それぞれを小さなチャンク（例：条項ごと）に分割します。各チャンクを Text Embedding 技術を使ってベクトル（数値の並び）に変換します。ここで、ユーザー（弁護士や事務局）からの質問に対して、システムがどのように動作するかを見てみましょう。例えば、ユーザーが「IT企業との業務委託契約で、一般的な秘密保持条項はどのようなものですか？」と質問したとします。
質問のベクトル化： システムは、この質問自体をベクトルに変換します。
関連性の高いチャンクの検索： 質問のベクトルを使って、データベース内の全ての契約書チャンクとの類似度を計算します。ここでは、「IT」「業務委託」「秘密保持」などのキーワードに関連する契約書チャンクが高いスコアを得るでしょう。
最適なチャンクの選択： 類似度スコアが最も高い上位数件のチャンクが選択されます。例えば：
2022年のA社との業務委託契約の秘密保持条項
2021年のB社とのソフトウェア開発契約の機密情報取扱い条項
2023年のC社とのIT顧問契約の守秘義務条項
LLMへの入力： 選択されたチャンクは、ユーザーの質問と共にLLMへ入力されます。
回答の生成： LLMは、提供された契約書チャンクの情報を基に、質問に対する回答を生成します。例えば： 「IT企業との業務委託契約における一般的な秘密保持条項には、以下のような要素が含まれることが多いです：
秘密情報の定義（ソースコード、アルゴリズム、顧客データなど）
秘密情報の使用制限
情報漏洩防止のための適切な措置
契約終了後の秘密保持義務の存続期間
違反時の罰則規定
このプロセスにより、ユーザーは事務所の過去の経験や実際の契約書に基づいた具体的な回答を得られ、実務で十分に活用できるツールとなります。しかし、ここには重要な制限があります。それは、LLMが一度に処理できる情報量（Context Window）に限界があるということです。上記の例では、ステップ3で見つかったチャンクが3つだった場合を仮定しています。しかし、これらの一つ一つが数万字に及ぶ文書だった場合、あるいはチャンクが10〜20個ある場合、LLMの一度の処理で扱える許容量を超えてしまうことがあります。
さらに、ハルシネーションも改めて課題となります。ステップ3で見つかった3つの契約文書の内容は、当然ながら重複していることがあります。そうすると、回答の中にある条項はA社から、別の条項はB社からと、複数の文書を織り交ぜてしまい、結果的に実際には存在しない契約文書を回答してしまう可能性があります。
終わりに
次回は、一度に処理できる情報量（Context Window）に関して触れたいと思います。ここまでお読みいただきありがとうございました。