Join the Webinar
Loading...
このウェビナーについて
すべての企業は、ある程度、非構造化ドキュメントに対処しなければなりません。中には、それらを大規模に処理しなければならない企業もあります。この問題に対するLLMを活用したアプローチは、従来の機械学習ベースのアプローチよりも間違いなくはるかに優れていますが、課題がないわけではありません。最大の懸念は精度とコストであり、大規模になると大きな負担になり始める可能性があります。
このウェビナーでは、構造化ドキュメントデータ抽出のために専用に構築されたオープンソースプラットフォームであるUnstractが、これらの課題をどのように解決するかを見ていきます。月間500万ページ以上の構造化コンテンツ抽出を処理するUnstractは、精度とコスト効率を達成するためにさまざまな手法を使用しており、その中でも主要なものがベクトルデータベースの利用です。
取り上げるトピック
- 非構造化データ処理の概要
- ドキュメントデータの処理
- 抽出の難しさ
- Milvusの活用
- デモ
本日のセッションをご紹介できることを大変嬉しく思います。先ほど申し上げたように、課題と構造化されたドキュメントデータです。そしてこれは非常に具体的で重要です。なぜなら、私たちは非構造化データの世界にいるにもかかわらず、その多くは実際には構造化されており、かなり複雑だからです。PDFや、フォームや法務文書、あるいは特定の形式でなければならない多くのドキュメントを見ると、もしそれを抽出しようとしたことがあるなら、それが簡単ではないことがわかるでしょう。ですので、本日ゲストスピーカーをお迎えできて本当に幸運です。
彼は、非構造化ドキュメントからデータを抽出し、重要なビジネスプロセスの自動化を支援する、クールなLLM搭載プラットフォームを構築しているオープンソースの、ええ、スタートアップであるUnst extractの共同創業者兼CEOです。そして繰り返しますが、本当に構造化されたドキュメントであり、これは非常に複雑です。彼は、ええ、Unstrを共同創業する前はFreshWorksでプラットフォームエンジニアリング担当VPを務め、また電子工作の愛好家でもあります。ああ、今日手に入れた新しい、ええ、回路をいくつかお見せすればよかったですね。ここ私の机の上に置いてあります。
ええ、それから、ええ、あなたはもう他人のスペルや文法の間違いを自発的に直すことはないのですね。わあ、それは大変ですね。それについては称賛します。ようこそ、ええ、始めましょう。スライドを共有してください。私は背景に隠れます。
ありがとうございます、ええ、Tim、ええ、本当に感謝します。ええと、画面を共有しますので、それから、ええ、進めていきます。ええと、では簡単に、ええ、背景として、今日、ええ、見ていく内容についてですね。ですので、すぐに確認できるような小さなアジェンダのスライドがあります。PDFドキュメントに関しては、構造化されていようと非構造化であろうと、実際には関係ありませんよね。つまり何が起きるかというと、こうした種類の非構造化ドキュメントをほぼ毎日のように扱っている企業が存在するわけです。ですが、何が起きるかというと、それらのPDFドキュメント、あるいは他の形式でも、構造化するために利用可能な現在の技術があります。形式は本当に関係ありません。
Word文書かもしれませんし、PowerPointかもしれませんし、Excelシートかもしれません。本当に関係ありませんが、そうした現在のシステムには制限があります。通常、最大の制限は、抽出を開始する前にドキュメントを手動でアノテーションしなければならないことです。これは大きな問題ですよね。ええ、例えば、融資を行う企業を考えてみてください。そして、ええ、何が起きるかというと、たとえば、あなたがどのような適格性を持っているかを判断するために、銀行取引明細書を提出する必要があるとします。そしてその企業、ええ、金融機関は銀行取引明細書を受け付ける必要があります。300件の異なる申請が来て、その300件の異なる申請が300の異なる銀行からの銀行取引明細書を提出したらどうなるでしょうか？その300の銀行取引明細書すべてを手動でアノテーションしに行くのは妥当でしょうか？つまり、それは不可能ですよね。これが現在のシステムの制限です。しかし、ここが本当に素晴らしい点です。大規模言語モデルは、その手動アノテーションの必要性を克服するのに役立ちます。ですので、unst instructは、ええ、それを支援するオープンソースプラットフォームです。そして、どのように機能するかを見ていきますが、同時に、これは、つまり、これが万能薬だと言うのは不公平でしょう。大規模言語モデルには限界があり、その限界が何であるかも見ていきます。ええ、abstractプラットフォームをご紹介します。
ええと、まずはたぶん10分ほどかけて、ええと、それが何で、どのように機能するのか、そういったことをざっと見ていきます。それから、この話の本題に入りたいと思います。ええと、今日の大半の時間を使うところですね。そこで、大規模言語モデルと、ええと、ええと、いわゆるベクトルデータベースの組み合わせが出てきます。ええと、今回のケースでは、Zillow cloud上のマネージドインスタンスとしてmalwareを使います。ええと、これは素晴らしいサービスです。実際、私はサインアップして、ええと、100ドル分くらいのクレジットをもらいました。すごいですよね。なので、Timがもっとくれることを期待していますが、まずは100ドルあるので、それでかなりリッチな気分になっています。ええと、でも、ここではかなり細かいところまで入り込みます。なぜなら、ベクトルデータベースなしで非構造化ドキュメントからデータを抽出しようとすると何が起こるのかをお見せしたいからです。
それからベクトルデータベースを導入して、それがどうなるかを見ていきます。ただその後で、もう少し詳しく見ていって、単純な検索戦略を使った場合に何が起こるのかを区別します。そして次に、もう少し高度な戦略を見ます。これはサブ質問検索と呼んでいます。もし、もし皆さんがこのすべてを完全には理解していなくても、私が、ええと、時間を取って、この仕組みや、そういったことの一部を順を追って説明します。皆さんの中には、すでに聞いたことがある内容かもしれませんが、でも、残りの、残りの聴衆の方々には、こうした内容の一部を説明する間、辛抱強くお付き合いいただければと思います。そうですよね？でももっと重要なのは、実用性という観点から話したいということです。そうですよね？つまり、私たちは現時点でプラットフォームとして、だいたい、ええと、月に500万ページほどを扱っています。それが私たちが抽出を支援しているものです。そうですよね？なので私たちは、多くのデータを持っていて、多くの量子ケースを見てきましたし、ええと、大規模言語モデルが本番環境で大規模にデプロイされるのも見てきました。そうですよね？そうですよね？ですから、何がうまく機能するのか、何がうまく機能しないのか、そういった点について、ええと、そうした洞察をいくつかお伝えできればと思います。
これは、ええと、とても興味深い、ええと、ええと、アプリケーションであり、今日すぐに収益化できる大規模言語モデルの非常に実用的なアプリケーションです。そうですよね？ええと、これは私についてです。ここに時間をかけるつもりはありません。今日は非常に詰まったアジェンダがありますので、進めていきますが、でも、つまり、もし、ええと、このウェビナーの後でも、話したいと思った場合にどこで私を見つけられるかは分かりますよね。PDF全般を扱うには多くの課題があります。なので、表があったり、PDFフォームがあることもあります。こうしたフォームにはチェックボックスやラジオボタンが含まれることがあり、複数カラムのレイアウトがある場合もありますし、さらにスキャンされたドキュメントもあります。
スキャンされたドキュメントが適切にスキャンされている場合もあります。つまり、誰かがフラットベッドスキャナーを使って、そこにドキュメントを置いてスキャンしたということです。そうしたスキャンは通常、問題にはなりません。かなり簡単に扱えます。でも、ほら、もちろん今では人々がスマートフォンを持っていて、さっと取り出して、レシートなどの写真を撮りますよね？彼らは、スマートフォンで、ええと、実質的に何でもできます。クリックして、フォームや、ええと、ドキュメント、レシート、あるいは何であれ写真を撮ることができます。でも問題は、傾きがあったり、ええと、照明の問題があったり、私たちが対処しなければならないあらゆる種類の問題が起こり得ることです。そして最悪中の最悪は、手書きのスキャンフォームです。そうですよね？これらは、これらもまた対処が非常に難しいものです。
これらは、私たちが日々、日常的に扱っているものの一部です。私たちは、今この現実世界で、これらすべての種類の文書から構造化された情報を抽出する必要があります。同じ文書タイプの中でも、ですよね？つまり、銀行取引明細書は文書タイプであり、履歴書も文書タイプであり、保険証券も文書タイプです。タイプと言ってはいるものの、これらの文書タイプの間には非常に幅広い多様性があることがわかります。そこに課題があります。そこに大規模言語モデルの出番があります。これに関しては、大規模言語モデルは機械学習モデルよりもはるかに優れています。
そして、それらは本当に、本当に良い仕事ができますよね？人間が行うように。たとえば、もし私があなたに2つの異なる銀行の銀行取引明細書を渡したとして、あなたは「この場所、50、100 x と y の位置に顧客名があり、その場所に顧客住所があるはずだ」などとは見ていません。人間として、私たちはそのようには考えません。私たちは、ただ言語の観点で考えるのです。銀行取引明細書を読むとき、私たちはただ銀行取引明細書を読み、顧客名が何か、住所が何か、取引テーブルがどこから始まるかを知っていますよね？私たちはただわかるのです。大規模言語モデルもほぼこれに従っています。つまり、非構造化文書から構造化データを抽出する方法において、かなり似たようなアプローチを取っているのです。これは素晴らしいことですよね？非常に人間らしいですよね？ええと、そして、もう一つの問題、つまり影響としては、人が手作業でデータを抽出すると、非常に遅く、非常に高価で、今でも非常にミスが起こりやすいということがあります。しかし、私たちにはここに非常に興味深い機会がありますよね？大規模言語モデルを扱う人々として、たとえばこの小さな楕円が、現在の既存技術によって解決されているすべての問題を表しているとしましょう。そこには、まだ解決されていない非常に、非常に大きな市場があり、それを大規模言語モデルを使って解決できますよね？非常に、非常に簡単に、ですよね？しかし、現在の大規模言語モデルでは解決されていないものの、さらに解決できるものもあります。
つまり、これが、これが私が話していたことです。では、大規模言語モデルの限界は何か、ということですよね？お客様から、棒グラフやこれらのグラフやチャート、円グラフ、そして財務諸表の中にあるあらゆる種類のものについて、「これも構造化データに変換できますか？」と聞かれます。答えは、最先端の技術はまだそこまで到達していない、ということです。たとえ非常に単純な円グラフや、円グラフを取り上げたとしても、多くの場合、その単純なスクリーンショットを撮って、たとえば chat GPT に貼り付け、それを構造化データに変換するよう依頼すると、多くの場合に多くの間違いを犯すことがわかります。そしてこれを十分に試せば、その成功率は本番環境に投入できるほどではないことがわかるでしょう。ですので、ええと、しかし、それでもなお、ですよね？大規模言語モデルを使って解決できるものは、巨大な市場なのです。
そして、この市場は現在100パーセント手作業で対応されていて、遅く、高額で、しかもプロ、ですよね？つまり、これはLLMを使って解決できることなんです、ですよね？それで、ええと、一歩引いて考えてみてください、ですよね？今日、人々は大規模言語モデルでどのように収益を上げているのでしょうか？少しだけ考えてみましょう。今、人々は、スタートアップが得ている、とんでもない評価額について話したり、大規模言語モデルで海を沸騰させるような大問題を解決することについて話したりしています。でも、大規模言語モデルが実際にどこで実用的に導入され、本当の問題を解決していて、そして、そのソリューションの背後にいる企業が収益を上げているのかを本当に考えてみると、それは本当に、本当にごくわずかで、非常にまばらなんです、ですよね？そのいくつかを見ていきます。なぜなら、実務家として、これは今でも非常に興味深い情報だからですし、リーダーの方々もいるはずです、ですよね？さて、私は、今日収益化可能な大規模言語モデルの最大のユースケースは、エンタープライズ検索だと思います、ですよね？大規模言語モデルとベクトルデータベースを使って、データを取り込み、それから検索を行う、セキュリティも関わっていて、実にさまざまなことがあります。しかし、これは非常に興味深いユースケースで、2番目のユースケースはカスタマーサービスです、ですよね？つまり通常、ええと、人間でできることがありますよね、ナレッジベースがあり、人々は、ええと、企業の製品情報などについて訓練されていて、それから別の人間が彼らに電話したりチャットしたり、あるいは何らかのチャットボックスを使ったりします。そして、それに答える人たち、これは大規模言語モデルによる、ええと、破壊的変革にものすごく適しています。
そして、私たちは、これはすでに起きているのを見ています、ですよね？大規模言語モデルの後、チャットボットは非常に優秀になったので、私たちが、ええと、人間と話しているのかチャットボットと話しているのかを区別するのが難しいのです、ですよね？そして私は、3番目に大きな水平的ユースケースはソフトウェアエンジニアリング、特に、ええと、コード、ええと、ええと、copilotだと思います、ですよね？今では GitHub、copilot code dm、tab nine など、たくさんあります。それらは本当に、本当に良い仕事をしています。私は毎日使っています。私の同僚もそうですし、ソフトウェア開発に携わっている多くの異なる組織の、私の友人の多くもそうです。これは、これは本物の、ええと、インパクトです、ですよね？そして多くのボイラープレートコードは、正直なところ、誰も本当に好きではありませんよね？こうした種類の、ええと、ものを使うときに書くものです、ですよね？そして私たちは、4番目に水平的に収益化可能な大規模言語モデルのユースケースは、これらの構造化および非構造化ドキュメントから非構造化データを構造化することだと考えています。
ですよね？もちろん、営業やマーケティングなどに対して同じことを行っている興味深い企業は他にもあります。しかし、私が思うに、LLMによって組織が今日収益を上げ、本当の問題を解決するソリューションを持っているのはここです。ですよね？もちろん、エージェントについて言えば、それは将来の話だと思います、ええと、ですよね？複合的なエラー率のためです、ですよね？もしLLMからの入力を別の、ええと、別のユースケースに送り、さらにそれを別のユースケースに送ると、エラーは積み重なっていく傾向があり、これはエージェントにとって大きな問題で、人々はこれを解決しようとしていますが、きっと解決すると思います。ただ現時点では、その周辺で、ええと、収益化が起きているとは思いません、ですよね？さて。いいですか、こういうことです、ですよね？copilotと un instruct には違いがあります、ですよね？ドキュメントを chat GPT にアップロードして、それを構造化するよう依頼することを妨げるものは何もありません。そこにはいくつか問題があります。
構造は何ですか？質問するたびに作業を作成し、毎回異なる構造を提示します。そして人間がループに入る、つまり情報はいま人間が見ている画面上にありますが、そのデータはおそらく別の場所で必要とされている、ということですよね？たとえば、あるシステムで、もし何らかの、ええと、銀行があなたから大量の書類を受け取っていて、あなたにローンを提供するためにそうしている場合、その情報は申請を処理できるようにバックエンドシステムに必要になります。そうですよね？もちろん、人間が、ええ、copilot からデータをコピー＆ペーストすることはできますが、まずそのデータが正しいかどうかを確認しなければなりません。幻覚がないか、ですよね？そしてコピー＆ペーストの際に、間違ったフィールドをコピーしてしまい、そこでミスをする可能性があります。また、もう一つの、ええと、問題は、データを変換したり、日付や通貨などの形式を変更したりしなければならない場合があり、そこでもミスが起こり得るということです。そうですよね？ですから、100パーセント手作業で行うよりは間違いなく一歩前進です。しかしやはり、ええと、この技術の最善の、ええと、可能な使い方ではありませんよね？untraced で見ているのは、私たちが machine to machine automation と呼ぶもので、ええと、非構造化された、ええと、文書を取り込み、構造化し、そして、ええと、それが実際に必要とされる場所へ送り込むものです。
8つの ETL パイプラインを行うこともできますし、API を使って、ええと、構造化データを必要なシステムに取り込むこともできます。もちろん、幻覚などの問題はありますが、それにどう対処するかについては後で話しますよね？私たちは、これは現在より、ええと、完全な自動化だと感じています。さまざまな非構造化文書からデータを構造化する方法には、ええと、ええと、3つの異なる世代があります。OCR があります。これは単に、ほら、これは純粋なデジタル化です。そこに知性はありません。
次に機械学習ベースのモデルがあり、コンピュータビジョンやその他の多くの技術を使って、ええと、文書を読み取るべきもので、NLP ベース、NER、そのようなものです。しかし問題は、それらは OCR R より確実に優れているものの、かなり脆いということです。そうですよね？そして、そして、ええと、現在大規模に運用されているシステムは、この種のシステムが本当にうまく機能するためにアノテーションを必要とします。そうですよね？しかし先ほど言ったように、人間が文書を扱う方法は、単に知識を使い、言語を使うだけです。私たちは文書を読んで、何が何であるかを理解します。そして同じことを、大規模言語モデルを使ってエミュレートできます。それこそが、ええと、UN instruct のようなシステムが活用しているものです。大規模言語モデルが推論する能力、ええと、指示に従う能力、つまり私たちのプロンプトを用いて、それによって非構造化文書を構造化できることがわかっています。
現在、un instruct 自体は、ええと、オープンソースプラットフォームで、ええと、独自の LLM スタックを持ち込むことができます。ええと、そうですよね？つまり、大規模言語モデルを選び、ベクトルデータベースを選び、em embedding model、text extraction system を選びます。本当にあなた次第です。なぜなら、私たちはあなたにコントロールしてほしいからです。ええと、そうですよね？たとえば、最高の中の最高のモデルが必要なユースケースもあるでしょう。人間がどこかでループに入っているユースケースでは、単にスピードアップしたいだけかもしれません。その場合は、より安価なモデル、より能力の低いモデルを使えます。
それは、本当にユースケースの実現可能性と、そして、何を選ぶべきかによって異なります。ええと、もちろん、私たちは、ええと、malware をサポートしており、非常に早い段階からサポートしていたと思います。そして、そして ZI の cloud もです。ええと、ほぼ、オープンソース提供は機能し、クラウド提供も機能しており、かなり十分にテストされています、with and Zills ですよね？さて、OnTrack を2つの別々の明確なフェーズとして考えてください。フェーズ1は、代表的なサンプルを、私たちが prompt studio と呼ぶものに提供するところです。つまり pro studio に行き、ええと、例を与えます。
では、銀行取引明細書の例を取り上げてみましょう、いいですか？さまざまな銀行の明細書を与えます、15、20種類の異なる明細書です。次にプロンプトエンジニアリングを行います。そして prompt studio は、それらのドキュメントから主要なフィールド、顧客の名前、顧客の住所、口座番号、取引情報、そういったものすべてを抽出するための汎用プロンプトを書くのを手助けしてくれます、そうですよね？つまり、汎用のプロンプトエンジニアリングを行う、それが1つ目です。プロンプトエンジニアリングに満足したら、次にデプロイメントフェーズに進み、それを ETL パイプラインまたは API エンドポイントとして起動します、そうですよね？たとえば、API エンドポイントとして起動したとしましょう。銀行取引明細書を送信すると、構造化された JSO データが返ってくる、ということです。それが一般的な考え方です。ですから、これらは2つの異なるフェーズであることを覚えておく必要があります。さて。
私たちはハルシネーションについて話しましたよね？そしてハルシネーションについて少し心配していました。ここで LLM challenge が登場します。ええと、unstuck users では2つの大規模言語モデルを使い、その両方が合意に達する必要があります。そうでなければ、抽出される特定のフィールドの値を null にします、そうですよね？なぜなら、誤った値よりも null 値のほうがよいと考えているからです。それが哲学です、そうですよね？私たちは、まあ、その方針を守っています。
ええと、そこで Elam challenge が登場します。ですからハルシネーションは起こり得ません。なぜなら、2つの異なる別々のベンダーからの2つの異なる大規模言語モデルが、同じ値をハルシネーションしてそれに同意することはできないからです。それは決して起こりません、そうですよね？だからこそ、抽象的にはハルシネーションを心配する必要はありません。さて、コストに関しては、single pass extraction と summarize extraction という他の2つの技術があります。これらはコストを削減し、これもまた大規模言語モデルを使ってプロンプトを圧縮し、ドキュメントを圧縮し、レイテンシとコストの両方を削減します。ですので一般的には、これらは本番環境で大規模言語モデルを実用的にデプロイするのを支援するために私たちが備えている機能の一部です、そうですよね？通常、これらの機能をオンにすると最大7倍の削減が得られます。これがその仕組みです。さて、次に進みましょう。先ほど言ったように、議論の本題と、物事がどのように機能するかに移りましょう。
unst platform の概要を簡単に説明します。そして、1つの特定のユースケースを取り上げ、それがどのように機能するかを見て、それからそれをデプロイし、API としてデプロイされた状態にして、そこにドキュメントを渡し、どのようなレスポンスが返ってくるかを見ます。そして、そこから進めていきます。その後、ベクターデータベースで使えるさまざまな戦略に移ります。この場合、zills Cloud を使い、Zillow を使ってこれらのドキュメントを構造化することにどのような影響があるかを見ていきます。ええと、これがプラットフォームです。ここに prompt studio があります。
ここには、pro studio プロジェクトがいくつかあります。これが読み込まれるなら、これを更新してみます。つまり、私たちがやりたいのは、pro studio の簡単なツアーをお見せして、さまざまなコンポーネントがどこにあるのか、物事がどのように機能するのかを示すことです。それから、特定のユースケースを1つ見ていきます。特に、API とそれがどのように機能するかをお見せしたいと思います。そして、そこから進めていきます。かなり時間がかかっています。別のインスタンスがあります。
こちらを確認してみます。はい。これは loaddemos です、そうですよね？はい、時間がかかっています。大丈夫です。先に進みましょう。
これから行ういくつかのことをお見せします。いいですか？さて、私たちがやりたいのは基本的に、いくつかのドキュメントから構造化情報を抽出することです。さて、この特定のケースでは、2つの大規模言語モデルを設定しています。Apple の 10 Q form があります。これらは単に、上場企業が毎四半期 a CC に提出する標準的なフォームで、大量の情報が含まれています。
ただ一般的に、私たちが関心を持っているのは、ええと、10個の異なる、ええと、項目を抽出しようとしている、ということだと思いますよね？つまり登録者の名前、ええと、JSONフィールドがあります。つまり最終的には、このドキュメントを、ええと、このJSON形式に変換したいのです。そこには登録名、ええと、委員会ファイル番号、管轄、州、州の従業員ID、住所、ええと、電話番号、証券の詳細、そして、リスクとリスク要因、そしてこの四半期と前年同期の収益詳細が含まれますよね？ええと、これが私たちが、私たちがやろうとしていることですよね？ですから、この、この特定のケースでは、ええと、2つの大規模言語モデルを設定しています。ええと、1つは、ええと、GPT-4 turboで、もう1つはclawed instant 1. 2です。そして、ええと、各プロンプトについて、コストが実際にはかなり高いことがわかります、ええと、そうですよね？理由は、このドキュメントが実際にはこのraw viewに変換されているからです、ええと、そうですよね？ええと、ご覧のとおり、私たちはこれを、ええと、レイアウト保持技術と呼んでおり、これは私たちの、ええと、テキスト抽出LLMです。
そしてレイアウトを保持すると、大規模言語モデルはこの種のものを読むのが本当に得意であることがわかりますよね？つまり、単なるテキストのダンプではなく、レイアウトを保持すると、私たちは文字通りテキストを挿入して、ええと、それができるように、できるようにしているのです、そうですよね？ですので、ええと、この特定のケースでは、ええと、ご存じのように、私たちはベクトルデータベースを使用していません。つまり起きていることは、何かを抽出しようとするたびに、ええと、コンテキスト全体、このコンテキスト全体が大規模言語モデルに送信されるということです。それがコストが非常に高く、また、トークンも非常に多い理由です、そうですよね？ええと、ファイル番号、管轄、州についても同じことがわかります。これらはすべて私たちが抽出しているテキストフィールドであり、私たちが持っている2つの異なる大規模言語モデルによる、異なる抽出結果を比較できます。次にここで住所を取得しています。ええと、つまり住所、州、郵便番号を、ええと、別々に取得しており、市も同様です。
そして、ええと、あの、異なる、ええと、つまり、これら2つの大規模言語モデル抽出結果を比較することもできますよね？さて、ええと、より複雑なタイプになると、A-J-S-O-Nフィールドがあります。つまり、フィールドにはさまざまなタイプがあり、テキスト、数値、メール、BOO、データ、その他すべてがあります。さて、これをJSONに設定すると、そして、プロンプトで、単に必要なJSONを記述できます。私たちは、基本的に、ええと、ご存じのように、JSON出力が得られることを確実にするために必要な追加のプロンプトエンジニアリングを行います、そうですよね？そしてここに開示があります。次に収益詳細です。これは少し複雑なプロンプトです、そうですよね？つまり、現在の四半期について、四半期名、純売上高、純利益を取得してほしい、と言っています。そしてここには追加の指示もいくつかあります。
そして、ええと、結果として、ええと、ご存じのように、VUSはこれが本当に、本当に得意です、そうですよね？ですから複雑なプロンプトがあっても、ええと、実際にここで使用されたチャンクを見ることができます、ええと、そうですよね？そして、そして、そして私は、ベクトルデータベースからどのような、ええと、データが返されているかを見ることができます。ただし、この特定の例では、ベクトルデータベースを使用していませんよね？何らかの理由でClaudeは失敗していますが、ええと、GPTは応答を返しており、私はこれが、これが確かに、正しい応答であることを確認しました、そうですよね？そして、リスク要因などがあります。そうですよね？では、ええと、ええと、ええと、これを基本的にAPIとしてデプロイしてみましょう。ええと、instructorsでできることは、失礼しました。これをツールとしてエクスポートでき、その後これをAPIとしてデプロイできます。
したがって、ここで APIs に移動すると、私は、ええと、prompt studio プロジェクトごとに1つのエンドポイントを持っていますよね？では、例えば、ええと、先ほど見ていたプロジェクトを取り上げてみましょう、いいですか？そこではベクトルデータベースを使っておらず、単に、ええと、ご存じのように、すべてのプロンプト抽出、すべてのフィールド抽出のために、各プロンプトに対してドキュメント全体を送信していますよね？つまり、これが私たちのやっていることです。さて、これを、ええと、ご存じのように、私の、ええと、Postman に読み込んであります。ですので、ええと、Postman Collection に移動すると、実際には、各 API について、この API を呼び出すための Postman collection を簡単にダウンロードできます。もちろん、キーを管理することもできます。この API を呼び出すためのコードスニペットも確認できます。
改めてお伝えすると、ええと、この特定の API エンドポイントは、ええと、ベクトルデータベースを使用していません。ですので、このような抽出にどれくらいコストがかかるかを見ていきます。それが全体的な考え方です、いいですか？Postman に戻ると、ええと、これを Postman に読み込んであります。この特定の、No Vector db の、ええと、エンドポイントですね。そして文字どおり、ええと、今年の第2四半期の最新の Apple、ええと、10 Q レポートを1つ送信し、それを API に送ると、ええと、構造化された、ええと、JSON データが返ってくるはずです、そうですよね？それが全体的な考え方です。いいですか？今、ええと、metadata をオンにしています。つまり、抽出のために大規模言語モデルへ送信されたチャンクも返されるということです、いいですか？ですので、ええと、チャンクがそこにあることがわかります。このセクション全体を飛ばして下に進みます、いいですか？つまり、ドキュメントを送信して、構造化データが返ってきたわけです、そうですよね？ここに出力があり、住所、ファイル番号、開示情報、今年6月終了四半期の、ええと、収益の詳細、そして昨年のものも取得できています。
そして、ええと、その他の、ええと、リスク要因や証券の詳細などもあります、いいですか？ただし非常に重要なのは、私が注目していただきたい点として、この特定の例では、ええと、millware を使用しなかったため、コストが非常に高くなっているということです。このような単純な抽出で、25万トークンを超えて使ってしまっています、そうですよね？ベクトルデータベースを使わずにコンテキスト全体を使ったからです。そして、ええと、出力トークンも 7 99 ほどあります。ええと、ただ先ほど言ったように、この特定の、この特定のユースケースでは、3ドル近く使ってしまっていますよね？もちろん、embedding にも多少使っていますが、embedding のコストは、ええと、それほど高くはありません、ええと、そうですよね？しかしこれは、これはかなり大きいです、いいですか？しかし幸いなことに、ええ、私たちはこの特定の、ええと、ケースで Zillow cloud を使用できます。そして、これのコストをかなり簡単に削減する方法を見ることができます。いいですか？では、abstract に戻ります、いいですか？そして、ええと、私が持っているいくつかのプロジェクトを見てみます、いいですか？そして先ほど見た同じ例を見ますが、今回は、ええと、ZILLS が有効になっているものです、いいですか？この特定のプロジェクトの設定を見ると、GPT-4 を、ええと、デフォルトの extractor として設定しています。
そして、比較するために、Cloud instant 1. 2 もセカンダリ extractor として用意しています。ええと、それらを並べて比較するためです。embedding には Azure Open AI add を使っていて、ええと、Vector database には Zillow's cloud 上の VIS を使っています、いいですか？そして現在、text extractor として LLand Whisperer をテキストモードで使っています。text extractor は基本的にこのドキュメントをこのような表示に変換します、ええと、ここではフォーマットを保持しており、そしてテーブルも、ご存じのように、美しく保持されています。これは大規模言語モデルにとって非常に重要です。ええと、そうですよね？はい、できました。
またまったく同じものがありますよね？つまり、ed name、ええと、file、file ID などで始まる10個の異なるプロンプトがある、ということですよね？それで、これらすべてがあり、さらに、ええと、この特定のケースでは、Gemini Pro を使った challenger LLM challenge も有効にしていると思います。つまり、抽出にチャレンジしていて、ここでそれが見えますよね？ええと、これが入力で、それから入力が非常に小さいことがわかります。なぜなら今は、ええと、vector database などがあるので、価格が本当に下がることがわかりますよね？つまり、ええと、これは、これは、これは、非常に小さいコンテキストになっています。なので抽出があり、その後にチャレンジがあります。抽出それぞれについてスコアを生成します。city、state、zip code、full address、すべてが5点中5点で、素晴らしいです。満点を許可しています。
そして、ええと、はい、結果は最終的にこれに設定されますよね？これが LLM challenge の実際の動作です。ええと、これでコストが劇的に下がったことがわかります。もちろん、fraud が GPT-4 よりずっと安いこともわかりますし、ええと、87,000 ほどの、ええと、tokens から、今では tokens がほんの数千にまで減っていることがわかりますよね？これはどうやって起きているのでしょうか？これは、この特定のケースで、ええと、vector database をオンにしたために起きています。ここでいくつか、ええと、詳細を見ていきます。
ええと、これを編集します。chunk size は 1,024 です。overlap は 1 28 で、simple retrieval strategy を使用しています。この特定の例では、simple が何なのか、もう一方と比べてどう違うのかを、少し後で説明したいと思います。今これについて説明するために、プレゼンに戻ります。
ええと、ここを見ると、これをクリックできますし、また、ええと、使用された chunks も見ることができます。今この特定のケースでは、ええと、プロンプトを見ると、registrant の住所は何か、次の fields を持つ J object を作成せよ、full address、city、state zip code、となっています。そしてこれはまず Vector database に送られ、そこにドキュメント全体の、ええと、raw text があります。これは full raw text のようなものですが、full raw text は抽出には使用されません。ええと、この、この質問、プロンプトはまず vector database に送られ、この場合は Zillow cloud に送られ、それから Zillow cloud が、ええと、これらの chunks を返します。
そしてここを見ると、これはまさに必要な chunk です。なぜなら、ええと、ご存じの通り、principal office の住所などが含まれているからです。つまり今 Zills は、ねえ、これが関連する chunk だ、と判断したわけで、そしてきっと他にも住所が含まれている chunks などがあるはずです。なぜなら、これが実際にシステムが動作する仕組みだからです。そして、そして、そして基本的に、ええと、探しているのは、ご存じの通り、ええと、住所で、基本的にはドキュメント全体から関連する chunks を取得しているわけです。しかし、ええと、どれほど大幅に、ええと、ご存じの通り、コストが下がったかがわかりますよね？ええと、では一つやってみましょう。これ、この Simple Retrieval も API として立ち上げています。
ここにこれが見えますよね？この 10 Q parsa、simple retrieval です。Postman に行きます。これを閉じます、いや、これを開いたままにしておきます。なぜなら、ええと、この、このコストと比較対照したいからです。では、この simple retrieval、ええと、endpoint を開きますよね？そして同じファイル、Apple 10 Q を送信し、この API に送ります。これは今、ええと、vis を使用しています。はい、できました。今回、見ると、chunks も非常に小さいですよね？ドキュメント全体は存在しませんよね？なぜなら metadata を有効にしているからです。
皆さん、これ全部を見ています。そうでなければ、一般的に、PA は今これ全部には応答しません。コストの話に移ると、なんて大きな違いでしょうね？コストは$2. 86から、たった、ええ、36セントまで下がっていますよね？これはコストが約8分の1になったようなものだと思いますよね？それが皆さんのやることです。つまり、あの、Vector データベースをオンにして、さらに単純なもののようなものを使うだけで得られるものです、そうですよね？でも少し戻って、あの、リトリーバル、特にシンプルリトリーバルについて少し話しましょう。そして、これ全体がどのように機能するのかを見ていきましょう。
さて、ここにいる皆さんの中には上級ユーザーもいるかもしれないことは分かっていますが、これに馴染みがないかもしれない、Vector データベースが初めてかもしれない、私たちの中の残りの聴衆のために、しばらくお付き合いいただく必要がありますよね？ですので、ここはお付き合いください。ええ、一般的に起こることは、クエリまたはプロンプトを受け取るということです。この場合、住所を抽出しようとしているとしましょう。皆さんはそのプロンプトを見ましたが、かなり単純なプロンプトでした。それを埋め込みモデルに送り、そしてすでにドキュメントはベクトルデータベースに格納されています。次にベクトルデータベースに、この特定のプロンプトに対して、関連するチャンクは何か、と尋ねますよね？そしてそれらのチャンクが取得され、ええ、ユーザープロンプトと組み合わされて大規模言語モデルに送られ、大規模言語モデルから応答を得ます。
これが RAG の実際の姿です、そうですよね？ただし、これは非常に単純化されていますよね？これはシンプルリトリーバルと呼ばれるもので、つまり、単にクエリを受け取って、あの、ベクトルデータベースに送り、チャンクを取得し、そして、ええ、それを使うということです。ここで非常に弱い点として、皆さんが理解しなければならないのは、ベクトルデータベースには、そうですね、強みと弱みがあるということです。Vector データベースに非常に非常に複雑なプロンプトを送り、あの、送るべき正しいチャンクを見つけてくれることを期待するなら、それは大きな問題です、そうですよね？ですので、ベクトルデータベースに直接送るべきではないプロンプトの例を見てみましょう。Vector データベースは、情報を整理すること、情報を取得すること、情報をベクトル空間内に配置し、そして必要な正しい情報を取得することに特化しています。それが、それが Vector データベースの、ええ、強みです、そうですよね？非常に複雑なプロンプトを与えるだけで関連するチャンクを返してくれると期待すべきではありませんよね？それはプロンプトへの正しいアプローチではありませんよね？今から、それがどのように、どのように、どのように、そしてなぜそうなのかを見ていきます。ですので、先ほど使ったようなシンプルな、ええ、ええ、リトリーバル戦略を見ると、つまり、プロンプトを受け取り、埋め込み後に直接、ええ、ベクトルデバイスに送り、11個のチャンクを求めるということですが、それにはいくつかの利点と欠点がありますよね？シンプルリトリーバル戦略は、ほとんど RAG のようなもので、先ほど見たスライドそのものですが、プロンプトが単純な場合、皆さんのプロンプトと抽出したいものの間に直接的な相関がある場合にうまく機能します。
たとえば、何を避けるべきか、どのようにフォーマットすべきかについての情報はあまりありません。だからプロンプトは本当に長くなり得ますよね？でも抽出する必要があるものは、プロンプトのどこかにあるだけかもしれません、ええ、つまり、それが通常は問題になりますよね？単純なプロンプトでは、私たちが使っていたようなものですが、これは今のところ本当にうまく機能します、ええ、単純な、ええ、ええ、検索戦略では、ですよね？単純なプロンプトでは、正しいチャンクを取得できるはずです、ですよね？ええ、結果は場合によりますが、通常は正しいチャンクを取得できるはずですよね？さて、こ、これはより安価なアプローチになります、ええ、ですよね？なぜなら、やっていることは、質問を取り、それを埋め込み、ベクトルデータベースに送信し、関連するチャンクを取得し、それを大規模言語モデルに送って、ほぼ完了、ということだからです。さて、プロンプト自体が非常に複雑な場合はどうなるでしょうか？私たちは、そうした、ええ、そうした、ええ、いくつかのケースを見てから、プレゼンテーションに戻ります。ですよね？さて、私には、ええ、subquestion retrieval が有効になっている別のプロジェクトがあります。それがどこで行われているかをお見せしますし、subquestion retrieval とは何か、そしてそれがどのように、どのように機能するかもお見せします。ですので、ここで settings に行き、今回は edit と言います。
これで retrieval strategy が simple から sub-question に変更されているのがわかりますよね？つまり、ract で行う必要があるのはそれだけです。さて、sub-question retrieval では、基本的に何が起こるかというと、大規模言語モデルを使ってこのプロンプトを取り、何を検索すべきかについての複数のサブ質問に変換します、ですよね？たとえば、このような大きなプロンプトを送るとしましょう、ですよね？私たちはベクトルデータベースに、その、ええ、その、その、その単一のプロンプトを送っているわけではありません。では何をしているかというと、このプロンプトを大規模言語モデルに送り、何を抽出すべきかを尋ねているのです。それを別々の質問として私にください、と。その後、ループがあり、そのループの中で、プロンプトから LLM によって生成されたすべてのサブ質問を送り、ベクトルデータベースに関連するチャンクを提供するよう求めます。そしてすべてのチャンクが揃ったら、重複チャンクを探し、それらを削除し、その後それらのチャンクを、ええ、質問と一緒に大規模言語モデルへ送り、うまくいけばより良い結果が得られます。
ですよね？さて、これは、たとえば、わかりますよね、この特定のプロンプトを考えてみてください。これは、単純なプロンプト、たとえば registrant の住所は何か、というものより少し複雑です。それほど単純ではありません。ここでは、cons、condensed、consolidated statement of operations または income statements から、次の JSO object で回答してください、となっています。そしてこれらが私たちが尋ねているすべての項目で、さらにここに追加の指示があります、ですよね？もしこれを本当に考えてみると、これらの指示をベクトルデータベースに送っても、関連するフィールドは何も返ってこないでしょう、ですよね？単に必要なのは、私たちにとって関連するフィールドは consolidated statements of operations または income statements であり、それだけが私たちの関心対象です、ですよね？ですから、私たちは実際には、ええ、わかりますよね、ここの部分には関心がありません。したがって、このケースでは subquestion retrieval のほうが実際にはうまく機能します。なぜなら、このプロンプトを大規模言語モデルに送り、ねえ、ユーザーは何を抽出しようとしているのか、と尋ねるからです、ですよね？そして大規模言語モデルはおそらく 2 つの質問で応答するでしょう。consolidated、ええ、condensed、consolidated statement of operations とは何ですか？そして income statement とは何ですか？income statements とは何ですか、ですよね？なので、おそらく 2 つ得られることになり、それからループに入り、これらのサブ質問を取り、ベクトルデータベースにこれらのサブ質問に関連するチャンクを後で提供するよう求めます。
次に、それらのチャンクをすべて取り、重複を削除し、それをこのプロンプトとともに大規模言語モデルに送信して、応答を取得します。そうすれば、おそらくかなり良い応答が得られるでしょう。さて、この特定のケースでは、実際には良い応答が得られていますよね？なぜなら、これは十分に単純で、たった90ページ程度しかなく、それでも良い応答が得られているからです。では、見てみましょう。私はこの特定の、ええと、戦略のコストを知ることに非常に興味がありますよね？では、Postmanに戻りましょう。ここにあるPostmanです。見ると、ベクトルデータベースを使わない場合は2.80ドルで、単純な取得戦略を使うと、ええと、36セントです。
では、サブ質問パーサーに行きましょう。ここです。これを開いています。同じファイルを、この特定のAPIエンドポイントに送ってみます。これはサブ質問取得戦略を使用しています。今回はチャンクが大きいですよね？今回はより多くのチャンクがあるため、コストが増えることを意味します。ご覧のとおり、今回は50セントを使いました。なぜなら、たとえばこのコンテキストと比べると、こちらの方がかなり大きなコンテキストであることがかなり簡単にわかるからです。こちらはそれに比べてずっと短いですよね？つまり、50セントです。でも、結果は、先ほど言ったように、この特定のユースケースでは、結果は実際かなり良さそうです。ここには問題ありません。必要なものはすべて得られました。セキュリティの詳細、リスク要因、すべて正しい詳細、そして当四半期の収益と前年同四半期の収益についても、良い結果が得られました。しかし今度はこれをひねってみます。単純な戦略を失敗させます。
どうやってそれを行うのでしょうか？プロンプトを非常に、非常に複雑にします。ひとつ言っておくと、もちろん、この特定のプロジェクトを見ると、プロンプトが10個ありますよね？これは大規模言語モデルを10回呼び出さなければならないことを意味します。良いアイデアではありませんよね？プロフェッショナルなプロンプトスタジオのプロジェクトが実際にこのようになることはありません。通常は非常に、非常に圧縮されています。なぜなら、トークンを節約したいし、レイテンシも節約したいからです。では、たとえば同じプロジェクト、抽出したい同じ10個のフィールド、あるいは抽出したい中核情報を見てみましょう。そこで、シンプル検索を使ったコンパクト10-Qパーセルというものがあります。
これを見てみましょう。これです。さて、これは非常に興味深くなります。ここには単一のプロンプトがあります。私がやったことは、次の構造のSOオブジェクトを、その下にJSOオブジェクトを持つ形で作成して、と言ったのです。今回は、開示、収益詳細、リスク要因があります。そして同じプロンプトの中で個々のJSOオブジェクトを説明しています。
開示については、これがそのサブオブジェクトのあるべき形です、と言っています。収益詳細については、これがその形です、ということです。リスク要因はかなり単純なものです。ここでも、2つの大規模言語モデルを設定しています。今回は、ご覧のとおり、多くのトークンを使っていません。
しかし結果を見ると、ここにnullが見えます。これを開いて、展開してみます。この2つの大規模言語モデルからの応答を並べて見てください。まず、正しい値が得られていませんよね？ここではnullが得られています。これは非常に残念です。しかし一方で、純利益を見ると、ここは実際には間違っています。前のプロンプトからそれはわかっていますよね？つまり、654と157、そんな感じでした。
これも間違っていますよね？さて、問題は、私たちが単純な戦略を使っていることです。ですから、ここで設定に行き、私たちが使っている戦略を見ると、単純な検索戦略です。問題は、このプロンプト、この大きなプロンプト全体がベクトルデータベースに送られていて、関連するチャンクをください、と尋ねていることです。そして、そのチャンクがプロンプトと一緒に、これら両方の大規模言語モデルに送られていますが、結果として正しいチャンクが得られませんでした。ですから、このチャンクを見ると、必要な財務データがまったく見つかっていません。
おそらくいくつかのリスク情報は見つかっているのでしょう、そうですよね？しかし、正しい財務データは見つかっておらず、それがここで null が表示されている理由ですよね？ですから、これは予想されることですよね？したがって、ベクトルデータベースを正しく使う方法を理解しなければなりません。これは非常に重要です。ですよね？さて、私はまったく同じプロジェクトを持っています。変更は一切加えておらず、まったく同じプロンプトですが、サブ質問 rie を使っています。つまり複雑なプロンプトですよね？同じ複雑なプロンプトです。しかし今回は、設定で単純検索からサブ質問検索に切り替えました。すると何が起きるかというと、先ほど説明したように、大規模言語モデルを使って、いくつかの質問を生成するよう依頼し、それらが、ええと、その、ベクトルデータベースに送られます。
そして今回は、見てみると、両方の大規模言語モデルから正しい値が得られています。もちろん違いはあります。なぜなら、大規模言語モデルがリスクを要約する方法が異なるからです。そうですよね？私たちはそれを非常に要約するよう求めていますよね？高度に要約された値、と言いました。ですから Claude はやり過ぎなくらいに、本当に本当に、ええと、非常に要約していて、非常に簡潔な要約を生成しています。一方で、ええと、GT four はまだ要約を少しだけ、ええと、ええと、つまり、冗長に保っていますよね？でも、素晴らしいのは、今起きたこととして、プロンプトはまったく同じなのに、単純からサブ質問可能なものに切り替えただけで、正しい答えが得られたということです。そうですよね？ですから、これは素晴らしいことですよね？はい、ですので今、皆さんが、ええと、抽象プラットフォームについて、そしてまた、ええと、マルウェアについて、そしてコスト削減にそれをどのように使えるかについて、良い理解を得られたことを期待しています。では簡単に要約しましょう。そして、ここでほぼ時間どおりなので、いくつか質問を受けます。単純検索戦略がありましたが、サブ サブ質問、val 戦略もあります。すみません。そこでは大規模言語モデルを使って、ええと、検索関連のサブ質問を生成します。そしてループ内で、ええと、ベクトルデータベースに関連するチャンクを尋ねます。
重複を排除します。ええと、もちろん、ええと、皆さんも、単純戦略が失敗した理由は、つまり、これらのチャンクがドキュメント全体に散らばっているからだと理解しているでしょう。ええ、そうですよね？ですから、サブ質問なしでは、正しいチャンクを取得するのに苦労していたのです。そうですよね？そして、ええと、もちろん、ええと、ここでの議論全体の要約を本当に見てみると、フルドキュメントを見る場合、通常は非常に高い精度が得られます。なぜなら、大規模言語モデルは完全なコンテキストを持つ傾向があるからです。この場合、それは30ページ程度だったので、大規模言語モデルのコンテキストに収まります。しかし問題はコストです。精度は本当に非常に高くなりますが、スケールして使用する場合には現実的ではありませんよね？次に単純検索が来ました。ええと、それは最も低コストです。なぜなら、ええと、通常は数個のチャンクを取得して、それが何であるかを大規模言語モデルに尋ねるだけで、そしてそれは答えます。私たちの場合、それは全文書よりも、たとえば8テキスト少ないようなものでした。ですから、ここがベクトルデータベースが、ええと、構造化ユースケースにおいて本当に力を発揮するところです。
ええと、でも一般的に、単純な検索では、高い精度は期待できません。ええ、特にプロンプトがどんどん複雑になる場合はなおさらです。ええと、通常はこの戦略の使用は避けるべきです。ええ、簡単なテストなどには問題ありません。ええ、大規模言語モデルがサブ質問の生成に関与しないため、通常はより高速です。ですから、時間を多少節約できる傾向がありますし、コストもいくらか抑えられます。ただし、繰り返しますが、これは存在する中で最良の、ええ、検索戦略ではありません。
ええ、サブ質問戦略は、その一方で、物事をはるかに良くしますよね？つまりプロンプトを理解し、必要なサブ質問を生成し、大規模言語モデルに質問します。かなり高い精度が得られます。完全なドキュメントほどではありません。すべての情報、すべてのコンテキストを持つことに勝るものはないからです。ただ、繰り返しますが、ええ、精度に関して言えばそれにかなり近い2番手ですし、そして、ええ、ベクトルデータベースの力を大規模言語モデルと組み合わせて本当に活用し、この特定のユースケースを解決することができますよね？では、ええと、ここでの議論は以上です。少し時間がありますので、Timに戻して、何ができるか見てみましょう。はい、ええ、いくつか質問があります。
ええ、幸いにもあなたの同僚の、ええ、Narenがそのいくつかに回答していますが、ええ、どれがまだ、ええ、回答されていないか見てみます。Aaron Cohenからのこちらですが、あなたのシステムは抽出の信頼度を報告しますか、または手動レビューや微調整を可能にしていますか。それ、それは正しいです、Aaron。つまり、ええ、LLM challengeは、最初の抽出に対して2つ目の大規模言語モデルを使ってスコアを生成します。そして、ええ、手動レビューもシステム内に存在するものです。ですから、ええ、prom studioプロジェクトの宛先を手動レビューキューとして設定でき、そこではソースドキュメントと抽出された値を並べて見ることができます。抽出された値をクリックすると、その値が変更されたかどうかに関係なくハイライトされます。ええ、フォーマットは、そうですね、大きく変更されているかもしれません。
それは問題ではありません。つまり、ええ、ソースドキュメント内でハイライトされます、ええ、そうです。ですから、ええ、そして、ええ、はい、いつでもそれを行うことができます、はい。はい、もう1つあります。ええ、unstrはunstructured IOやllama parseと異なるのですか、それらではlmsによって動かされているとしても汎用的な抽出が得られる一方で、UNSTRでは関心のあるフィールドに対してプロンプトを指定できる、という点で。
その通りです。つまり、unstructured IOとLAMA partsはテキスト抽出サービスです。つまり、大規模言語モデルで消費できるようにドキュメントを準備します。そして、そして、unstrは非構造化、ええ、データ抽出、つまり非構造化ドキュメントからの構造化データ抽出のために目的特化して構築されています。ですから、LLM Whispererはunstructured DやLAMA partsに相当しますが、オープンソースのunstuckプラットフォームは、はるかに多くのことができます。
そして、LLM challengeやその他すべてのものもあります。はい、とても素晴らしいです。ええ、その質問は回答済みでした。正確な値を抽出しようとしているのですか、それとも要約分析ですか？おそらく両方が可能でしょう。はい、両方可能です、そうですよね？つまり、正確な値を抽出したいわけで、それは非常に重要です、そうですよね？非構造化ドキュメントを構造化するとき、それを再現可能に行いたいわけです。そこで、そうですね、pro Studioが登場します。
とても素晴らしいです。ここでもう1つくらいの時間があると思います。LLMに複雑なクエリをサブ質問に分解させる信頼性について、もう少しコメントできますか？精度と成功率はどのくらいですか？それは素晴らしい質問です、そうですよね？つまりこういうことです、そうですよね？ここがLLMとベクトルデータベースが連携して機能するところです、そうですよね？そしてプロンプトを調整し、多くのドキュメントを与える必要があります。だからこそPrompt Studioに多くのサンプルドキュメントを読み込めるのです。私が言ったのは代表的なサンプルです。
ですので、まず第一に、適切な代表サンプルを用意する必要があります。通常は15〜20件のドキュメントを推奨しています。同じドキュメント内にあるものです。タイプに大きなバリエーションを持たせて、それからプロンプトを調整します。Vectorデータベースから適切なチャンクを取得できていることを確認してください。uiでそれらを確認できます。本当に適切なチャンクを取得できていることを確認してください。
それから、つまり、プロンプトを調整して、実際に取得できていることを確認します。最後の言語モデルによって、サブ質問の品質は変わります。そして、ええと、抽出しようとしているものに基づいて、ある程度微調整して、そこから進めていく必要があります。かなりいいですね。うーん、これは興味深いです。彼らが何を指していたのかはわかりません。
もしかすると、これはあなたには意味が通じるかもしれません。Oscar Monroeさんが質問しました。自分のプロジェクトで使用するために紹介されている現在のモデルアーキテクチャに興味があります。これは利用可能になりますか？コンセプトは素晴らしかったです。はい。ですので、ええと、おそらくあなた自身で何らかのファインチューニング済みモデルを持っているのだと思います。
はい、Ractが持っているコネクタの一つに、ええと、O Lamaコネクタがあります。ですので、自分のモデルをo lama上でホストして、それに接続できます。ええ、はい、まさにそれは可能です。とてもいいですね。そろそろ時間切れだと思います。かなり素晴らしいウェビナーだったと思います。
良い質問がたくさんあり、参加者数もまずまずでした。スライドを提供し、この録画もまもなく提供します。ここに来ていただけて本当に良かったですし、早く、対面でabstractがあります。私のドキュメントをいくつか見てもらうことになるかもしれません。それから、ええと、そこでクールなミートアップを行うことになるでしょう。ですが、参加してくださった皆さん、ありがとうございました。
素晴らしい質問をありがとうございました。ええと、またお会いしましょう。来週も別のウェビナーがあると思います。それもそこに入れておきます。素晴らしいことがたくさん進行中です。改めて皆さん、ありがとうございました。ホストしていただきありがとうございます。
ありがとうございます。はい、いつでも。素晴らしかったです。さようなら。皆さん、またお会いしましょう。
Meet the Speaker
Join the session for live Q&A with the speaker
Shuveb Hussain
Co-Founder & CEO, Unstract
Shuveb Hussain is the co-founder and CEO at Unstract, an open source startup building an LLM-powered platform that extracts data from unstructured documents, helping automate critical business processes. Before co-founding Unstract, he was VP of Platforms Engineering at Freshworks (NASDAQ: FRSH). He’s also an electronics hobbyist. He no longer voluntarily corrects spelling and grammar mistakes committed by others.