1. HOME
  2. ブログ
  3. LLMを賢くしても国会答弁には使えない？LangChainとChatGPT（「IISIA技術ブログ」Vol. 12）

LLMを賢くしても国会答弁には使えない？LangChainとChatGPT（「IISIA技術ブログ」Vol. 12）

この年末年始は大規模言語モデル（LLM）三昧といった日々だった。世間はやれ年末だ、年始だと騒いでいたようだが、人工知能（AI）開発とその社会実装にそんな季節感は全くない。今年（2024年）には人工知能学会の全国大会（浜名湖）が5月に控えている。それに向けてのコーディングと実験、検証、さらにはそれをベースにした論文執筆で瞬く間にこの年末年始は終わってしまった。今、ようやく一段落つき始めているので、久方ぶりにこの技術ブログを書くことが出来ている。

詳細については学会での論文発表を申請しているため、そこでの「新規性」のジャッジメントを損なわないよう、控えさせて頂く。ただ、一言でいうならば私がそもそも何故に外務省を自主退職したのか、そこにある本当の重大な理由に対して個人的に、しかし「工学的に」ケリをつけたいと思ったため、テーマを選択した次第である。換言するならば自分自身の人生にある意味、区切りをつける研究だともいえるわけで、それだけにやればやるほど、全く疲れを知らず嵌っていく自分を感じている。人工知能（AI）開発の「中毒性」は正にここにある様な気がしてならない。

2005年3月末に自主退職した当時、私は外務省アジア大洋州局北東アジア課において「北朝鮮班長」を務めていた。当時、国会対策のために毎月ほぼ200時間以上、時には240時間を超える超過勤務の日々を過ごしていた。「働き方改革」が語られて久しいが、当時（2005年）にそんな言葉は存在しなかった。私は文字通り「組織の駒」として精勤し、日々、見えない敵と戦い続けていた。しかし同時に胸の中に抑えきれない疑問も感じていたのだ。「このまま行ったら、死んでしまうかもしれない」

霞が関の国会答弁作成作業はマゾヒズムの極地というべきものだ。政と官の間のルール、しかも不文律に則り、官僚は野党議員からの質問通告・要求をいつまでも翌日の審議開始直前まで待たなければならない。総理経験者で最近引退したある野党大物議員は、自分ではなく秘書にそうした質問通告を「真夜中」からさせるので有名だった。無論、霞が関全体が待たなければならない。質問が出て来て各省庁に配布されるのは午前1時過ぎということもざらにあった。それから答弁案の作成に入るわけだが、一筋縄に行かなかった場合、結果として答弁案のセットは午前5時などということもある。午前5時を過ぎると当時の外務省ではタクシー券は出ず、「地下鉄で帰れ」というルールであった。それでどうやって翌日7時からの大臣勉強会に参加出来ようか？畢竟、「では仮眠でも取るか」ということになり、ネクタイを外してソファに横になる。1時間もすると大臣勉強会のために目を覚まし、ネクタイを締め直して仕事を再開する。・・・そんな日々を私は当時過ごしていた。

「国会答弁案の中でも、とりわけ定型パターンについては自動的に作成出来たら」

そう何度と想っただろうか、当時。そして今、「生成AI（generative AI）」の時代になってようやくその夢がかなったかの様な時が到来したというわけなのである。

世には既に数々の大規模言語モデル（LLM）がある。そして実際、その社会実装の可能性についてマスメディアは騒ぎ立て、したり顔の評論家が語ってもいる（そういえば最近、かのホリエモンが「AIスクール」を開講したと聞いた。あれ？彼って・・・WEB世代であって人工知能（AI）を学んだことなんてないはず、とほくそ笑んでいる自分がいる（笑）、同世代として）。しかし、実際にLLMの社会実装まで至ることの出来るコーディング能力とそれを社会の現場で検証する能力を持っている者となると、果たして何人いるだろうか？実際にはほとんどいないし、そういう意味での論文は我が国発であまり（今のところ）発されていないのが現実と言わざるを得ない。

「それでは自分でやってみよう」ということで、今回の論文テーマに取り上げてみることにした。結論から言うとコーディングそのものは完成し、動作確認もできた。正に夢の「国会答弁案作成システム」の出来上がりである。ざっと構造を書いてみることにしよう。

●まず、OpenAIとAPI連携する。他のLLMでも良いのだが、やはりLangChainなどとの相性を考えると断然、OpenAIだと思う。ここから従量課金制の世界に突入する。したがって「カネがあればどこまでも行くことが出来る」という世界に入っていく。

●次にオープンソースの世界からLangChainをダウンロードする。このライブラリーはなかなかの優れものであって、NLPで有名なspaCyから始まり、ベクトル化をpython環境で行うためのtiktoken、それからベクトル化した言語データをデータベースにするためのChromaなどが盛りだくさんで入っている。

●言語モデルはさしあたりOpenAIからtext-embedding-ada-020を用いる。というか、現状ではOpenAIではこれがデファクト・スタンダードなのだから仕方がない。特にこのあたりは問題がなく進む（というか、実は後程述べるとおり、ここで大きな問題がコーパスの規模によっては生じるので一工夫がいる。AIエンジニアではなく、プランナーの世界だとややしんどいかもしれない）。

●そしてデータベース化が終わったらば、質問（query）と答えの組み合わせに整理して、chatbot化する作業に入る。したがって質問はまずもって上記のChroma上のデータベースを用い、類似度文書検索という形で行う流れになる。これをgpt-3.5-turboに接続し、HumanMessageといったツールでチャット型式での答えへと整形していく。

お気づきだろうが、今回利用したのはRAG（retrieval augmented generation）という手法である。これ以外にも同様のシステムを作りたいのであれば古典的に1：1対応での質問と答えを登録していく「エキスパートシステム」を利用する手もあるだろうし、LLMについてfine tuningを行うことでそもそもアルゴリズムそのものによる学習をより専門化させていくという手法もある。しかし前者は余りにも手間がかかりすぎるので1980年代における我が国の人工知能（AI）開発が頓挫することになった元凶であったわけだし、後者についてはそもそもfine tuningが有効なのか？という議論が論文ベースでも既に出されていること、さらにはそもそもLLMそのものを改変しようとするわけで、個人の開発者にはおよそ手が出せない世界というべきである。しかも最終的にはprompt engineeringをしなければまともな答えが返ってこないというのでは、そこまでコストをかけるの？ということになってくるわけである。

「果たしてどれくらいの精度の国会答弁案作成システムが出来たのか？」と読者は大変興味深く感じてくれているであろうが、その点についての検証と考察が今回の人工知能学会全国大会に持ち込みたいテーマであるのでここでは割愛させて頂く。他方でテクニカルな論点だが、意外に重要と思われる点（前述）があるのでコードも含め、示しておければと思う。それはCharomaにデータベースを登録する際、OpenAi側が「不正アクセスに対する防護措置」としてとっているRate Limitに引っかかってしまい、登録できない場合が往々あるという点である。コーパスもあり、ベクトル化も済んだというのに一気に「悲しく」なるわけだが、これに対するソリューションは大きく分けて2つあることを指摘しておきたい。一つは「動作がクラッシュしたらば、その続きから残りのデータについて作動するようback off機能を活用すること」そして「そもそもbatchを小さくし、複数回にわたって作動させること」の2通りである。今回は前者を用いてみた。綿密にネット上でチェックすると同種のエラーに対してどう対応するのか、ということについてOpenAiの「準公定マニュアル」の様なものが見つかるわけだが、結構手間がかかったのでここで該当部分をそのままアップしておくことにする。

#データ量が多いのでこちらを参考にbackoffを組み入れる。https://cookbook.openai.com/examples/how_to_handle_rate_limits

from openai import OpenAI # for OpenAI API calls
client = OpenAI()
from tenacity import (
    retry,
    stop_after_attempt,
    wait_random_exponential,
)  # for exponential backoff

@retry(wait=wait_random_exponential(min=1, max=60), stop=stop_after_attempt(6))
def completion_with_backoff(**kwargs):
    return Chroma(**kwargs)

completion_with_backoff(persist_directory="./.data",embedding_function=embeddings).add_documents(splitted_data,)

print("データベースの作成が完了しました。")

 

いかがだろうか？「社内文書を活かしてLLMで業務効率アップを」と宣伝するAIヴェンチャーが後を絶たないわけだが、そもそも「本当にそうなの？」と最後に一考頂きたい。なぜならば社内データをどんなにアルゴリズムの出発点に投入しても、所詮は「確率論」で動くのが生成AI、そしてLLMなのだ。どんなに調整してもずれは生じ、かつ仮に正確な（期待している）応えが出て来るとしても、それはあくまでも確率論の下にある。すなわちそこにはどうしても「創造性の罠」があるというわけなのだ。・・・それを果たして「創造性の新しい源泉」と見るのか、あるいは「幻覚」として否定するのか。いよいよ選択の時が迫っている気がしてならない。

 

2024年1月4日　東京・丸の内にて

原田　武夫記す

株式会社原田武夫国際戦略情報研究所　代表取締役CEO/グローバルAIストラテジスト