Join the Webinar
Loading...
このセッションについて
GalileoのAtindriyo SanyalとZillizのYujian Tangが、RAGとLLM管理について深掘りします。このウェビナーでは、LLMパイプラインと出力品質を向上させるための実践的な知見と手法を得られます。
本セッションは、RAGとLLMのパフォーマンスを最適化するためのフレームワークやツールを探しているデータサイエンティストや機械学習エンジニアにとって、有益な内容となるでしょう。
学べること:
- RAGにおいて、どのような場合にファインチューニングを行うべきか？
- RAGにおいて、どのような場合にベクトルデータベースを使用すべきか？
- ZillizのベクトルデータベースのアーキテクチャとRAGにおけるその役割
- 言語モデルをファインチューニングして精度の高い出力を生成するためのメカニズム
- RAGコンテキストの疎性と関連性を評価するためのメトリクス駆動型フレームワーク
- 定量評価に基づいてコンテンツの疎性を「修正」し、LLM出力を改善するための手法
本日は、えー、本日のセッション「大規模で効果的なRag」、えー、VectorとBeddingsの役割、そしてAttend Atriaのゲストスピーカーをご紹介できてうれしく思います。Sonya、Ottenさん、ようこそ。えー、それでは私がこのプレゼンテーションを始めます。Ottenさんと私、AANが途中でいくつかコメントを入れ、えー、おそらく半分から3分の2あたりで、えー、AANに引き継いで、えー、検索拡張生成の、えー、評価について話してもらいます。では、まず私について少しお話しします。
私の名前はChen Tangです。私はここZillowsで、えー、開発者アドボケイトをしています。横にQRコードがありますので、よろしければそのQRコードをスキャンしてください。私のLinkedInに移動しますので、つながっていただければ、そこでご希望の質問を何でもしていただけます。私のバックグラウンドは主に機械学習とソフトウェアエンジニアリングです。
えー、そしてここ数か月は、基本的に私がやっていることはすべてragアプリの構築です。えー、aan、自己紹介をお願いできますか？はい。えー、本日はウェビナーにお招きいただきありがとうございます。そしてご参加いただいた皆さん、ありがとうございます。えー、私の名前はAthanです。えー、Galileoという機械学習企業の創業者の一人です。私たちは本質的に、モデルをより良く評価し、特に非構造化データ関連のモデルやユースケースを評価するためのより良いフレームワークを提供する事業を行っています。
そしてr a gは確かに、その、えー、そのユースケース全体の非常に大きな部分です。えー、私について少しお話しします。私は現在まで約12年ほど、特に機械学習システムの構築だけに携わってきました。主に、えー、AppleやUberのような、やや大きめの企業向けです。えー、前の10年の初めのころは、Appleで長年過ごし、えー、主に古典的なN L Pのようなことをしていました。私たちが構築したML技術の多くはSiriに取り込まれ、最終的には他の多くのapple、えー、AppleのAIエコシステムにも取り込まれました。
えー、面白いことに、私は、えー、この、N L P向けAPI構築に向けた最初の取り組みの一部でした。えー、それはAppleでのことで、私たちはそれをSiri Kitと呼んでいました。最初のSiriのa p iです。そして、それが2014年に始まったと考えると面白いですね。現時点ではほぼ10年前です。そして、新世代のl l mワークフロー、たとえばr a gワークフローのようなものに対して、非常に多くの類似点を見いだせます。えー、とはいえ、当時の問題は、モデルが今日ほど強力ではなかったことです。えー、私はUberでも長年過ごし、Uberの、えー、Michelangeloチームで構築された最初のフィーチャーストアのアーキテクトを務めました。そして、基本的にUberの機械学習全体のデータ品質を把握することを中心に、多くの仕事をしました。
そしてそれらの学びの多くが、えー、Galileoの創業につながりました。その原則は、モデルを評価することは確かに、非常に大きな、えー、課題であり、より良くモデルを評価するためのツールが不足している、というものです。えー、はい、お招きいただきありがとうございます。えー、このウェビナーを、えー、興味深いものだと思っていただければ幸いです。はい。そして、そこにあるQRコードをまだ、えー、スキャンしていない方は、それはONSのLinkedInですので、LinkedInで彼を見つけたい場合はご利用ください。
えー、ということで本日は基本的にこの5つのトピック、あるいは実際には4つのトピックとデモを扱います。まず、なぜ検索拡張生成を使うのかについて話します。次に、ragアプリをどのように構築できるかについて話します。それから、ベクトル埋め込みの役割について話します。それらが何であるか、どのように取得するか、何をするのかを見ていきます。そして、ベクトル埋め込みを使用してragの出力を評価します。
えー、そして最後にデモに入ります。Tonさんが、えー、Galileoを使って、えー、ragの出力をどのように評価できるかを見せてくれます。えー、では、なぜragを使うのかから始めます。えー、検索拡張生成で私たちが取り組もうとしている本当の点は、大規模言語モデルがあなたのデータにアクセスできないということです。しかしそれだけではなく、その多くは幻覚を起こす傾向があります。
そしてここでは、これをちょっと実演するために、ええと、画像をいくつか選んだだけです、そうですよね？ それで、ええと、ある弁護士がここ数か月の間のどこかで法廷で chat G B T を使い、ええと、架空の判例を引用して、そのことで問題になりました。そして、まあ、あなたは本当にその人にはなりたくないですよね。本当にその弁護士にはなりたくない。ええと、さらに、まあ、学界では大きな話題になりました。学校でも、Chad G B T を使って、引用したり話したりするための偽の記事を作り上げる人たちをめぐって、大きな話題になりました。
ええと、そして私は、ええと、あなたにもこの、ええと、ハルシネーション関連について、ええと、何かクールなことを言うことがあると思います、ええと、 はい、つまり、 私はここ Galileo でここ数か月ずっと、現代のモデルにおけるハルシネーションに深く入り込み、それを解明してきました。ええと、まず最初に、 もちろん、まあ、 r a g はおそらくハルシネーションに対する最初の解毒剤です。 単純に、LLM は時間の中で凍結されているからです。そしてその問題をどう解決するのか？ それらを現代の現実にどう持ってくるのかというと、ええと、R a G を通じてです。ええと、 ええと、しかし、より高いレベルでは、ハルシネーションには、ええと、 多くの次元があります。そして、ええと、 r a g は、あなたが生成するすべての L l m の応答が、何らかの、ええと、非常に具体的なコンテキストに根ざしている必要がある、というこの1つの重要な側面を解決するために設計されているようなものです。そしてそれが、ええと、 vector DBS と r a g ワークフローが提供するコンテキストです。
ええと、 しかし、ええと、ええと、 ハルシネーションの他の次元について話すと面白くなります。というのも、そこには、内在的ハルシネーションがあり、それは、よりクローズドドメインのものですが、 ええと、他にも外在的ハルシネーションがあり、それは、まあ、 こうしたモデルが起こす事実誤認のようなものです。そして、ええと、 非常に興味深いテクニックがたくさんあり、後でそれらをどのように、ええと、検出するかについて共有します。しかし、ええと、ええと、embeddings と、まあ、 vector DB の役割は、正しいコンテキストを取得するうえで極めて重要です。そしてそれはおそらく、まあ、 ハルシネーションに対する0から70%の緩和戦略です。
ええと、はい。はい。だからこそ私たちは、この問題を解決するために VIS を使うことを推奨しているのです。ええと、 では、なぜ LLM がハルシネーションを起こすのかを掘り下げていきましょう。 それから、この問題をどう解決していくかに入っていきます。では皆さんを、ええと、ニューラルネットワークが出てきた、おそらく1970年代まで連れていきます、そうですよね？ つまり、50年代後半から60年代前半にかけて、こうした perceptron というものが出てきました。 本質的にそれらがやっていたことは、何らかのデータを学習することでした。
そして私たちが発見したのは、ねえ、もしこれらの perceptron や neuron をたくさん組み合わせれば、ええと、 より複雑な、ええと、より複雑な関係をモデル化するものを実際に得られる、ということでした。データの中により複雑なパターンがあるわけです。そこでこれを始めたとき、 最初はこれらの neuron のうちの1つだけで行いました、そうですよね？ それは入力を受け取り、それから何らかの bias があります。何らかの計算を行い、それから出力を返します。私たちが進んで、これらを組み合わせ始めると、 これらの、ええと、perceptron や neuron を層に配置し始めたことで、この neural network 構造にたどり着きました。
そして、ええと、 ここにあるこの画像は、3層の neural deep neural network を示す非常に基本的な neural network です。そしてそれが deep と呼ばれる理由は、ここに hidden layer があるからで、 この hidden layer は、ええと、 後で vector embeddings を扱う際の重要な要素として関わってきます。それについては、ええと、後のセクションで扱いますが、ええと、 hidden layer は、この vector embedding、ええと、ワークフローの重要な要素であることを覚えておいてください。ここから、ええと、 私たちは自然言語のための recurrent neural networks へ移行しました、 自然画像処理のために。ともかく、実際に私たちが発見したのは、ええと、 特定の neural network アーキテクチャは、特定の種類のデータにより適しているということです。
以前お見せした基本的なニューラルネットワークのアーキテクチャは、ええと、ご存じのように、基本的な種類のデータに適しています。たとえば数字がたくさんあって、そこから何らかの分類を見つけようとしているような場合です。自然には簡単に挿入しにくいデータを扱うために人気になったニューラルネットワークには2種類ありました。それが、ええと、畳み込みニューラルネットワークと再帰型ニューラルネットワークです。自然言語処理では、再帰型ニューラルネットワークが優れた、ええと、アーキテクチャであることがわかりました。なぜなら、それによってシーケンス、ええと、コンテキストを考慮に入れることができるからです。
ここにこの図が見えますが、図について、またそれを理解することについてはあまり心配しないでください。ええと、この図で注意してほしいのは、この、この、ええと、HT minus one、XT minus one HT xt HT plus one XT plus one、ええと、という部分ですね。つまり、ここにある3つの小さなブロックは本質的に、いくつかのニューロンの出力を自分自身に戻してフィードバックする再帰型ニューラルネットワークを行うと、これらのトークンを時間にわたって追跡する能力、このコンテキスト、これらのシーケンスを時間にわたって追跡する能力が得られる、ということを示していますよね。たとえば、the cat in the hat のような文があったとすると、たぶん私たちは、ええと、cat という単語の位置にいて、XT minus one は、XT は CAT で、XT plus one は Cat N だと見ることができます。そして、進んでいくにつれて、xt には異なる、ええと、単語が入りますが、その周囲の他のものは同じ概念の中に残ります。再帰型ニューラルネットワークの問題の1つは、時間が経つとコンテキストを失ってしまうことです。そしてコンテキストを失う理由はたくさんあります。しかし、おそらく最もよく知られている理由は勾配消失です。
ええと、勾配消失問題というのは、こうした操作をより多く行うにつれて、ええと、変化量、あるいは勾配がほとんどゼロになってしまい、そして、その情報をもう持てなくなってしまうというものです。そこで私たちがこれに対処するために作ったのが、トランスフォーマーアーキテクチャと呼ばれるものです。ここで画面にあるのは、トランスフォーマーアーキテクチャがどのように見えるかの超簡略化した例のようなものです。ええと、しかし基本的に、トランスフォーマーアーキテクチャはエンコーダーを取り、ええと、そのエンコーダーを使って入力を受け取り、それを隠れ状態に変換します。そして隠れ状態というのは、実際には単にベクトルの集まり、あるいは、ええと、ご存じのように、行列のようなものであり、隠れ状態は文、または、ご存じのように、ええと、時間にわたるシーケンスのコンテキスト、およびトークンがどこにあるかという現在の位置、ええと、埋め込みをエンコードします。
次に、このベクトルの集合を行列としてデコーダーに入力します。そしてデコーダーは、自己注意と呼ばれるものを適用する場合もあれば適用しない場合もあります。ここではそれを追加入力として示していますが、自己注意という用語はおそらく聞いたことがあるでしょう。ええと、そしてデコーダーはそれを適用する場合もあれば適用しない場合もあります。たいていの場合、ええと、現在のほとんどのアーキテクチャでは、自己注意を適用します。つまり、隠れ状態、これは行列ですが、それを取り、自己注意、これも行列ですが、それを取り、それらをデコーダーに入力すると、デコーダーは「はい、次のトークンはこれであるべきです」、あるいは、ご存じのように、そのようなものを返します。そして実際、それこそが G B T が行っていることです。そうですよね。つまり G B T はデコーダーのみのアーキテクチャです。
つまり、G B Tに単語を入力すると、実際にはこれがトークンと位置埋め込みに変換され、それによってデコーダーは次のトークンを出力するために必要な隠れ状態、あるいは、ええと、まあ、必要な情報を得ます。ですのでこの例では、G P Tに、まあ、「the chicken walked」と与えると、「across the road」のようなものを生成するはずだとわかります。なぜなら、これはデータの中で、ええと、一般的に、ええと、おそらく最もよく見られると期待されるものだからです、そうですよね？つまり、実際にやっていることは、この次のトークンを予測しているということです。ですので、「the chicken walk」を見たとき、それは「across」を予測していて、「ねえ、acrossが確率的に最も、次に来る可能性が最も高いトークンだ」と言っているのです。だからそれを出力するわけです。つまりG B T、つまりchat G B Tが幻覚を起こす理由は、単語またはトークンの系列を予測するように設定されているからです。
ええと、では次に、ragアプリをどのように構築できるかに進みましょう。ええと、基本的にRAGとは、L L Mの上に独自データを注入し、類似性検索を使って適切なデータを見つけることです。そしてこれは、ええと、Autenが先ほど述べた幻覚のタイプの1つに対して非常にうまく機能します。ええと、Auten、ええと、他のタイプの幻覚についても少し補足してもらえますか？はい、もちろんです。ええと、そうですね、これは、ええと、ここでこれから入っていく内容への良い、ええと、前提になります。
ええと、ええと、なぜならR A Gの重要な目的の1つは、ええと、l mの応答にコンテキストを組み込むことだからです。ええと、ただ、ええと、非常に高いレベルで言うと、ええと、私たちは最新の最先端LMSsにおける幻覚を測定し定量化することについて、社内で非常に興味深い実験を行ってきました。そして私たちは、G P D 3. 5以降のものはすべて最先端のものだと考えています。ええと、私たちの評価哲学や指標の多くは、実際には、ええと、古いG P Tアーキテクチャの一部にはあまり対応していません。なぜなら、ええと、現代のものは単純にもうそうした簡単な間違いをしないからです。
ああ、ええと、そうですね、とても興味深いです。私たちの、ええと、幻覚実験から得られた、ええと、発見のいくつかは、ええと、その1つが、ええと、R A Gの文脈では、ええと、あなたのコンテキストやドキュメントがどれだけ根拠づけられているか、あるいはL L Mの出力が、あなたが提供したコンテキストにどれだけ根拠づけられているか、という考え方があるということです。これはもちろん明らかです。しかし、こうしたワークフローにおける次のレベルの課題は、ええと、モデルがその主張や、その、ええと、その回答に到達するために使った領域を、ええと、具体的にどのように指し示すかということになります。なぜなら、多くのエラーはもう少し抽象的で、ええと、より推論に基づいており、特定のトークンを特定するのが難しいからです。ええと、そこが、つまり、次のレベルの課題であり、どのようにして、まあ、なぜそうなのかについて、ええと、より多くの説明可能性を組み込むかを考えることです。ええと、その答えがコンテキストに根拠づけられているかどうかにかかわらず、さらに一歩進めるにはどうするのか、ということです。ええと、これはR a gの文脈での話です。ええと、よりオープンドメインなユースケースでは、ええと、通常は、まあ、あなたが、つまり本質的に学習しているものに基づいて、コンテキストを使わずに何かに答えることになります。
そして、そしてそのような場合、幻覚は通常、論理的または推論に基づくエラー、あるいは事実上の誤りにより関係している傾向があると思います。ええと、そして、ええと、そうですね、それらが本質的に幻覚の2つまたは3つの次元です。そして私のスライドで、ええと、まあ、L L Mシステム、特にR a Gシステムへの主要な入力と出力についてもう少し話します。それから、ええと、幻覚につながる、入力、コンテキスト、出力において発生する具体的な種類のエラーについて、さらに深く掘り下げていきます。ですが、ええと、ええと、ここではあなたに続けてもらいます。
はい、いいですね。ええ、つまり、その話を後のセッションで聞けるのを楽しみにしています。では、ええと、基本的なRAGアーキテクチャがどのようなものかから始めましょう。ええと、基本的にRAGアーキテクチャを構築するときにやっていることは、「よし、このLLMの上に自分のデータをどう注入するか」ということを考えているわけですよね？ ええと、実際に何が起きるかというと、まあ、この最初のLLMの部分は実は省くこともできますが、私が見る限りほとんどの場合、人々はLLMを使って、クエリをよりクエリ可能で検索可能なものにし、ベクトルデータベース内で意味的に検索できるようにしています。ですが通常起きることは、ユーザーであるあなたがクエリを持って入ってきて、「ねえ、ええと、帽子の中にいる動物は何か知りたい」と言います。するとそれがLLMに行き、LLMは「なるほど、ええと、animal hatを探して」と言います。
それからVISに行き、VISは「ああ、the cat in the hatだ」と言います。そしてそれをLLMに送り返し、LLMはそれを受け取って、「なるほど、これはベクトルデータベースにある中で意味的に最も類似した応答だ。これを人間が読める形にしてあげよう。そして帽子の中にいる動物は猫だと伝えよう」と言いますよね。つまりそれが基本的なRAGアーキテクチャで、単に「クエリを、意味のあるものに分解する。VISのような自分のベクトルデータベースに、ええと、最も似ているものは何かを尋ねる。そしてそれを受け取って、よし、今度はそれを元のクエリに対応させて質問に答えよう」と言っているわけです。
これが基本形です。そして次に進むと、ああ、ここには入れていませんでした。ええと、RAGの基本的なテックスタックについてですが、実は、ちょっとここで一旦止めます。ここに追加したいことがいくつかあるからです。ええと、このアーキテクチャは、ええと、キャッシュレイヤーを挿入することで、実はより良くできます。ええ、もちろんこれは、あなたのRAGアプリに多くの利用があるという前提のもとです。
そしてこれは、私たちが社内で、ええと、OSS Chatを構築したときに実際に見たことでもあります。多くの人が非常によく似た質問をしていたのです。OSS Chatは、このスライドには入っていないと思います。はい、OSS Chatはスライドデッキにはありませんが、ええと、OSS chat.ioは、オープンソースソフトウェアについて質問するために行けるサイトです。私たちはこれを構築し、そして「ねえ、わかるでしょう、多くの人がとても似たような質問をしている」と気づきました。
もしかすると、応答、質問と応答をキャッシュできるかもしれません。そうすれば、ユーザーはより速く、より良い体験を得られるだけでなく、OpenAIのLLM APIエンドポイントを常に呼び出さなくて済むので、私たちもコストを節約できます。ええと、つまりそれが私たちが見つけたことで、わかるでしょう、それはまさにここに位置します。基本的に、クエリがLMやOrvisなどに行く前に、それをキャッシュに送り、答えがあるかどうかを確認します。ですから基本的なRAGのテックスタックはこのようになりますよね？ Chat CTやその他のLLMがありますよね？ ええと、Llama、Falcon、何でも。そしてベクトルデータベースがあり、さらに、ええと、何らかのフレームワーク、何らかのprompt as codeフレームワークがあります。
そして、ええと、これをコンピューターのように考えることができます。コンピューターの中には、プロセッサ、CPU、つまりコンピューターが多くの操作を実行できるようにする何かがあります。そしてさらに、ええと、ROM、ハードドライブがありますよね？ それがコンピューターに記憶を保存させるものであり、そこがVISのいる場所です。そして、これらすべての異なるコンポーネント間でやり取りできるようにし、同時にコンピューターとやり取りできるようにするものがあります。そこにHaystackやLangChain、あるいは、わかるでしょう、その他のprompt as codeのオーケストレーションフレームワークが入ってきます。そして、ええと、このアーキテクチャがこのように見える理由は、検索拡張生成を行えるようにするための中核的な推進要因の一つが、この類似性検索、この意味的類似性検索を実行できることだからです。ですよね？ これは本質的に、ええと、ベクトルデータベースが機能として提供しているものです。
では、類似性検索では何が起こるのでしょうか。あなたは自分のデータを持ってきます。それはどんな種類の非構造化データでもかまいません。画像、動画、ええと、音声、P D F C S V、何でも、適切なベクトル埋め込みモデルがある限り可能です。そしてそれが、ここでの1から2へのステップです。適切なベクトル埋め込みモデルがある限り、どんな種類のデータでもベクトルに埋め込むことができ、それをベクトルデータベースに保存します。そしてクエリ時、質問をするタイミング、プロダクトレコメンデーションを行うタイミングなどになったとき、RAGの文脈では、質問をするタイミングになります。もう一度、質問の対象にできる、ええと、どんなデータであれそれを取り出します。
もしかすると、文に変換したい画像があるかもしれませんし、単に文があって質問したいだけかもしれません。そして以前使ったのと同じモデルを使って、ええと、ベクトル埋め込みを取得します。そしてこれは非常に重要で、同じモデルを使うか、少なくとも何を測定しているかに応じて同じ次元を持つものを使う必要があります。ええと、なぜならベクトル類似性は実際には、同じ次元のベクトルに対して行って初めて意味を持つからです。ですから、これは重要なステップです。同じモデルを使っていることを確認したいのです。
それらのベクトルが得られたら、そのベクトルをベクトルデータベースに入力し、ベクトルデータベースは近似最近傍探索を実行します。これは本質的には、いわゆる類似性検索であり、次のセクションでそれがどのようなものかをある程度取り上げます。このスライドから理解してほしいのは、ええと、本質的には、どのようなステップなのか、ここで起こっているワークフローは何なのか、ということです。そうですよね。したがって、近似最近傍であるベクトルが得られると、その結果を取得し、それから l l m が再び、ええと、その結果を人間が読めるものに変換して、あなたに返します。つまりここでのポイントは、RAGアプリはコンピューターのように構築でき、計算には L L M を使うということです。これがあなたの C P U、G P U であり、ストレージにはベクトルデータベースを使います。
つまりそれがあなたのハードドライブです。ええと、あなたの ss、あなたのソリッドステートドライブ、ええと、そしてコードとしてのプロンプト、つまりインターフェースであり、物事がどのように互いに通信するか、ということです。そうですよね？これが主なポイントです。ええと、L L M、ベクトルデータベース、何らかのプロンプティングです。では、ragにおいてベクトル埋め込みの役割は何でしょうか？これは短いセクションになります。これが私が扱う最後のセクションになり、その後、評価についてはOttenに引き継ぎます。実際、あなた、Yj、ええ、はい。
この前のスライドに戻ってもらえますか。ここで聴衆の皆さんに、ちょっと興味深い点を強調したいだけです。はい。ええと、この図の最初の部分、左側は非常に興味深く、非常に重要です。なぜなら、それは私に、ええと、私がこれまでのキャリアで取り組んできた、より複雑な、ええと、埋め込み生成技術のいくつかを思い出させるからです。特にレコメンデーションシステムに関してです。ええと、ええと、そこでは例えば、単に sentence transformers を使って埋め込みを作成し、それを vector store に保存するのではなく、より複雑なモデルアーキテクチャがあります。例えば two tower アーキテクチャのように、ユーザー埋め込みとアイテム埋め込みを本質的に扱うことができます。たとえばショッピングサイトの場合です。
ええと、私たちの場合、私自身の経験では、Uber Eats のためにベクトル検索エコシステム全体を構築しました。そこでは、Uberアプリ上でのユーザーアクティビティから、ええと、埋め込みを作成していました。ええと、実際、Stanford の人たちと一緒に書いた、ええと、ワークショップ論文があります。ええと、私が書いたものです。ええと、feature stores for embeddings で Google 検索してもらえれば、うまくいけば出てくるはずです。しかしそれは、具体的には、ある種の埋め込みは動的な性質を持っており、システムとやり取りするにつれて時間とともに変化する、ということについて説明しています。
ええ。ショッピングアプリの場合で言うと、つまり、あなたは、その、アプリを使っていて、クリックを生成していて、埋め込みを動的に進化させているわけです。ですから、この図の左側は、ええと、このことをある程度強調しています。つまり、より複雑なワークフローで、埋め込み管理システムがあり、それがユーザー向けのより新しい埋め込みを絶えずキュレーションしていて、ええと、それが最終的にベクトルストアに保存されます。ええと、ただ、ええと、非常に興味深い新しい r a g のユースケースがいくつか出てきていて、それは多くのお客様との議論からも、さらにそれ以外からも出てきているのですが、こうした種類の埋め込みを使いたい場合があります。それは必ずしもテキスト埋め込みではないのですが、それをマルチ、ええと、マルチモーダルモデルと結びつけて、ユーザー活動のテクスチャ表現を生成し、それが最終的にベクトルストア内の別のインデックスに保存されます。そしてそれが L L M への入力として機能し、ええと、より複雑なワークフローにつながります。
しかしそれによって、非常に、いくつかの非常に興味深い問題を解決できます。そこでは本質的にユーザー活動をテクスチャ化しているのです。ええと、私の友人の何人かは、ええと、Airbnb のフィーチャーストアである Zipline を構築しているのですが、彼らはこうしたアイデアを探求しています。つまり、ええと、本質的にユーザー活動のテクスチャ表現を作成し、その後ベクトルストアを使って、ええと、L L M のコンテキストを拡張するのです。そして、ええと、ユーザー活動に関する非常に興味深い分析や要約を生成できます。そして私は、これは出てきつつある非常に興味深い新しいユースケースだと思っていて、r a g ワークフローには、可能性は無限にあると見ています。ええと、これはその一例にすぎません。
ああ、なるほど。それは本当に面白いですね。それについては聞いたことがありませんでした。なので実は、今すぐそれについてもう少し掘り下げてもらおうと思います。ええと、では、その変換側、左側についてですが、人々が取り組んでいる、あるいはすでに存在しているかもしれない方法があって、ええと、アプリ内で今起きているようなライブなものを取り込む、ということを言っているのですね？ 何らかの、よくわかりませんが、これは何か、その、起きていることの特徴量のようなものなのでしょうか。そしてそれをベクトルストアに変換して保存し、クエリ時には、同じユーザーに対して再びそれを行える、ということなのでしょうか。それともクエリ時には何が起きているのでしょうか？ええ、いえ、まったくその通りです。
つまり本質的には、ええと、たとえば多くの聴衆が知っているかもしれない two tower architecture のような確立されたアーキテクチャがあります。ええと、ただ、ええと、two tower architecture についてはぜひ読むべきです。そこでは本質的に、ええと、たとえばユーザー、アイテム、データウェアハウス内にある任意のエンティティから、ええと、特徴量を取り出し、その特徴量から、ええと、ベクトル表現を作成します。そして出力、そのベクトル自体が two tower deep learning model の出力です。ええと、しかしそれは、ユーザー活動のようなより抽象的なものを表現する非常に効率的な方法であることが証明されています。そして、同じようにあなたのシステムと相互作用している人々をクラスターにまとめることができます。なぜなら、それらの埋め込みは同じ空間内で対応してくるからです。
ええと、しかしそれらを言語モデルに活用することが、この新しい r i g ワークフローの方向性であり、今まさに生まれつつあるものです。わあ。なるほど。それは本当に面白いですね。その論文は読んだことがないので、確認してみます。
ええ。ええ、Google で、ええと、feature stores for embeddings と検索してみてください。そうすれば、ええと、出てくるはずです。古い論文ですが、ええと、本質的には、私たちはこの来たる波を見てそれを書きました。ええと、埋め込みの重要性や、数年前に私たちが解決できた問題のいくつかによって、ベクトルデータベースがはるかに重要になるという波です。ええと、ただ、ええと、G P T や、ええと、LLMs の登場によって、これが、これがどのように現れてきたのかは非常に興味深いです。ええ。
はい。ええと、わかりました。では、ベクトル埋め込みの役割と、ツインタワー法、ええと、ツータワー法を使う以外にそれらをどのように取得できるかについて簡単に話し、その後、評価について話すために引き継ぎます。ですので、従来、ほとんどの場合、ベクトルは何らかのディープラーニングモデルから得られます。基本的には、ナレッジベースを取り出します。これは、先ほど言っていたように、画像、動画、テキスト、音声、必要なものであれば何でもよく、それをディープラーニングモデルに入力します。
ええと、resnet や sentence transformers のようなディープラーニングモデルの場合、ええと、mini lmm のようなものでは、ええと、埋め込みを取得するために行うことは、実際には最後の層を切り落とすだけで、そして、出力は何か、というものを得ます。それがベクトル埋め込みです。そして、これらの出力は、モデルから見たこの入力の内部的な意味的／数値的表現です。そして、そのベクトルを取得したら、Zillow や Viss のようなベクトルデータベースに保存します。では、この種のものをどのように評価するかに入る前に、ベクトルで意味的類似性がどのように機能するかについて、この簡単な、チュートリアル的な要約、基本的なコメントを残しておきたいと思います。そして、このスライドから得てほしい基本的な考え方は、ベクトル埋め込みを使うことで、もともと数字ではない単語や画像、あるいはその他あらゆるものに対して数学を行えるということです。
ええと、また指摘しておきたいのは、実生活では二次元ベクトルを見ることは決してないでしょうし、実生活でベクトル指標としてマンハッタン距離を使っている人を見ることも決してないでしょう、ということです。ええと、しかしこれは概念を伝えるための完全な例です。では始めましょう。ここで示したかったのは、単語 queen 0. 3 0.
9 から単語 woman、0. 3、カンマ 0. 4 を引く、ということです。さらに、それは、ほら、この 0. 5 を与え、そして単語 man、0.
5 0. 2 を足すと、ええと、点 0. 5 カンマ 0. 7 に到達し、それは king に対応します。そして、ええと、ここで他にもいくつか注意したいことがあります。ええと、重要なのは、ほら、見てください、queen と woman は最初の、ええと、次元において同じ値を持っている、ということを見ることです。
そして、それが私たちに示しているのは、これらの単語がその最初の次元に沿って同じ意味を持っているということですが、その次元が何を意味するのかは教えてくれません。その次元が何を意味するのかについては何も教えてくれません。これらの単語が両方とも5文字であり、それがこの次元に沿って同じ値を持つ理由である可能性もあります。それは必ずしもその次元が何を意味するのかを教えてくれるわけではありません。ただ、それらがその次元に沿って同じ、ええと、値を持っているという意味です。
もう一つ指摘したいのは、ええと、queen と king、そして、ええと、woman と man は、ええと、X軸とy軸に沿って同じ値だけ異なるということです。そしてそれが意味するのは、これらの単語がその次元に沿って同じ関係を持っているということです。適用される変換が何であれ、queen から king への変換は woman から man への変換と同じです。ですから、それが基本的に私が、あなたに指摘したかったことであり、ただ、ねえ、ベクトル埋め込みを介して、もともと数字ではないものに対して数学ができる、という考えを理解してほしいのです。それでは、あなたにお渡しします。画面共有を停止しますので、ええと、あなたが画面を共有できます。
いいですね。わかりました。ええと、では、ええと、このセクションでは、ええと、非常に、はい、ええと、私たちが会社として非常に、非常に重要だと考えているものを取り上げようと思います。ええと、あらゆる機械学習ワークフローにおける実践としての評価です。そして、Galileo を設立した全体の、ええと、基盤は、より良い評価指標が必要だということでした。ええと、そして精度測定などに使う従来の指標は、ええと、必要ではありますが、十分ではありません。
それらはあらゆる種類のエラーを同じように扱います。そして、ええと、それらは、大きなエラーと悪いエラーを区別することができません。また、多くのエラーは本質的にデータに帰着するという事実もあります。ええと、私たちは基本的に、現代的な ML ワークフローのための新しい種類の指標を作成する事業に携わっています。そして L L M ワークフロー、r a g ワークフロー、Vector DB ワークフローは、ええと、出現したこの新しいワークフローです。
それでは、R A G ワークフローの全体的な健全性をどのように評価するか、そして具体的にどの部分を見るべきかについて話します。ええと、これは非常に高いレベルで、ただ、ええと、この重要性と、本当に何を評価すべきかについての理解を組み込むためのものです。ええと、これは R A G ワークフローの 10,000 フィートから見た概観です。ええと、ここでは、ええと、左側にプロンプトまたはクエリがあり、もちろん右側には、ええと、L L M の出力があり、そして、ええと、vector dbs が埋めているギャップは、本質的にはコンテキストを組み込み、必要なものに非常に関連性が高く類似したコンテキストを組み込むことです。そしてもちろん、zills や VUSs のような技術を使えば、それを大規模に実現できます。
ええと、しかしこのワークフローでは、ええと、多くの疑問が浮上します。そして、ええと、これらは本質的に実務者にとっての未知の要素です。そして通常、問われる質問はプロンプト側に関するもので、ええと、あなたのプロンプトが望ましい l l m の結果を得るのに適切かどうか、ええと、ドキュメントまたはコンテキスト側、つまりベクターストアから取得されるデータについてです。ええと、そのドキュメントは関連性があるのか？ドキュメントは埋め込み空間の疎な領域から取得されているのか？ええと、これらのドキュメントは望ましい結果を得るために関連性があり、最も理想的なのか？ということです。なぜなら最終的には、アプリケーション開発者であれ、モデルのファインチューナーであれ、モデルから最良の出力を得ようとしているからです。そして、L l m の出力を調整するために調整できるノブがいろいろあります。ええと、ですから、目にしているこれらの問題のいくつかを定量化することが非常に必要になります。
ええと、出力側ではもちろん、ハルシネーションという大きな問題があります。これは、ええと、検索拡張ワークフローの文脈では本質的に、ええと、モデルがクエリに答えるためにコンテキストをどれだけ使ったか、そして、ええと、ドキュメントのどの部分に回答が、ある種、根拠づけられていたのか、ということに帰着します。ええと、そこで私たちは、これらの問題のいくつかをメトリクスとして較正し、ええと、定量化しました。そして、ええと、これらのいくつかについて話し、また非常に単純な r e g ワークフローで、ええと、これらのメトリクスのいくつかもデモします。まず説明すると、ええと、プロンプト側には、prompt relevance があります。これは、プロンプト、またはクエリの、L l M の出力に対する pance の定量化です。
ええと、ドキュメント側には、ええと、疎性について話しましたが、ええと、疎性についてもう少し深く掘り下げると、ええと、それがなぜ問題になり得るのか。ええと、あなたの vector store は本質的に、ええと、ドキュメント集合全体の埋め込みを保存します。これは、あなたの l l m のシラバスのようなものと考えることができます。ええと、そしてもちろん、それらのベクトルは埋め込みであり、元のドキュメントから派生した表現です。しかし Ujan が言及したように、埋め込みの面白いところは、それを使って数学的な操作ができることです。そして、ええと、それらは非常に、非常に、ええと、まとまってクラスター化し、生データについて、そうでなければ得られなかった洞察を与えてくれます。
ええと、でも埋め込みを使った典型的な操作といえば、もちろん、ご存じのとおり、次元削減とクラスタリングで、ええと、それらはこの終端の次元空間にマッピングされるようなものです。ただし、その空間は密にも疎にもなり得ます。それは、ご存じのとおり、ベクトル TB に入れるドキュメント全体の集合や、その疎密、そしてコンテキストやドキュメントを取得する領域の疎密によって、L L M の出力に大きな違いが生じ得ます。ええと、つまり疎性とは本質的に、データを取得した埋め込みの領域がどれほど密か、または疎かを測る尺度です。ええと、その先には、ドキュメントの関連性があります。たとえば、先ほどアトリビューションやアクショナビリティについて話していたようなことです。何かを良い・悪いとして定量化すること自体は一つのことですが、ええと、そこから次の一歩をどう踏み出すのか、ということです。そして、ええと、r a g ワークフローの場合には、ええと、出力の中にエラーを検出した場合、ええと、あるいは幻覚や出力のエラーを検出した場合、ええと、その目標、というか最初のステップは、ご存じのとおり、そのエラーをある程度定量化することです。つまり、出力があなたの、ええと、ドキュメントにどの程度高いレベルで、どの程度根拠づけられていたか、ということです。
しかし、さらに具体的には、ええと、ご存じのとおり、モデルが、ええと、回答に向けて考慮したドキュメントのどの領域か、ということです。うーん、なので doc relevance は、そうした定量化の、ある種の尺度であるメトリクスです。そして最後に、主なものは、L L M の出力、つまりそれが幻覚したかどうかです。これは、ええと、groundedness と呼ぶメトリクスを通じて話します。今のところそう呼んでいます。これはかなり単純化されたメトリクスですが、ええと、これを測定するために使っている手法は Galileo の groundedness です。そして私たちは、ええと、ええと、ええと、非常に、うーん、非常にニュアンスのある思考の連鎖を使って、なぜ何かがドキュメントに根拠づけられているのか、あるいはなぜそうでないのかを推論できるようにしています。ええと、そして、ええと、それが非常に効果的な手法であることが分かりました。
うーん、実際、ええと、ここ数か月にわたって私たちが行ってきた多くの幻覚関連の取り組みについて、少しだけ簡単に強調しておくと、ええと、本質的には、私たちは、ええと、15 を超えるデータセットをキュレーションしてきました。ええと、ええと、多くの種類の異なる l m タスクにわたって、ええと、世界中の専門家に、ええと、ご存じのとおり、何千、何万ものデータポイントを確認してもらい、それらを、ええと、うーん、幻覚しているかどうかとしてラベル付けしてもらいました。ええと、そしてこれらはドメイン専門家であり、ええと、ええと、私たちの実験では、ええと、先ほど話していたこの思考の連鎖手法によって groundedness の判定を行いました。それは、うーん、85% を超える、ええと、a u c スコアを示しました。これは 85% の精度であり、これらの人間が注釈した幻覚専門家との一致を意味します。ええと、なのでデモでもそれに少し触れるつもりですが、強調しておきたかったのです。
ええと、ではそれを、ええと、最初に見た元のワークフローに結びつけると、ご存じのとおり、不足しているピースは本質的に、ええと、このアルゴリズム的な評価と定量化だけなのだと思います。そしてそれはループですよね？つまり、何かを見つけ出し、それからクエリに戻り、クエリを調整し、ドキュメントを調整し、モデルの理想的な出力へと自分自身をファインチューニングするまで、それを繰り返すのです。ですから、R a g のために見た単純なワークフローに、いくつかのコンポーネントを追加しているだけです。では、うーん、話は十分です。デモに入りたいと思います。そして、ええと、ここで時間を確認しておくと。
ええと、大丈夫です。9時40分なので、ええと、全然問題ないはずです。素晴らしい。よかったです。ええと、ではデモについてですが、高いレベルの文脈だけお伝えすると、これは、ええと、ええと、アイデアを伝えるためのかなりシンプルなデモです。ただし、同じ原則をより複雑な r i g ワークフローに適用するには、ぜひ想像力を働かせてください。
しかしこのデモでは、あなたがQ&Aシステムを構築しているデータサイエンティストだと想像してください。あなたの目標は、この質問応答マシンを構築することであり、それは入力の一部として提供されるドキュメントに基づいてのみ回答し、外部情報には一切依存しません。つまり、このループの中にこのL L Mがあり、それは事前学習済みモデル、または非常に強力なG P T 3. 5または4レベルのモデルによって支えられた何らかのA P Iです。そしてあなたは、このI d Gワークフローを構築しようとしており、提供するドキュメントだけにモデルの出力を制限しようとしています。これはさまざまな理由による可能性があります。あなたがFinTech企業やヘルスケア企業で働いていて、一般的な情報や、そのような類のことを開示することが許されていない場合などです。
しかし私は、このl mアプリを構築しているデータサイエンティストまたはプロンプトエンジニアです。私は、ええと、vusを使います。ですので最初に行うことは、ここでpy milを含む一連のライブラリをインストールすることです。そして、それを行ったら、ここで環境変数を設定します。主要なコンポーネントに移ると、わかるように、私の目標の1つは、元のデータまたは私が持っているドキュメントのために、ええと、埋め込みを生成することです。
この場合、私はsentence transformerを使っています。これは単純なBERTベースの埋め込みのようなもので、hugging faceのコード1行で非常に簡単に生成できます。そして私は、そのtransformerモデルを使って、ここでドキュメントの埋め込みを生成します。私はmillwareストアを初期化しています。そして、この特定のコード片は、本質的には、r a gシステムへの入力であるクエリを入力として受け取ります。そしてもちろん、milが提供するm similarメソッドを使用します。
そして、私たちはそれらの埋め込みを取得し、ここではデモでわかるように、それを本質的に単純なデータフレームに連結しています。ここでのデータフレームには、入力の質問が含まれています。たとえば、「vector embeddingsを説明して」「買うのに最適なスマートフォンは何ですか？」「machine learningとは何ですか？」といったものです。これはQ&Aシステムです。したがって、これが元の入力です。そこには、テキストのコンテキスト、実際のドキュメントチャンク、ベクターストアから取得された同じものの埋め込み、そしてsentence transformerから生成されたクエリの埋め込みがあります。私はそれらすべてを、単純なデータフレームにまとめます。
さて、プロンプティングを行うので、プロンプトを定義します。そしてここに、プロンプトの一例があります。通常、実験フェーズでは、これからお見せする評価指標に主に基づいて、プロンプトに対して多くの異なる微調整や変更を試していきます。しかし、これは1つのプロンプトの例です。つまり、あなたはモデルに対して、自分が専門的なQ&A担当者であることを伝えますが、以下のコンテキストに基づいてのみ回答してほしい、そしてコンテキスト外のものを直接参照しないでほしいと伝えます。ただし、「コンテキストに基づくと」のような表現も避けるようにします。
つまり、ここではプロンプトを通じてモデルを誘導しています。しかし本質的には、このコンテキストを提供しています。Galileoでは、R A Gの存在を検出するためにcontextをキーワードとして使用し、特定のr a g固有の指標をあなたのためにキャリブレーションします。それはすぐにお見せします。また、GalileoではPythonライブラリを使って、関心のある具体的な指標を上書きすることもできます。
つまり、グラウンデッドネスとコンテキスト関連性だけに関心がある場合は、それを提供します。ええ、もちろん可能です。ええ、ほかにも多数のメトリクスがあります。ええ、それらが表示されるはずだと思いますが、その、その、その、ええ、その、その、これは何だろう、えっと、ノートブックが接続されていないので、表示されていません。でも、私たちの scorers ライブラリには多数のメトリクスが表示されるはずです。えっと、この場合、私は一般的なメトリクスのキャリブレーションを上書きして、主にこの2つを返すようにしています。ええ、RAG ワークフローでは、ええ、自動的に含まれる特定のメトリクスがあります。
グラウンドトゥルースがある場合、ベースラインがある場合、私たちは、ええ、通常よく使われるものを提供します。ええ、不確実性も、私たちのシステムにある興味深いメトリクスの一つです。これは基本的に、えっと、LLM が自分自身の出力においてどれだけ混乱しているかを測定します。その方法として、モデルが吐き出すトークンにおけるエントロピーを追跡します。そして、ええ、それによって、モデルがどこで確信を持てていなかったのか、どこで確実だったのかがよくわかります。
はい。そして私たちの実験を通じて。こうした最新の、ええ、ご存じのような、これらのマシンについて見られた興味深いことの一つは、ええ、彼らはしばしば、ええ、話し始めるとき、最初のトークン群を吐き出し始めるとき、ウォームアップしているような感じで、エントロピーが非常に高いことが多いということです。そして話し始めるにつれて、あるいは、すでにある程度蓄積したアテンションに基づいて、さらに多くのトークンを吐き出し始めると、ええ、エントロピーは徐々に下がっていくようです。ですから、これらのモデルの内部的な挙動を見るのは非常に興味深いのですが、それもまた私たちが提供するスコアの一つであり、出力における混乱度をよく把握できます。
えっと、わかりました。ええ、メトリクスと、プロ、ええ、テンプレートを定義したら、ログインして、ええ、PQ dot login を使います。PQ は prompt quality の略で、私たちの Python ライブラリです。ですので、pip install prompt, quality をインストールし、prompt, quality を pq として import すると、これを実行できます。ええ、自分の、つまり hosted Galileo 環境に、たった1行のコードでログインできます。そして、さらにもう1行のコードで、RAG ワークフローを実行できます。ここで、私たちの場合は、プロジェクト、先ほど私がキュレーションしたテンプレート、ええ、ベクトルストアからのコンテキストを持つデータフレーム、関心のあるメトリクスのセット、そしてクエリしたいモデルを指定しています。つまりこれは基本的に、実験を定義するための、あなたの実験用のコード行ということです。そうですよね？
ええ、これは単一の実験にすぎません。もちろん、私たちは sweeps と呼ぶものを実行できるようにしています。これは、モデルのベクトル、または、または、モデルの領域、ハイパーパラメータの領域を取り扱えるようにするものです。そして裏側で興味深い最適化のようなことを行い、ええ、一連の実行をバッチで行います。ええ、それではここで、これを実行すると得られる出力に入ります。ワークフロー全体を実行して、ええ、移動先となるこのリンクを返します。すぐに行きます。ええ、ただ、データも提供していることがわかると思います。オブジェクト自体、prompt metrics の Python オブジェクトです。
つまり、そこには hallucination の数値、つまり幻覚がどの程度定量化されたか、そしてレイテンシやコストなどのその他の情報があります。ですから、文字どおり Python だけを使ってシステム全体を構築できます。つまり、ええ、ええ、オブザーバビリティシステム全体を構築できるのです。なぜなら、これらすべてのメトリクスが最初から得られるからです。ええ、デモそのもの、あるいはコンソールに入る前に、ええ、この実験フレームワークに対する興味深い拡張について少し強調したいと思います。私たちが取り組んでいるものです。えっと、通常、実験では、私は異なるテンプレート、ええ、異なる種類の、えっと、ご存じのような入力を使い、より良い出力を得るためにプロンプトを微調整することについて話していました。
しかし、r a G ワークフローでは、異なる embeddings を活用することもできます。ええと、ご存じのように、vector dbs では異なるインデックスを保存でき、そこに異なる embeddings のセットを保存できます。ええと、ここで私たちがやりたいのは、vector store の上に実験のレイヤーを提供することです。そこでは基本的に複数の embeddings を取得できます。ええと、生成できます。たとえば、sentence transformer で1つ生成し、別の two tower モデルでもう1つ生成して、どちらがよりうまく機能するかを見たい、ということです。ええと、私たちは現在、私たちの A P I の新しいバージョンに取り組んでいます。それにより、これらの変換メソッドを上書きでき、embeddings を生成する方法を1つ、あるいは複数指定できます。そしてそれらをある種つなぎ合わせて、ここにあるこれらの関数のような transform を提供します。
そして裏側では、この ab 実験を行い、ええと、どれがより多く hallucinate したか、またはどれがより少ない hallucination につながったか、などをお知らせします。そうですね、この Python コードを通じて、Vector db を使った非常に高度な実験を実行できるという考えを組み込みたかっただけです。しかしこれを実行すると、このリンクをクリックし、ここに移動します。そしてこれはもちろん Galileo ui です。そして、ええと、あります、ええと、大まかには、そうですね、ええと、すみません、これがあなたが行った1回の実行です。ええと、そして、ええと、私の data frame に戻ると、その single run は3つのクエリをテストしていますよね？ええと、vector embeddings の説明があります。
買うのに最適な phone は何ですか？これらが私がテストしているものです。ですから、これをクリックすると、ええと、私が作成したその3つのクエリが表示され、全体を Stitch Together したバージョンが表示されます。ええと、なので最初から、評価プロセスを始めるときにやりたいことは、これらのトップレベルの metrics を見ることです。そして、ええと、すでに見えることの1つは、aggregate uncertainty が少し赤になっていることです。少し、ええと、ええと、高めです。ええと、0. 36 は低く聞こえるかもしれませんが、私たちは standard deviations を使っています。
ですから赤は悪いという意味です。ええと、しかし同時に、relevant context relevance が、これは r a G metric で、私が関心を持っていたものですが、やや低めであることもわかります。何かがおかしいです。理想的には 0. 9 から 1 の間であることを期待します。ええと、そしてここで、ええと、最後の列でわかります。もし私が、ええと、ここで見えるように、requests の1つが明らかにそうではありませんでした。それには grounding の問題がいくつかありました。
ええと、ええと、ここに culprit があり、これはやや低い、ええと、relevance です。ですからこれをクリックできます。ええと、そしてすぐに使える評価用の metrics が多数あります。私が強調したい主なものは groundedness metric です。ええと、これは先ほど言ったように、chain of thought を、ええと、使って、モデル自身が自分の回答が grounded されているかどうかを判断できるかを見極めるものです。ええと、なぜなら、私たちの実験から得た気づきの1つは、これらのモデルは、そもそも error を起こさないことについてはあまり得意ではないことが多い一方で、自分が error を起こしたと気づくことについては得意だということです。
ですから、いろいろな方法があります。ご存じのように、prompting でできるトリックがあり、re model に自分自身の間違いを気づかせることができます。これは非常に興味深い例です。では input を見てみましょう。ええと、あなたの expert q and a system、ああ、これはもう説明しました。ここで私が尋ねている question は、買うのに最適な phone は何ですか？そして context information、vector store から fetched されたものですが、ええと、それには moto colon mobile net の advantages と書かれていました。
ええと、このモデルが優れている理由はいくつかあります。ええと、この場合は Vector DB から取得された、いくつかの、いくつかのランダムなテキストで、ここでは明らかに、ほら、この種の質問、つまり「買うべき最高の携帯電話は何か？」にモデルが答えるのは難しいだろうと分かります。そしてここで、LLM の出力が mobile net だったことが分かりますが、ええと、人間の読者からすると、考えてみれば、それは実際には答えではありません。単に「moto の利点は mobile net です」と言っているだけのようなものです。ええと、それは本当に買うべき最高の携帯電話ではありません。そこで groundedness によって、その推論を自動化しました。ここではゼロと表示されており、これは否定的で、そこにマウスを合わせると、「買うべき最高の携帯電話」という問いに対する回答が mobile net だった、という理由が表示されます。
しかし、この主張を直接裏付ける情報はコンテキスト内に提供されていません。Moto の利点と欠点に言及しているだけです。特定の携帯電話を比較してはいません。ええと、そしてその回答はドキュメントによって裏付けられていません。つまりこれは、ええと、私たちの RAG メトリックである groundedness がここで機能しているということで、それを自動化したのです。
そして、ほら、これを大規模に行うことを想像してみてください。評価において、ええと、どれほど大きなレバレッジが得られるか。ええと、それ以上に、他のいくつかの点も強調しておきたいです。たとえば、ええと、LMM の不確実性が最初から得られます。この場合、以前お伝えしたように、モデルは最初、少し不確かそうに始めたことが分かります。彼らはたいていそうします。ええと、でも面白いのは、ええと、その回答自体、mobile net と言ったときには非常に自信があったことです。
つまり、非常に自信過剰に間違った答えを出したわけですが、私たちはそれに、ほら、自分自身の間違いを認めさせた、と言えるでしょう。そして、ええと、その回答が間違っていたことを突き止めることができました。ええと、これは本質的に、ええと、単一のワークフローを評価しているものです。もちろん、もっと多くのことができます。ええと、たとえば複数の実行がある場合です。いろいろな方法で、そうですね、ほら、比較できます。複数の実行があれば、compare runs を押すことができ、それがこの列形式のビューに読み込まれます。そこで、ほら、基本的にこれらのものを有効にできます。
そして、ほら、これらの応答を見ることができ、AB 評価を行う非常に簡単な方法です。そして最後に、勝った実行を決めたら、この場合は 1 つだけですが、Galileo はこれを勝者として提示しました。これを選択して、それから書いて、ここをクリックすると、ええと、そのワークフロー全体のコードを基本的に取得してコピーし、Python 環境に貼り付けることができ、そのままプログラム的に実行されます。とても超高速な Blitz Creek 的なデモです。もちろんここにはもっとたくさんあります。
ええと、そして、ええと、これが Galileo を使って、現代の LLM、現代のプロンプトワークフロー、そして現代の RAG ワークフローの迅速な実験と非常に精密な評価を行う方法です。ええと、uja にお返しします。最高だね。うん、そこまで踏み込んでくれてありがとう。本当に面白かったし、聞けてよかったです。
どうやらたくさん質問が来ているようです。ええと、これは、これは素晴らしいですね。私たちには、ええと、数分しかありません。これらの質問すべてに答える時間はないと思います。なので、私がやることは、ええと、この QA にあるいくつかの QA 質問に答えてみることです。
それから、皆さんの多くがチャットで質問を送ってくれているのは分かっています。ええと、私たちにできることとしては、もし答えてほしい質問があれば、単に、その動画をアップします。YouTube に載りますので、YouTube で質問できます。ええと、LinkedIn にも載ります。私たちにメッセージを送ってもいいですし、投稿を作って私たちをタグ付けして質問しても、何でも構いません。ええと、でもすべてに対応することはできません。
なので、私は黙って、今から質問に取りかかります。ええと、では 1 つ目は「幻覚へのフォーカスは見当違いではないか。より重要な問題は、NLP アプリケーションに非公開の機密情報を含める必要性ではないのか？」です。ええと、これは私宛てだと思いますが、フォーカスは見当違いなのかと言うと、分かりません。ええと、そうかもしれません。でも、ええ、そうですね。
RAG の重要性は、それによって、ええと、この非公開の機密情報を証明し、提供できることです。ええと、ここにはいくつかニュアンスがありますが、これを使って、ええと、ご存じのように、l l M が答えをでっち上げるのを止めることもできます。それがハルシネーションの部分ですよね？つまり、ここにはその両方が少しずつあります。ええと、それから、もしローカルのナレッジベースに関心のある情報がすべて含まれているなら、それをクエリに含めてファウンデーションモデルに送信する利点は何でしょうか？ええと、通常は複数の回答、ええと、返ってくる複数のものをある程度組み合わせたいのです。そして、それが人間にとって読みやすいものであることも確認したいのです。ですから、ベクトルデータベースから回答を取得し、それから lmm を使ってそれを扱う目的は、それが実際にあなたの質問に答えるようにすることです。質問の表現が異なる場合、どのようにキャッシュするのでしょうか？ええと、ベクトル埋め込みが一定の距離内にある限り、そしてそれは実装者であるあなたが決めることですが、ええと、「これは十分近い、この回答を返そう」と言うことができます。
N L P で r n N を使うことは、今では時代遅れと見なされ、LLM に置き換えられているのでしょうか？ええと、つまり、完全にそうではないかもしれませんが、私が見てきた限りでは、ほぼそうですね。ええ、ええと、つまりそれは、ええと、業界で私たちが観察しているトレンドであり、人々はこれらの lms、現代の lms を使って、より実用的なシステムを構築しようとしています。これらのアーキテクチャや、ええと、これらの新しい LLM がはるかに優れていることに疑問の余地はなく、ええと、2021 年のような早い時期に発表された指標や論文でさえ、もはや当てはまりません。ええと、これらのモデルは、そのような基本的な間違いをすることができないほどです。とはいえ、ええと、ええと、まだ、つまり、明らかにすべきことは、これらの LMS を使って実用的なシステムを大規模にどのように構築するかです。ええと、しかし流れは間違いなくその方向に進んでいます。
ええと、はい。こちらも同じです。ええと、スライド 25。rag の箱には l l m が含まれていますか？ええと、はい、含まれています。ええと、これに印を付けます。
はい。適切な埋め込みアルゴリズムを持つとはどういう意味か、もう少し議論していただけますか？適切な埋め込みアルゴリズムを使っていることをどのように評価できますか？これはかなり複雑な質問になると思います。これは、ええと、録画のコメント欄か LinkedIn で質問すべき内容だと思います。この種のシステム、検証し複製を検討するためのテストシステムを構築するためのリファレンスアーキテクチャはありますか、ええと、otten？ええと、すぐに繰り返してもらえますか？この種の s を構築するためのリファレンスアーキテクチャはありますか、質問が指しているこの種のシステムというのは、ええと、rag と eval のもののことだと思います。ええと、それで彼は、それに対するリファレンスアーキテクチャと、検証して複製を検討するためのテスト ISN があるかを尋ねていました。
はい、これらは、ええと、まだコモディティ化されていません。今のところすべて進行中の作業です。ただ、ええと、オフラインで連絡していただければ、業界で書かれたいくつかの、いくつかの新しい、そうですね、ホワイトペーパーやブログを共有できます。私たちからのものも含めて、ええと、参考として。はい。ええと、はい。
ありがとうございます、ええと、Otten。来てくださった皆さん、ありがとうございます。時間になりました。ええと、私は時間にとても厳しい人間なので、ここで終わりにします。ご質問があれば、どうぞ遠慮なくご連絡ください。
ええと、これはオンラインに投稿する予定です。LinkedIn で私たちを見つけることができます。ええと、何か質問があればぜひお尋ねください。皆さん、お越しいただきありがとうございました。また次回お会いしましょう。ありがとうございます。
Meet the Speaker
Join the session for live Q&A with the speaker
Atindriyo Sanyal
Co-founder and CTO at Galileo
Prior to Galileo, Atindriyo was an Engineering Leader at Uber AI, responsible for various Machine Learning initiatives at the company. He was one of the architects of the world's first Features store (Michelangelo) and early engineers on Siri at Apple, building their foundational technology and infrastructure that democratized ML at Apple.