ChatGPT で「マラソン」という言葉の語源について質問すると、ファイディッピデスがマラソンからアテネまで完走した伝説的な 42 km のランをヘロドトスがどのように説明したかが正確にわかります。

しかし、私の祖母のレシピのリストはどうですか? もちろん、それらのレシピをデジタル化できます。問題ありません。しかし、冷蔵庫にある食材、好きな色、その日の気分に基づいて、どのような食事を準備すればよいかアドバイスが欲しい場合はどうすればよいでしょうか?

疲れ果てて倒れずにそれが可能かどうか見てみましょう。

LLM、自分の限界を満たし、それを超える

LLM は大規模言語モデルです。OpenAI のGPT-4 はその一例であり、Meta のLLamAは別の例です。ここでは、これらのモデルを参照する一般的な LLM 用語に固執することを意識的に選択します。覚えておいてください: これらの各モデルは、膨大な (公開されている) データのセットでトレーニングされました。

これらの LLM が一般的な言語を意味のある理解を持っており、トレーニング データに存在していた情報に関連する情報を (再) 生成できることが、これまでに明確に実証されています。これが、 ChatGPTのような生成ツールが、LLM がトレーニング中に遭遇したトピックに関する質問に驚くほどうまく答える理由です。

しかし、これらの大規模な LLM が直接把握できないのは、各組織内で非常に価値のあるデータ、つまり内部の知識ベースです。したがって、大量にポップアップする質問は次のとおりです。

これらの LLM の能力を活用して、特定のナレッジ ベースに保存されている情報を解き放つにはどうすればよいでしょうか。

オーケー、これを行うには、内部のナレッジ ベースを、LLM をトレーニングするための追加データとして導入することはできませんか? または、よろしければ、特定のナレッジ ベースで LLM を微調整できますか。

はい、ほとんどの場合可能です。しかし、信頼できる質疑応答のためには、それは適切な方法ではないかもしれません.

微調整が常にうまくいくとは限らない理由

本の虫のビリーに会いましょう。ビリーは大規模な言語モデルであり、膨大な量のオンライン情報をむさぼり食い、膨大な知識で力を与えてきました。しかし、ビリーは頭が良いのですが、あなたの特定のホームライブラリの本を読み通したことはありません.

微調整は次のとおりです。本の虫のビリーに、非常に具体的な知識ベースのすべての本を提示し、おいしい追加情報をすべて彼にむさぼり食わせます。このように、LLM の本の虫である Billy は、その一般的な情報をすべて知っているだけでなく、特定の知識ベースの内容についても多くのことを「知っています」。

おめでとうございます。この微調整プロセスにより、ビリーは特定のドメインについてよく知っている非常に具体的なビリーに変わりました。以下に、Billy の作業を開始する方法を示します。改善された本の虫に質問を投げかけることで、巨大な一般的なトレーニング セットからの情報と、特定の知識ベースに保存されている情報の両方を使用した回答を期待できます。

確かに強力ではありますが、このソリューション アプローチの重大な問題は、本の虫がどのようにしてその答えを思いついたかについての洞察がまだほとんどないことです。さらに、LLM の微調整には (コストのかかる) 結果があります。

Billy の微調整がうまくいかない主な理由を次に示します。

• ソースの明確さはありません。幻覚を防ぐのは難しく、LLM には「一般的な」知識と「特定の」知識の明確な区別がありません。
• アクセス制限なし。戦略文書の情報を照会できるユーザーとそうでないユーザーがいる場合を想像してください。これにどのように取り組みますか？微調整されたビリーはすべてを知っているだけで、推論時に知識を除外することはできません。
• LLM のホスティングにはコストがかかります。LLM を微調整したら、それを回転させ続ける必要があります。大規模な言語モデルはまあ… 大規模です。それを維持し、実行するためのコストは増加します。メリットはそれらのコストを上回りますか?
• 微調整の繰り返し。モデルにナレッジ ベースへの変更を反映させたい場合は、モデルの再トレーニングが必要です。

RAG で富を得る

Retrieval-Augmented Generation (RAG) の背後にある考え方は非常に単純です。目標は、ナレッジ ベースの情報を解き放つことです。本の虫を解き放つ (微調整する) 代わりに、知識ベースの情報を包括的に索引付けします。

上記のスキーマでは、スマート レトリバーが司書のように機能する方法を示しています。理想的には、司書は自分の図書館にあるものについて完全な知識を持っています。訪問者が特定の質問をした場合、どの本のどの章を推奨すればよいかがわかります。

より技術的なレベルでは、これはセマンティック検索エンジンを表します。この場合、埋め込みはドキュメント セクションのベクトル表現であり、各セクションに格納されている実際の意味を数学的に記述することができます。埋め込みを比較することで、どのテキスト セクションが他のどのテキスト セクションと意味が似ているかを判断できます。これは、以下に示す検索プロセスにとって重要です。

重要な要素は次の 2 つです。

1. スマート・レトリバー(司書)
2. ジェネレーター(つまり、本の虫)

この RAG ベースのセットアップの主なハイライト

1. 回答の根拠となった情報源の明確な表示。ジェネレーターから返された回答の検証を可能にします。
2. ジェネレータコンポーネントをナレッジ ベースのコーパスに制限することで、レトリーバによって関連するソースが見つからない場合、応答を作成できないことを認めます。
3. 保守可能な検索インデックス。ナレッジ ベースは生き物です。それが変更された場合、その変更を反映するように検索インデックスを適応させることができます。

微調整の再訪

上記のセクションでは、ソースの明瞭さをほとんど制御できず、幻覚のリスクが高まるため、微調整を貴重なオプションとして却下したことに注意してください.

一般的な LLM によって強化された RAG アプローチは、LLM が一般的なトレーニングから理解できない超特定の専門用語が特定の知識ベースに含まれていない場合にのみうまく機能することに注意する必要があります。

知識ベースに存在する「口調と専門用語」に従うために、ソリューションの応答が必要であると想像してください。この場合、LLM の微調整は避けられないようです。

特定の専門用語を処理し、微調整された LLM を RAG アーキテクチャに組み込んで、組み合わせた利点を享受できるようにすることは、有効なアプローチになる可能性があります。一般的な本の虫で作業する代わりに、特別に訓練されたビリーを使用して、ジェネレーターおよび/またはスマートレトリーバーのコンポーネントに電力を供給します.

なぜ今なのか？新着情報？

素晴らしい質問です。
セマンティック検索 (スマート検索) はかなり前から存在しており、ジェネレーティブ AI も同様です (いくつかのプリミティブ フォームは何十年も前から存在しています)。
ただし、ここ数か月で極めて重要な進歩が見られました。

技術レベルでは、最近、LLM のパフォーマンスが大幅に向上しました。これらは、RAG ソリューションに次の 2 つのレベルでプラスの影響を与えます。

• 埋め込み(例: OpenAI または Google のPaLMによる埋め込み API )
• 生成機能 (例: OpenAI のChatGPTソリューション)

したがって、間違いなく平凡なバージョンの RAG はかなり長い間可能だったかもしれませんが、技術の向上と牽引力の増加により、実り多い市場機会が生まれます。

成功への挑戦

このセクションでは、成功する RAG ソリューションをセットアップする際の主な課題のいくつかを紹介することを目的としています。

• スマートレトリバーの性能に大きく依存。
  Generative Component からの応答の品質は、Smart Retriever から渡される情報の関連性に直接依存します。前述のように、LLM の進歩により、リッチで強力なテキストの埋め込みが可能になりました。しかし、純粋に API を介してこれらの埋め込みを取得することは、最善の選択肢ではないかもしれません。セマンティック検索コンポーネントを設計するときは、非常に意識する必要があります。おそらく、ナレッジ ベースには特定の専門用語があり、それを処理するためにカスタム フィット (微調整) コンポーネントが必要になる場合があります。セマンティック検索に関するより詳細な実践ガイドは、このブログ投稿 [1]にあります。
• ナレッジ ベースの情報に固執するための制限には、トレードオフがあります。
  RAG アーキテクチャで説明したように、LLM 生成コンポーネントを関連ドキュメントにある情報に制限することができます。これにより、幻覚 (無意味な答え) が発生する可能性はほとんどなくなりますが、LLM が持つ情報をほとんど活用していないことも意味します。ソリューションでその知識も使用したい場合がありますが、ユーザーから要求された場合にのみ使用する場合があります。
• 複雑な対話を可能にする会話型デザイン。
  上記の図は、ユーザーの行動を単に「1 回限りの質問」をするものとして表していますが、多くの場合、ユーザーはソリューションによって提供された回答を ( ChatGPTスタイルの会話で) 拡大したいと考える場合があります。幸いなことに、この戦いを支援するツールが存在します。フレームワークlangchainは、これを正しく行うための手助けを提供します。
• 世代を成功に導く方法として、迅速なエンジニアリング。
  生成コンポーネントの答えを正しく得るには、期待する出力の種類を正確に伝える必要があります。全体として、これはロケット科学とはかけ離れています。ただし、ユースケースに合わせてプロンプトを適切にセットアップするには時間がかかり、十分な注意が必要です。プロンプト管理システムを調べて、どのプロンプトがどの状況で最適に機能するかを追跡できるようにすることをお勧めします。
• 適切な LLM の選択: 費用はいくらで、データはどこに行くのですか?
  このテキスト全体を通して、ソリューションで使用する LLM に関して明示的な選択はしていません。使用する LLM (API) を選択するときは、プライバシーとコストの制限を考慮してください。まともなオプションはすでにかなりあります。OpenAI のGPT、Meta のLLaMA、Google のPaLM があり、イーロン マスクは LLM シーンに参加すると主張しており、物事がどこに行くかを知っています。エキサイティングなニュースは次のとおりです。より多くのオプションが登場し、競争によって LLM のパフォーマンスが向上し、価格が低下するはずです。
• LLM ソリューションを取得して本番環境に維持します (LLMOps)。
  すべての成熟した AI ソリューションと同様に、それらを構築することと、それらを本番環境で取得/維持することは別のことです。LLMOps の分野は、LLM の運用化に焦点を当てています。LLM ベースのソリューションのパフォーマンスを監視し、ナレッジ ベースと検索インデックスを最新の状態に保ち、会話履歴を処理します。LLM
  ソリューションを本番環境に投入する前に、それを維持する方法と実りある状態に保つ方法について賢明に考えてください。ロングラン。

RAGで手を汚す

Retrieval-Augmented Generation の概念に興味を持った場合は、次のことを自問している可能性があります。

RAG ベースのソリューションを試してみるのに必要なものはありますか?

さて、あなたが持っているなら：

• 特定の知識:ワールドワイド Web では簡単に見つけられない有用な情報を含む「知識記事」の適度な (できれば組織化された) データベース (技術文書、オンボーディング ガイドライン、サポート チケットの処理など)。
• ビジネス価値: 意図したユーザーのためにその情報を解き放つことができた場合のビジネス価値の明確な定義

実験として、私たちは最近、この技術を活用して政府職員が議会の質問により簡単に回答できるようにする方法を紹介する小さなデモを作成しました。
この場合、特定の知識は次のもので構成されます。

• フランダースの立法文書のセット
• 過去の一連の議会質問

• フラマン語の知識ベースに基づいて議会の質問に対する回答を自動的に提案することにより、効率を向上させます
• 明示的な引用を通じて透明性とユーザーの採用を改善する

参考文献

• Mathias Leys (2022 年 5 月 9 日) セマンティック検索: 実用的な概要https://blog.ml6.eu/semantic-search-a-practical-overview-bf2515e7be76