Join the Webinar
Loading...
何を学べますか？
組織がGenAIの高価値なユースケースを特定し、プロトタイプを作成した後、本番環境への道のりが始まります。Day 2に向けたこの道のりでは、スケーラビリティ、ガバナンス、自動化、エラー処理など、主要な運用上の懸念事項が浮上します。
AIアプリを支えるデータパイプラインには、エンタープライズ文書やデータの継続的かつ自動化された取り込み（CDCに似ていますが、マルチモーダルの世界向け）のための機能を提供する必要があります。
取り上げるトピック：
- Apache NiFiを搭載したDatavaloのライブデモ
- データエンジニアがAI向けの本番品質のマルチモーダルパイプラインを実装する方法
まだログインしている人がいるようなので、もう少しだけ待ちます。でも、ええと、今日のセッションについて紹介したいと思います。先ほど言ったように、マルチモーダルパイプラインで、これは、ええと、とてもクールなものです。本日のスピーカーはSamです。Samは18年以上の経験を持つ熟練したテクノロジーリーダーです。私はSamと、ええと、HortonworksかClouderaか、その時どう呼ばれていたかはともかく、そこで一緒に仕事をしていました。
彼はデータエンジニアリング、分析、AIに関する多くの技術における本物の専門家です。そして、ええと、現在はData VoloのCTOで、フィールドエンジニアリングチームを率いています。これは本当に素晴らしいことです。彼はGoogleやDatabricks、Hortonworks、そして多くの素晴らしい企業の出身です。それでは準備ができていれば、参加者数も安定したようなので。ええと、Sam、ようこそ。始めてください。
ありがとうTim。ここにいられてうれしいです。本日のウェビナーにお招きいただき、とても感謝しています。ええと、丁寧なご紹介をありがとうございます。Timと私は、ええと、HortonWorksのデータエンジニアリング領域で一緒に仕事をしてきました。そして、ええと、再び協力できることをとても楽しみにしています。
ええと、今日はAIアプリケーションの採用におけるday twoの局面と、それがデータプラットフォーム、データエンジニアリング、そして企業が成功するために必要な全体的なAIスタックに何を意味するのかについてお話ししたいと思います。まず、AI市場の現状について、データセットの課題という観点からいくつか観察したことから始めます。それから少しデモをお見せします。時間があれば2つの異なるデモを用意しています。ええと、Data Voloプラットフォームをお見せし、ragのhello worldのようになっているもの、つまり金融の10-K文書の処理に取り組みます。これにより、金融アナリストのユースケースのスタイルで、自分のドキュメントとチャットするために必要な正しいデータを取得できるようにします。
ええと、最後の方で、ええと、質問も楽しみにしています。ええと、Q&Aのために十分な時間を確保できればと思っています。では、ここで画面を共有して、ええと、過去、ええと、数年にわたって多くの企業と仕事をする中で私が得た、いくつかの観察に入っていきます。Timが言ったように、私はGoogle Cloudで約4年間を過ごしました。DatadogやMongoDB、Collibraのようなデジタルネイティブ企業がデータアーキテクチャを構築し、Geminiのような言語モデルを採用するのを支援していました。当時はPalmだったと思います。
ええと、私が見た大きな課題の一つは、AIアプリを成功させるために必要なデータツールに対するディスラプションについて、皆さんが十分な時間をかけて考えていなかったことです。そして、どのようなAI戦略でも、どのようなAIアプリケーションでも、データ準備の側面に本当に注力する必要があるという認識がもっと必要でした。また、アプリ層を成功させるための適切な基盤を、ええと、整えるためには、新しいツールや新しいフレームワークを採用する必要があるかもしれません。では、それに関連するいくつかの観察です。LLM APIが最初に登場したとき、誰もがそれを単なるAPIとして扱い、アプリケーションを構築するにはそれで十分だと考えていたと思います。そして過去数年でわかったことは、それが実際にはそうではないということです。
必要なのは、よりAIスタックに近いものです。その一部が今日お話しするデータパイプラインソリューションですが、これには他にも多くのコンポーネントがありますよね？ベクトルデータベースの側面があります。ええと、visのようなソリューションでは、リスクを軽減し、アクセスの安全な強制を行うために必要なガードレールがあります。ええと、評価を行い品質を確保する必要もあります。つまり多くの新しいツールがあり、特にこの、ええと、AIの波の以前にML opsや検索の世界にいなかった企業にとっては、その多くが非常に新しいものでした。
ええと、私たちが目にしたもう一つの大きな課題は、当初、私たち自身のコンテキスト、自社のエンタープライズ文書やデータをここに取り込みたいと考えていたのですが、適切な検索プラットフォームがなければそれは困難だったということです。そこで最初は、皆がファインチューニングやその他の方法で、自分たちのコンテキストやデータを言語モデルに取り込もうとしました。ええと、しかし検索、そして今日さらに詳しく話すパターンは、そのエンタープライズのコンテキストを取り込むための事実上の方法のようなものになりました。そしてプロプライエタリなデータこそが、ユースケースによっては本当に価値が存在する場所ですが、企業にとってのより深い価値には、そのプロプライエタリなコンテキストをアプリケーション層に取り込むことが本当に必要です。ここでの最後のポイントは、この領域、そしてより広く ML ops や AI アプリケーションにおいて、評価が極めて重要だということです。
特に、チームには評価ファーストの考え方で考えることを強く勧めます。新しいアプリケーションやユースケースの開発を考える際には、そのアプリケーションの成功をどのように評価するのかを、最初の段階で考えてください。では、評価データセットをどのように構築するのか？データが変化し、ユーザーが尋ねる質問が変化していく中で、検索の有効性をどのように継続的に監視するのか？これは本当に重要であり、この領域では困難でもあります。なぜなら、モデルが非決定的であることを私たちは知っているからです。また、これらのアプリケーションの一部において、良い応答がどのようなものかは非常に主観的になり得ることも知っています。ですから、ええと、異なるラベラーから一貫して良質なラベル付きデータを得ることさえも課題になり得ます。
ですので、これは取り組むべきある種の新しい世界であり、特に2つ目のデモで評価についてさらに話します。さて、今日お話しするパターンは、検索拡張生成です。これは、企業全体に存在するコンテキストに LMS をグラウンディングするための方法です。課題は、そのコンテキスト、その根拠のある、ええと、真実を、適切な形式で適切なタイミングにアプリケーション層、モデルへどのように届けるかです。そして、それをどのように有用なものにするかです。データ統合市場で私たちが本当に見ているディスラプションは、非構造化データをめぐるものです。ご存じのように、Tim と私が Hortonworks にいた頃、私たちはその当時、非構造化データの価値について話していました。それは、ええと、今からもう8年か9年前だったと思います。
ええと、しかし私たちは、非構造化情報、マルチモーダル情報、文書や音声、画像のようなものの価値を解き放つという点で、必要なところまで本当に到達することはありませんでした。今日 AI によって私たちが目にしている最も深遠なパラダイムシフトの一つは、過去に数値に対して計算を行えたのと同じように、今では言語に対して計算し、画像や文書に対して計算できるようになっていることだと思います。そしてもちろん、その一部は埋め込みそのものであり、それらはある意味で、何らかの高次元空間において、これらのものを数値として表現します。ええと、しかしこれは従来のデータツールが本当に対処に苦労するものであり、特に大規模になるほどそうです。そして、1日目に価値を見いだし、ユースケースを洗練させた後の2日目の瞬間、その2日目の瞬間はすべてスケールに関するものです。
それはすべてレジリエンシーに関するものです。長期にわたって堅牢でレジリエントであるパイプラインや、ええと、デプロイメントアーキテクチャを構築することです。そして、それこそが Data Volo が設立された目的です。ええと、私たちは Tim が言及した Apache NiFi というオープンソースプラットフォームによって支えられており、それについてはさらにお話しします。しかしここで、全体的な AI スタックの中に Data Volo を位置付けてみましょう。
では、この、ええと、ここにある紫色のボックスの中に見えるものすべて、ちなみに、Zillow と Data Volo のブランディングや色が最近とてもよく調和しているようで、私は気に入っています。素晴らしいことです。ええと、ですが、その紫色のボックスの中にあるものすべてが、機能という観点で Data Volo が提供するものです。つまり、データを取得し、データを変換し、Zillow のようなベクトルデータベースやその他の検索プラットフォームにロードする、従来の ETL ステップを考えてください。そこには、ええと、elastic search のような従来型検索も含まれますし、ドキュメントストアも含まれます。よりハイブリッドな検索パターンを使うことになるパターンは数多くあります。メタデータでフィルタリングするかもしれませんが、検索プラットフォームと、vis のような密検索プラットフォームの両方からの結果を融合することもあるかもしれません。
ええと、このもう一つの側面は、これらのパイプラインのオーケストレーションです。では、どうやってそれらをスケジュールできるのか。どうやってデータをバックフィルできるのか。上流システムがオフラインになっている可能性があり、再試行し、ええと、一部のデータをバックフィルする必要がある場合にどう対応できるのか、あるいは処理すべき変更量が多く、それを効果的に管理する必要がある場合にどうするのか。そしてそれには、バックプレッシャーやその他の主要なパイプラインオーケストレーション機能が含まれることがあります。そして、この最後の部分はオブザーバビリティに関するものです。Data Volo では、オブザーバビリティは組み込みであるべきだという考え方を持っています。
これは、私のパイプラインで何が起きているのかを見るために別のコンポーネントを追加する必要がない形で、プラットフォーム自体の不可欠な一部であるべきです。そして私たちは、評価と検索有効性を、パイプラインの健全性を見るためのもう一つのレンズにすぎないと考えています。したがって、それを長期的に観測し、監視することも重要になります。では、Data Volo の仕事が終わるのはどこかというと、実際には vis のようなベクトルストアにロードした時点です。私たちはデータエンジニアというペルソナに焦点を当て、データを取得して AI アプリケーションレイヤーで有用にするために必要な、ええと、データエンジニアリングに焦点を当てています。
私たちはアプリケーションのフロントエンド側には焦点を当てていないので、LM の経路上にも、検索の経路上にもいません。パイプラインがその役割を果たしたら、その部分の、ええと、問題は解決されたことになります。そして、そこが Data Volo の仕事が大部分終わるところです。世の中のいくつかのフレームワークには、少しアンチパターンを見てきました。ええと、それらはデータの課題やデータロードの側面を、アプリケーション UX やプロンプトエンジニアリング寄りのものと混同しているように見えます。そして私たちは、ええと、検索をうまく機能させるには、それをデータランドスケープの中に位置づける必要があると固く信じています。
それをデータエンジニアが解決すべき問題として位置づける必要があり、アプリケーション側とデータ側の間に明確な分離が本当に必要です。ちなみに、以前の ml の波でもそれを見たと思います。それはスキルセットとして、またペルソナとして、まさにデータエンジニアの領域でした。そしてそれが生まれたのは、つまり、データサイエンティストや ML エンジニアは、予測モデルを構築し、良い結果を出すことに非常に優れているからです。彼らはトレーニングと評価、そして強力な、ええと、予測に焦点を当てています。
必要となるフィーチャーエンジニアリングの一部やデータ作業の一部は、データエンジニアリングチームの得意領域により近いものです。そして私たちは、同じパターンが今 LLM の領域でも繰り返されていると考えています。ええと、だからこそ私たちは、この問題のデータ部分を解決することに本当に集中しているのです。さて、ええと、では 10 x データエンジニアをどう実現するのでしょうか。Tim が言及したように、私たちは Apache NiFi というオープンソースプラットフォーム上に構築されています。これは大規模環境で実証済みのプラットフォームです。世界中の 8,000 を超えるエンタープライズに導入されており、ええと、金融サービス、防衛、ヘルスケア、通信など、高い、ええと、セキュリティ態勢と規制が求められる多くの分野で利用されています。したがって、セキュリティとスケールに関するエンタープライズレディネスの基準を満たすことは、ええと、NiFi がこの 10 年ほど行ってきたことなのです。
ええと、私たちは本当にオプショナリティと、ツールを組み合わせて使うというUnix的な考え方を推進しています。私たちはブラックボックスになりたくありません。AI向けETLスタックのさまざまな部分について優れた実装を持ちつつ、プラグイン可能でありたいと考えていますが、同時に、皆さんが自分たちのモデルや独自の変換処理を差し込めるようにし、エコシステム全体を通じて柔軟性とアグノスティシズムを本当に推進したいのです。私たちはそのエコシステムに対して非常に多くの連携を作ってきましたし、デモではそのさらなる例を見ることになります。そして、オブザーバビリティとセキュリティは、本当に最低限必要な要件です。
それは組み込まれていて、そのまま機能し、実装や設定も簡単です。では、Data Voloでは何をしてきたのでしょうか？私たちは昨年末に始動し、注力してきた大きな要素が3つあります。まず1つ目は、クラウドネイティブな提供形態です。私たちはSaaSとしても、Bring Your Own Cloudモデルとしてもデプロイします。これはZillowのデプロイ形態ともかなり似ていると思います。
完全なサーバーレス型のオプションを選ぶこともできますし、皆さんのクラウドVPC内に私たちのプラットフォームをデプロイすることもできます。また、Snowflakeのようなプラットフォーム上にネイティブにデプロイすることもできます。そして、自社データセンターにData Voloをデプロイしたい方々向けに、Dockerベースのディストリビューションも提供しています。もう1つの大きな側面は、セキュリティをいかに容易にしたかです。ご存じの通り、セキュリティを適切に実現するのは多くの場合難しい課題です。
最も安全なシステムとは、ある意味で誰もアクセスできないシステムです。ですから、トレードオフのバランスを本当に取る必要があります。私たちは最高のセキュリティ態勢を備えつつ、ユーザーが実装や設定を簡単に行えるようにすることを目指しています。そして、マネージドサービスの多くは、それをさらにずっとシンプルで簡単なものにします。それから先ほど述べたように、私たちはAIシステムのニーズに懸命に取り組んできました。これには、データを取得するための適切な連携、そのデータを有用にするための適切な変換、機械学習モデルの活用、そしてチャンキングやエンベディングのようなデータ変換のさまざまな方法が含まれます。これにより、優れた検索と取得ができるようになり、それをデモで見ていただきます。
そして、適切なデータを適切なシステムにロードする能力です。私たちはリリースしたvis連携に非常に期待しています。より広範なエコシステムとの連携もあります。つまり、AriseやGalileoのような評価やフレームワークであれ、DAAやPuebloのようなセキュリティやフレームワークであれ、私たちはAIスタックにおける多くの主要プレイヤーと提携し、保守可能で、箱から出してすぐに使いやすい連携を提供しています。そして、その保守性の部分について少しだけ触れておきます。
多くのAIアプリケーションでは、繰り返しになりますが、初日の段階では始めるのは非常に簡単です。しかし、これらを実際に本番環境へ実装しようとすると、多くのフレームワークやAPI、OpenAI、Anthropic、Google、LangChain、LAMA Indexにおいて、多くの変更と大きな変動が発生することになります。これらのライブラリにはあまり安定性がありません。そのため、私たちが連携を構築する際には、それを長期的に保守し、適切なバージョン管理と、容易に採用できる適切なデプロイ戦略を提供するという負担も引き受けています。ですから、なぜData Voloを使うのかを考えるうえで、これは重要なポイントです。
私たちは、これらの連携を保守し、保護するという多くの負担を引き受けています。それは、皆さんのチームが差別化につながらないコードとして行う必要のないことです。では、おそらく最後のスライドです。その後、デモに移りましょう。ええと、あわせて強調しておきたかったのは、Data Voloはストリーミングプラットフォームだということです。継続的で自動化されたプラットフォームです。取得において私たちが気づいたことの1つは、メタデータがどれほど重要かということです。
つまりメタデータは、ええと、埋め込みに対してセマンティック検索を行う前に、次元によるフィルタリングに使われます。メタデータは結果のランキングにも使えますよね？生成のためにLLMへ送る前に、結果を正しい順序でランク付けすることが重要です。また、認可や検索の安全な強制適用にもメタデータを使うかもしれません。ご存じのように、SamとTimは、組織内で同じチームに所属していないかもしれませんし、基盤となるソースドキュメントに対する権限やアクセスが異なるため、チャットボットから同じ回答を得る資格がないかもしれません。そこで私たちは、非構造化データ向けのCDC、つまり変更データキャプチャについて話します。なぜなら、Google DriveやSharePointといったさまざまな上流システムからイベント駆動型で変更を取り込み、その変更を下流へ伝播できるからです。
アクセス制御において、これは非常に重要です。Timのドキュメントへのアクセス権が変更された場合、私たちはそれをすぐに知りたいでしょう。その変更をベクターデータベースまで複製し、更新されたメタデータを強制適用に使えるようにしたいのです。では、その流れでデモに入りましょう。ええと、プラットフォームパートナーシップや、もちろんエコシステム統合については、さらにお話しできます。
今日の注目はZillowです。では、data volo uiに移ります。冒頭で説明したように、ええと、このデモは実際には、NvidiaやAppleなどのいくつかの異なる企業から財務10-Kを取得し、それらを解析し、チャンク化し、埋め込み、保存することで、自分のデータとチャットできるチャットボット体験を構築できるようにするものです。数百ページに及ぶこれらのドキュメントから、非常に素早く簡単に正しいインサイトを得たい金融アナリストのようなペルソナを想像してください。ええと、これから見るように、これらのドキュメントには複雑な要素が含まれています。
表があり、セクションがあり、マークアップはありません。つまり、HTMLドキュメントやMarkdownドキュメントのように、そのマークアップによって分割できるものとは違い、pdfにはそれがありません。そのため、実際にはそのマークアップを導出し、そのメタデータを導出して、正しい方法でチャンク化する方法を把握する必要があります。ええと、そしてもちろんragでは、良い検索効果と、言語モデルからの良い生成の両方を得られるように、データをどのように最適に分割するかというバランスを常に取っています。では、ドキュメントをどのように取得するのでしょうか？標準で提供される統合は350以上あります。
今日はS3をお見せしています。ええと、しかしこれはさまざまなシステムのホストであり得ると想像できます。ご存じのように、先ほど触れたGoogle Driveの変更のいくつかについて考えると、それらをイベント駆動型でキャプチャできますし、SharePointに対してそれを行いたい場合もあるでしょう。ええと、ここで話せるシステムは本当にたくさんありますが、ええと、思いつく主要なエンタープライズプラットフォームのどれについても、組み込みの統合があります。このプラットフォームは拡張可能でもあるため、独自のものを構築することもできます。
ええと、ただし今回は、すべてのドキュメントがS3にあり、そこから取得します。data Voloでこのような統合を設定するのは非常に簡単です。使用するS3バケットを指定しているだけです。それらにアクセスできるように、認証を提供するサービスを使います。ここで一つ触れておきたいのは、リスティング戦略です。
先ほど、Data voloは継続的かつ自動化されていると述べました。そのため、そのS3バケットに新しいデータが到着すると、すぐにフローに取り込みます。つまり、それらのドキュメントを着地させるプロセスがあれば、ほぼリアルタイムでそれらを取得しますが、古いドキュメントを再処理したくない場合もあるかもしれません。そのため、ここではこのタイムスタンプ戦略を使って、まだ見たことのないものだけを取得しています。そして、そのために少しの状態を保存します。
これは、新しいものだけを処理していることを確認するのにかなり便利で、このためのさまざまな戦略があります。ハッシュ技術を使って、これをエンティティレベルで追跡することもできます。そして、ですが、これは良さそうです。私は、ええと、データをリストした後、データを取得します。これを2つの異なる部分で行うのは、これによって非常にスケーラブルになるからです。
ええと、私たちは Kubernetes 上で稼働しています。ですので、ここで見ているこの環境は、私たちの SaaS 環境内の EKS にあります。そして、ボリュームに応じて水平スケールしていきます。ここには、リスティングが 1 つのノード上だけで実行され、その後、そのメタデータのリスティングを多数のノードに分割して、すべてが並列にデータを取得し、互いに干渉しないようにする、というパターンがあります。また、私たちはプロビナンスもキャプチャします。
つまり、data volo 内で見ているこの有向グラフ全体において、ここでのプロセッサ間のあらゆる状態変化が、プロビナンスイベントとしてキャプチャされます。特に、私が生データを取得したとき、ええと、ここで出力を見ることができます。ここにはこの Nvidia の PDF があり、これは、複雑な情報が大量に含まれた 100 ページの 10-K です。ドキュメント内を下にスクロールしていくと、表のようなものがあります。ええと、これらの表をどのように解析するかについては非常に注意する必要があります。
これを半分に分割して、その参照整合性を損なうようなことはしたくありません。ええと、チャートや画像もあり、これらも同様に重要になります。ですので、このデータをどのように解析するかを、このあとすぐ見ていきます。では、いくつかのものを整理します。URL と DOC タイプを設定します。
ええと、データエンジニアはこのイベントに対してさまざまなメタデータを設定できます。ええと、これは本当に便利です。このデモ全体を通して、メタデータがテーマとして出てくるのを見ることになります。ええと、ただ、これがどのように見えるかをお見せするために、ええと、属性の中を見てみます。いくつかのメタデータは自動生成されており、その他はデータエンジニアによってキャプチャされています。データを vis に書き込む前に、そのメタデータをすべてまとめます。それによって、私が説明したハイブリッド検索のユースケースやランキング検索のユースケースの一部が可能になります。
この一部が S3 から取得されたことがわかります。ええと、そして元のソース、URL のようなものがあります。RAG アプリを行う場合、私たちは本当に引用をできるようにしたいですし、それがこのグラウンディングの、ええと、側面の一部ですよね。つまり、チャンクを返すとき、その元のソース URL と一緒に返したい場合がありますし、さらにこのあとすぐデモで見るように、ええと、セクションによってそれよりも具体的にすることもできます。では、生の PDF を取得した後、私は今度は、ええと、レイアウト検出と呼ばれることを行うためにコンピュータビジョンを実行します。レイアウト検出は、ドキュメントの各コンポーネントのバウンディングボックスとラベルを提供します。そして、ええと、ここの私たちの環境にはモデルがあります。
私たちはそれをファインチューニングし、カスタマイズしています。ええと、それは YOLO X というモデルの、ええと、先行技術に基づいていますが、これは共有サービス内の GPU 上で実行されています。そして、これを使ってそれらのバウンディングボックスとラベルを導出します。テキストレイヤーにない場合にテキストを抽出する必要があれば OCR もできますが、重要なのは、それらのラベルを使用するということです。そして、これが実際にどのように見えるかの例をお見せします。
UI にはこの PDF アノテーションビューアがあります。これは先ほど見ていたものと似ていますが、今度はドキュメントのさまざまなコンポーネントすべての周りに、これらのボックスとラベルがあるのがわかります。ですので、それらの、ええと、より複雑な要素のところまで下がっていくと、ええと、表のようなものが見えます。クリックすると、左側に実際にこの階層を構築していることに気づくでしょう。この階層は非常に便利です。なぜなら、ドキュメントをたどるとき、これをドキュメントグラフとして使いたいからです。
本質的には、兄弟要素を取得できるようにしたいのです。たとえば、この表には、その上に、表で何が起きているかを説明するナラティブテキストがあります。ええと、画像についても同様です。ですので、このような要素を取り囲む前後のチャンクを取得できるようにしたいのです。また、このドキュメントをセクションごとにチャンク化したいとも思っています。ここで緑色のテキストの中で、これを高い信頼度でセクションとして認識していることに気づくでしょう。そしてこれは、ええと、この階層は左側で折りたたむことができます。
つまり、これらのさまざまなナラティブのテキスト要素はすべてセクションに紐づいています。ですから、場合によってはナラティブなテキストの一部にマッチさせたい一方で、レスポンスを生成するためにLMへ送るプロンプトには、セクション全体のようなより大きなまとまりを取り込みたいことがあります。RAGでは常にこの「ゴルディロックス」ゲームをしているようなもので、クエリに対して良いマッチを得るためにembeddingでは適切な意味的精度が欲しい一方で、生成のためには十分な豊かさも欲しく、可能な限り多くのコンテキストをモデルに与えたいのです。そしてこの2つは実際には互いに押し引きし合います。したがって、そのトレードオフをどうバランスさせるかを決める必要があります。
画像についても同様で、ここがかなり面白いところなのですが、この画像についてembedしてretrieveできるものも必要になります。実際に画像そのものをembedするためにマルチモーダルembeddingを使うこともできます。そしてvision language models周りには非常に面白い取り組みがあります。Timと私は、Zillowのサポートという観点から、こうしたVLMモデル、つまりlate interaction retrievalモデルに必要なmulti-vector表現のいくつかについて話してきました。ただし、clipのようなマルチモーダルembeddingで画像をembedすることに加えて、language modelsを使って画像を説明することもできます。
するとlanguage modelは自然言語を返してくれるので、その自然言語をembedしてretrieveできます。そしてさらに、このグラフ、この階層構造を使って、ドキュメント内の位置関係に基づいて関連するチャンクを引き出すこともできます。つまり、このテーブルはこの画像に関連しており、その前にある説明もそれに関連しています。そしてそれらすべてが、Viss databaseに格納するparsed formatの中で利用可能になります。素晴らしいですね。
ええと、では。前処理段階でLSを使っていることにも気づくと思います。たとえば、それを使って画像を説明したり、テキストを要約したりするかもしれません。なので、私たちはlmの経路上にはいないと言ったとき、もしかすると少し嘘をついたかもしれません。ユーザーインタラクション中、つまりクエリ時やretrieval時にはLMの経路上にはいませんが、データをvector database内に格納する前に有用なものにするため、ETLプロセスやデータパイプラインではLMSをよく使います。では、メインのフローに戻りましょう。
ここで面白い点の1つは、ドキュメントの各コンポーネントに関するそれらの派生annotationを使って、それを異なる下流のparserへルーティングできることです。特に画像とテーブルを、異なる下流モデルへルーティングしています。ここに入ってくる画像については、先ほど話したように、GPT-4 oh miniを使います。ちなみに、data voloを使うと、モデル選択やモデルルーティングを非常に動的に行えます。これはますます重要になっています。なぜなら、一部のモデルは大きく、高品質なレスポンスを返すからです。
一方で、他のモデルはより小さく、品質はおそらくやや低いものの、より高速で安価なレスポンスを返します。したがって、データエンジニアとしては、高速かつ安価であることと品質とのバランスを取りたい場合があります。そして場合によっては、こうした小型モデルでもかなりうまく機能します。さらには、10億パラメータ以下のような、本当の意味でのs SLMs small language modelsも見られるようになっています。たしかにそれでも大きく聞こえますが、数千億パラメータ規模のモデルと比べると、ずっと、ええと、よりスリムです。
ただし、特に評価用途で使われるs SLMsも見られます。Galileoについて言及しました。彼らは非常に低レイテンシなものを作成しており、そのため大きな遅延を生じさせることなく、経路上で使用できます。ここではGPT-4 L miniを使っています。この画像を説明するのに役立つsystem promptがあり、その結果として自然言語が返ってきます。それを後でretrieveしたりembedしたりできます。テーブル側でも、ちょうどあのlayout detection modelと同じように。
また、独自の proprietarytable 抽出モデルも開発しました。これは実際には、テーブル transformer モデルです。ええと、これも先行技術に基づいていますが、これをカスタマイズし、チューニングしています。dock lane net のような大規模なデータセットがあり、複雑な PDF 内のテーブル例が多数含まれています。そのため、これらの公開されているデータセットを使用して、抽出を本当に改善しました。
このモデルの出力は、そして繰り返しますが、これは当社の SaaS 環境内の GPU 上で裏側で実行されている ML サービスを指しています。ええと、これは各セルから抽出された正しいデータ型を持つ行と列の CSV 形式の表現を提供します。これをデータベース内の variant テーブルにロードできます。解析して抽出することもできます。また、単にその中身を記述することもできます。繰り返しますが、言語モデルを使用します。
ええと、それでご存じのとおり、このステップを行う必要はないかもしれませんし、スキップしたい場合もあるでしょう。というのも、open AI に送信するトークンが増え、コストにつながる可能性があるからです。しかし、テーブル画像抽出器の CSV 出力も記述し、それを取得および検索できるものとして使用するのも良いと分かっています。ええと、最後に、このステップの終わり、またはこのサブフローの終わりで、すべてを再び結合します。覚えていますか、私たちは物事を分割しました。テーブル、画像、テキストを分割しました。
それから再び結合します。ええと、裏側では、ここでデータ provenance に入ると、ええと、これはどう見えるかというと、その PDF ビューアーではもっと見栄えが良いのですが、ここではちょっとしたお遊びとして、これがその解析済み情報の基礎となる JSON 表現です。そして、これを下流で使用して chunking や embedding を行います。ええと、この低レベルの表現に入りたい場合も、それができます。では、これですべてを再び結合しました。メインフローに戻ります。
前処理中にときどき行いたいことの 1 つは、enrichment を行うことです。つまり、先ほどのように evaluation first の考え方を持ち、ユーザーがこのデータをどのようにクエリするかを考えている場合、ユーザーはしばしば、たとえば NVIDIA の 10-K を扱っているとすると、その 10-K には含まれていないかもしれない企業としての Nvidia に関する質問をします。つまり、「NVIDIA の従業員数は何人か？」のような質問をします。ええと、あるいは「本社はどこか？」あるいは、ええと、複数の文書にわたって物事の傾向を見たいかもしれません。そのため、認識されたエンティティについてエンティティ認識と enrichment を行い、解析済み文書にさらに多くのコンテキストを取り込む必要があることがよくあります。この場合、NVDA のような ticker を抽出し、それを使用して、ええと、lookup を行っています。
ええと、ここには Postgres テーブルがあり、関心のあるいくつかの企業についての追加情報が含まれていて、それによってその追加の企業レベルのデータを取り込みます。しかし、これは任意のエンティティを enrich することだと考えられますよね？そのエンティティに関する情報を含む任意のナレッジベースやデータウェアハウスがある場合、文書だけを使用した場合よりも多くのユーザー質問に答えるために、それをここで retrieval system に取り込みたいかもしれません。つまり、enrichment ステップとはそういうものです。ここで chunking までスキップします。evaluation についても少し時間内にカバーしたいと思います。
では、この chunking サブフローを詳しく見ていきます。ここではいくつかの異なるパスで chunk していきます。最初のパスでは、その JSON 表現を期待する chunk document を使用します。そしてセクションごとに chunk します。ここで選べる戦略はいくつかありますが、セクションは非常に良いです。なぜなら、semantic precision の優れたバランスが得られるからです。
いくつかのことについて話しているだけです。ええと、でもかなり内容も豊富です。そして、あのレイアウト検出モデルでセクションラベルを導出していて、それらをチャンク化の境界として使う予定です。また、それらを境界として使うので、これらのテーブルや画像をチャンク化する際の問題にはぶつからないはずです。それらは別々に分割され、特定の項目を調整できます。
ええと、サブセクションを含めたい場合もあれば、含めたくない場合もあるかもしれません。これらのチャンクサイズやオーバーラップを調整したいかもしれません。ええと、それらは有用です。要するに多数のハイパーパラメータがあり、データエンジニアとして、AI エンジニアが扱うための最適なデータセットを得られるよう、最良の検索結果を得るためにそれらを調整しています。ええと、ただしこれは評価にも関係しています。どのハイパーパラメータ、どのチャンク化戦略、解析戦略が最良の検索結果につながるのかを把握できるようにしたいのです。
そして、これらの各ハイパーパラメータを評価指標と合わせて記録し、基本的にはデータサイエンスを行って、それらのハイパーパラメータ値と可能な限り最良の検索スコアとの相関を調べることができます。これについては間違いなくもっと話せます。ええと、では、これでセクションごとにチャンク化しましたが、最後にもう一度チャンク化の処理を行います。つまり、セクションのテキストが得られたら、そのテキストをさらにチャンク化することもできます。繰り返しになりますが、これは精度と豊かさのトレードオフを試したい場合に有用かもしれません。
ええと、できる最も単純なことは、あまりうまく機能しないのですが、異なる例を示すために、400文字ごとにチャンク化することです。つまり、これは単に400文字を使います。これは問題にぶつかります。ええと、たとえば意味的につながっているものを途中で分割してしまうかもしれません。文の境界や意味的な境界が何であるかという概念を持っていません。そのため、一般的にはあまりうまく機能しません。
ええと、ただし、このチャンクテキストプロセッサもあります。これをすべて分けている理由は、適切な評価を行うためです。並列で処理しているので便利ですし、vis に異なるコレクションを保存しているので、評価用データセットをそれらの異なるコレクションに向けて、どれが最も良い性能を示すか確認できます。別の選択肢としては、セマンティックチャンク化があります。ええと、セマンティックチャンク化では、文ベースの再帰的デリミタのようなものもあります。ここでも、類似度しきい値のようなものを調整できます。
これは連続する文のペア間のコサイン類似度を計算しています。つまり、その文の切れ目を探しますが、その後でコサイン類似度を比較し、しきい値を下回った場合にのみ分割とみなします。そしてそれを調整してきました。0.6 にはどうやって到達したのでしょうか？まあ、機械学習の多くのことと同様に、経験的にさまざまなものを試し、評価に基づいて最も良く機能したものを決めました。
ええと、機械学習では非常に一般的ですが、ハイパーパラメータ値としてこのような魔法の数字が出てきます。ただし、テストした別の選択肢もあります。そして 0.4 はあまりうまく機能しませんでした。つまり、これもまた調整して評価できるものです。
では、ええと、最終的なチャンクが得られたら、これが vis データベースに永続化する粒度になります。ここでは Zillow のサーバーレス環境を使用しています。ええと、ただしデータベースに書き込む前に、まず再度埋め込みを作成したいと思います。このフローのどの部分でも、ここに来て出力を見ることができます。この場合、テキストがあり、埋め込みの重みもあります。ええと、しかし非常に重要なのは、すべてのチャンクメタデータを取得し、それを埋め込み自体と同じ行に書き込みたいということです。
私がそのように行った方法としては、さまざまなメタデータパスをすべて1か所に整理しました。ここで注目すべき興味深い点は、これらのメタデータ要素のそれぞれが、前処理フローの異なる部分から来ているということです。システムによって自動的に設定されたものもあれば、機械学習モデルによって導出されたものもあり、データエンジニアによって設定されたものもあります。つまり、ドキュメントタイプやURLのようなものは、エンジニアがフロー設計の一部として設定しました。そして、プロセスのエンリッチメント部分を通じていくつかのものも取得しました。
たとえば、タイトル階層のようなものについては、そのPostgresテーブルでこの階層が何であるかを調べるためにシンボルを使用しました。そして、それもメタデータ要素として取得しています。では、このデータをMelに書き込む準備ができました。先ほど述べたように、私たちはZillow serverless環境を使用しているので、ここに接続サービスがあります。それを簡単にお見せすると、このserverless環境に入っており、非常に優れていてプロビジョニングも簡単で、パフォーマンスの観点からも非常によく機能します。
そして、あとは認証を設定するだけです。私たちはすべてをシークレットとシークレットマネージャーとの統合を使って保存しています。そのため、認証情報が漏洩する心配はありません。そして、どのコレクションに書き込むのか、チャンクコンテンツやメタデータなどを保存したいさまざまなパスはどれか、といったことを設定しています。また、生成時にモデルへ異なるテキストを送るようなパターンを行いたい場合には、コンテンツを保存することもできます。では、これでこのフローは完了です。
データをベクトルデータベースに書き込みました。ここからはAIエンジニアが引き継ぐ準備ができています。質問に移る前に、評価について少し話したいと思います。では、別の環境に移ります。この評価ファーストの考え方では、まず行いたいことは、評価データセットを取得または構築することです。
今回の例では、Wikipediaデータセットを使用しています。そして、これらのWikipedia記事に関する既知の質問と回答のセットがあります。ここでは例としていくつかだけ取り出しています。Wikipediaの記事としては、いくつかのホッケーの試合やホッケー選手に関するもの、さらにアイルランドやシカゴのコミュニティ活動に関する記事なども取り出しました。非常に多様なWikipedia記事のセットです。しかし重要なのは、評価データセットから来た質問と回答があるということです。ここでよく聞かれることの1つに、「そのデータセットがない場合はどうすればいいのか？」というものがあります。いくつか選択肢があります。
まず、人間の専門家を使うことが考えられます。これは、データにラベルを付けてQ&Aデータセットを構築する方法に似ています。また、利用できる過去の履歴データがあるかもしれません。たとえば、HRチャットボットのようなものを構築している場合、私は自分にこう問いかけます。過去にユーザーはどのようにHRから回答を得ていたのか？おそらくチケットを作成したか、メールを送っていたでしょう。過去に尋ねられた質問と回答の履歴を取得して、それを評価データセットの構築に使うことはできるか。3つ目の選択肢として、実際に言語モデルを使って評価データセットを合成的に生成することもできます。
つまり、回答がある場合、Jeopardyをプレイしているふりをして、モデルに質問を尋ねることができます。そうすると多くの場合、データセットを構築するために使える質問を合成的に非常にうまく生成してくれます。実際にはおそらく、これらの手法を組み合わせて使うことになるでしょう。しかし重要な点は、最初の段階でそのデータセットを取得、構築、合成しておかなければ、物事がどれほどうまく機能しているのかを知ることは決してできないということです。ですから、これは非常に重要です。では、これらの正解質問を使っていくつか前処理を行います。そして、ここでさまざまな埋め込みをたくさん行います。
ええと、質問を埋め込みます。正解データ、つまりその答えも埋め込みます。さらに、生成された答えも生成して、それも埋め込みます。これらのさまざまな側面それぞれについて、類似度の観点で比較する必要があります。では、質問を埋め込んだら、データベースにクエリできるようになります。前のフローで Elvis への取り込みを見たのと同じように、Mel this にクエリする機能もあります。
ええと、ここでも非常によく似たセットアップです。ここで行うのは、質問を取り出すことです。これがアプリケーション層にデプロイされていれば、ユーザーから来るものだと想像できますが、この場合は eval データセットから質問を取り出し、それを埋め込み、その埋め込まれたクエリを、埋め込まれた生成済み回答と照合します。では、評価とは実際に何を意味しているのでしょうか？ここでは評価指標の2つのクラスに注目しています。1つは従来の情報検索指標です。つまり、context recall、context precision、mean reciprocal rank のようなものです。そしてもう1つはエンドツーエンドの指標で、これは言語モデルの応答に基づくものです。
つまり、faithfulness のようなものです。これはフローの次の部分で見ていきます。さて、ええと、ここで私がやりたいのは、検索がどれだけうまく機能したかを評価することです。そして LM をジャッジとして使います。これがこのパターンの呼び名です。人間のラベラーに評価してもらうのではなく、LM に評価してもらいます。そこで質問を送り、結果も送ります。
Novus に対してこのクエリを実行したとき、出力を見ると、ええと、結果が得られましたよね？最初の例を取り上げると、Buffalo Saber と Edmondson Oilers の NHL の試合における3人のスターは誰だったのか？ええと、答えがあり、q and a データセットからの正解データがあります。ただ私がやりたいのは、その質問を取り出して、viss にロードしたデータに基づいて確認することです。簡潔にするためにそのステップは省略しましたが、チャンク化した後に、このデータもすべて viss にロードしました。ここで見えているスコアは、質問と、ベクトルデータベースに保存していた取得済みチャンクとの間のコサイン類似度です。ですので、ここでは K equals three、つまり結果を3件だけ取得しています。ええと、それらが得られた結果であり、それをこの統合に渡しています。この場合は GPT for oh, mini を使っています。
ええと、つまりそれがコンテキストで、正解データが答えです。そして検索結果をいくつか永続化します。それを見てみることができます。ええと、これで検索結果があります。recall precision のようなものがあり、ええと、それから F1 score があります。これは recall と precision の組み合わせです。なぜなら、これらは互いに押し引きするからです。
別の F score は recall と precision の調和平均です。そして mean reciprocal rank も計算できます。言語モデルが私たちに伝えているのは、与えられたステートメントが実際に提供されたコンテキストと一致しているかどうかです。つまり、ある chunk ID について、これは一致しており、その理由も示されています。これはすべて言語モデルから返ってきたものです。
コンテキストにはそれら3人のスターが明示的に列挙されており、これらが3人のスターで、名前もあり、理由もあります。つまり、これらの attribution scores を導出できるわけです。これは人間のラベラーでもよかったのですが、ここではより自動化された方法で行うために LM を使っているだけです。そして、これらの attribution があるので、適切に evaluation を行うことができます。ええと、次に必要なのは、つまりこれらはすべて retrieval metrics です。
リコールと適合率を計算できました。これを使って、最初のデモでパースとチャンク化がどれほどうまく機能したかを判断できますが、今度はエンドツーエンドの部分をやりたいと思います。では、それはどういう意味でしょうか？今度は、提供されたコンテキストから言語モデルを使って回答を生成したい、ということですよね？それこそが検索拡張生成の要点です。つまり、回答を生成し、その回答を評価データセットに含めていた正解データと比較します。では、回答を生成し、正解データを埋め込み、生成された回答を埋め込んだ後、今度は他の2つの指標を評価できます。
1つ目は回答の正確性で、最後の1つは忠実性です。回答の正確性はF1スコアの関数となり、正解データが生成された回答とどれほどうまく比較できるかに関連します。これを見てみると、ええと、ここでさらに興味深い出力が得られます。ちなみに、これらの結果を実験用のフレームワークに送ることもできます。多くの人はML flowやweights and biasesをML opsの実験トラッカーのようなものとして使っていて、私たちはそれらとの連携機能を持っています。
ええと、ただ今は、検索指標と実際の回答の正確性評価の両方があります。生成された回答があります。ええと、生成された回答と正解データの埋め込みを計算し、それから回答の正確性を評価できました。ここでは、上位K件の結果全体の平均で96%という非常に高いスコアが得られました。ええと、ただ明らかに最初の回答が最良でした。
ですので、これを、データパイプラインをどのように構築しているかへのフィードバックとして使い、どの戦略が最適かを判断できます。ただ、回答の正確性が単一の数値で得られるのは便利です。そして最後が忠実性です。信じられないかもしれませんが、ええと、これらのモデルはまだハルシネーションを起こすことがあります。正しい読み取り順序で素晴らしいコンテキストをすべて与えたとしても、別の内容を生成しようとすることがあります。
ええと、忠実性はそれを測る指標です。つまり忠実性は、取得されたチャンクから事実の記述のような主張を抽出し、質問に答えるためにその取得されたコンテキストの何パーセントが使われたかを計算します。では、ええと、このステップを最後に見てみると、忠実性についても評価しており、ええと、ここでは良いスコアが得られました。つまりモデルは、質問に答えるために取得されたコンテキストを使っています。回答に余計なノイズは追加していません。
ええと、最後にこれらの指標を記録できます。ML flowは連携の1つです。ええと、ここではDatabricks環境を使ってML flowと連携しており、時間の経過とともに追跡するさまざまな実験を持ち、それらをハイパーパラメータ値に結び付けることができます。さて、楽しんでいただけて、興味深かったことを願っています。ええと、ここで一旦止めて、聴衆からの質問に移りましょう。
では、何が来ているか見てみましょう。チャットのQ&Aを確認します。はい、ええと、チャット内のQAから短い質問が1つありますので、読み上げます。AIアプリを成功させるために、なぜ新しい種類のETLプラットフォームが必要なのでしょうか？素晴らしい質問です。ありがとう、Tim。
これは、Data Voloが会社として存在する理由の核心に関わるものです。ですので、この質問はとてもありがたいです。まず私たちが目にしたのは、非構造化データに関連するETL市場の混乱だと思います。多くのシステムは、実際にはリレーショナルデータをデータベースからデータウェアハウスへ複製するように構築されており、データを取り込んだ後に変換を行うELTパターンに近いものを持っています。埋め込みの場合、それは実際には当てはまりませんし、埋め込みはこのAIの波における重要な残存物の1つになると思います。
私たちはそれらを、より第一級のデータ市民として認識するようになるでしょう。ええと、埋め込みについて分かることの1つは、後から実際に変換することはできないということです。ええと、このELTパターンは実際には使えません。メタデータ取得を含む変換を前処理レイヤーで行う必要があります。そのためにdata voloは構築されています。
まず第一に、基盤技術である NiFi は、ええと、あらゆる形式のデータ、本当にあらゆるバイトストリーム、音声、動画、画像、テキストを扱い、それを非常にスケーラブルな方法で行えるように構築されています。ええと、しかしこの最後の部分として、データを着地させる前に、それを有用なものにする必要もあります。そこで私たちは、適切な情報をよりよく抽出し解析するために、これらの ML 搭載モデルに投資してきました。ですので、複雑な PDF を扱っている場合、データを正しくチャンク化できるように、ええと、あの、セクションのメタデータ導出を行える必要があります。テーブルを認識し、表形式データを正しく抽出する必要があります。
それらは、マルチモーダルデータ向けに設計された ETL プラットフォームに求められる投資の類です。納得できますね。別の質問を確認します。はい、はい、私は NiFi と非構造化データでかなりクールなフローをいくつか作ったことがあります。それは本当に素晴らしいです。
では、もう一つ来ています。ええと、なぜ継続的かつ自動化されたデータパイプラインが AI アプリにとって重要なのでしょうか？素晴らしい質問です。ええと、Vincent からの質問も見えています。まず今あなたが出した質問に答えます、Tim、それから Vincent の質問に行きましょう。ええと、はい、継続的かつ自動化されていることは本当に重要で、これはデータの内容だけでなくメタデータについても考える必要があります。
つまり、ドキュメントのメタデータは時間とともに変化します。権限が追加されたり削除されたりすることがあります。これらの新しいバージョンを作成することもあります。そして、こうした検索プラットフォームを構築すると、それらはチームがすべてのデータにアクセスするための事実上のインターフェースの一つになっていきます。そうなると、世界の状態が変化するにつれて、これらの検索ストアを最新の状態に保つ必要があります。
古いデータは望ましくありません。GPT モデルのようなもので皆気づいていると思いますが、トレーニングのカットオフに基づいているため、過去、そうですね、2か月、3か月に何が起きたかを知りません。これは言語モデルと組み合わせた rag や検索のもう一つの良いユースケースです。しかし、ユーザーが AI アプリケーションから最新の回答を得られるように、コンテンツとコンテキストの両方を常に最新に保つためには、こうした継続的かつ自動化されたパイプラインが必要です。はい、とても良いですね。ええと、Vincent の質問もやってしまいましょう。
彼はそこに「Excellent」と書いていますね。ありがとう Vincent。とても良い質問です。ええと、では Lang chain について話してから、特に Lang graph について話します。ええと、先ほど示した図、つまり、ええと、AI スタックの中に da、ええと、data Volo が位置づけられている図に戻るとします。
少しだけそれを表示します。ええと、私は Lang chain をより広く、右側のアプリケーションフレームワークの設定に置きました。つまり Lang chain は、アプリケーションの UX、プロンプトエンジニアリング、適切なテンプレートを持つことに本当に優れていますが、私たちがここで全体的な問題の一部をある意味混同していると考えているのは、データのロードとデータエンジニアリングです。私たちは、それはより本格的なデータパイプラインソリューションの中に位置づけられるべきだと考えています。ですので、Lang change はそのアプリケーション側、フロントエンド側に集中し、データを適切なプラットフォームにロードし変換を行うためには、本物のデータパイプラインソリューションを使うべきだと考えています。
ええと、これは特にスケールした場合に重要です。なぜなら、これは単に一つのドキュメントに対して行うことではなく、すべてのドキュメントに対して行い、そして、ええと、それを継続的な方法で行うことだからです。さて、特に Lang RAF は非常に興味深いです。ええと、私の理解では、それは、ええと、エージェントや、ええと、さまざまなエージェントのオーケストレーション、そして Harrison がよく話しているような認知アーキテクチャの構築に関するものです。ですので、ええと、これは非常に、ええと、重要な領域だと思います。ええと、私たちは実際に、間もなくリリースされる copilot サービスのために、ええと、エージェントを使用しています。
そして、このコパイロットは、Tim がたぶん経験しているように、データエンジニアが適切なパイプラインを構築するのを支援することを意図しています。ええと、Jolt 変換は面倒なことがありますよね、connection string を取得したり、そうですよね、regular expression を取得したり、そうですよね。copilot にこの processor をどのように設定すべきか尋ねるだけで、それを代わりにやってくれたら素晴らしくないでしょうか？ええ、間違いなくそうですし、私たちはその素晴らしい alpha version の構築に懸命に取り組んできました。ですので、近いうちにご覧いただけるでしょう。ただ、Lang Graph については、そのフロントエンドに位置する、全体的な agentic architecture を構築するものとして考えるとよいと思います。
そして Data Volo は、データパイプライン側の問題を解決することにより重点を置いています。ユーザーがタスクやプロンプトをエージェントに送信する経路上にあるものではありません。さて、録画についての質問がありました。ええと、登録されている場合はメールで送られます。そうでない場合は、Zillow の YouTube に掲載される予定で、Data Volo もリンクを用意するはずです。
簡単に見つけられるようになりますし、スライドも必ず公開するようにします。ええと、別の質問が来ています。ええと、企業が AI を採用するうえでの主な障壁として、どのようなものを見ていますか？これは私たち全員が見てきたものですね。はい。これは私たちが毎日真剣に考えていることです。
ご存じのように、ええと、私たちは皆、chat GPT の瞬間に、このテクノロジーの可能性に非常に興奮しましたし、その可能性は完全に現実のものです。これは、cloud、big data、mobile と並んで、私のキャリアの中で見てきた最大級のパラダイムシフトの一つだと思います。ええと、しかし現在、企業は採用においていくつかの課題に直面しています。その大きなものの一つは、物事を正しい方法で行わないことに伴うリスクです。そこで私は、適切なガードレールを持つことについて話しました。ええと、それには role-based access や retrieval 時の secure enforcement が含まれます。
それには、適切な評価とテストを行うことも含まれます。そして一つの問題は、ええと、ユーザーの期待値を適切に設定する必要があるということです。ご存じのように、評価に本当に役立つことの一つは、たとえまだその動作の出来に恥ずかしさを感じている段階であっても、できるだけ早くアプリケーションを公開することです。その理由は、ユーザーが良い応答と悪い応答についてフィードバックをくれるというフライホイールが回り始めるからです。そうですよね？親指を上げる、親指を下げる。親指を下げる反応を見るたびに、それはアプリケーションと全体のスタックを改善するための宝です。ですので、皆さんには、そのユーザーフィードバックを自動化されスケールした形で収集し始めることをお勧めします。そうすることで、それを使ってアプリケーションを改善できます。
ええと、適切な期待値を設定し、適切なガードレールを持つことです。また、企業は必ずしも best of breed のソリューションでフルスタックを構築してきたわけではないとも思います。ですから、多くの人たちは、特定のクラウドサービスを使わずに物事を進めたいという制約を受けています。OpenAI や Anthropic を使いたくないのかもしれません。そのため、力不足のモデルを使っているのかもしれません。ええと、オープンソースモデルは非常にエキサイティングです。ええと、しかし LAMA 3。
1 は、400 billion に入り始めると、少し良くなるかもしれません。しかし LAMA 3。1 と Claude 3。5 や、ええと、GPT-4 oh のようなものを比べると、性能には本当に大きな、ええと、大きな差があります。数桁の差があると言ってよいと思います。ですから、適切なテクノロジーを選び、適切なスタックを構築する必要があります。
そして一部の人たちは、リスクであれ、信頼であれ、ガードレールであれ、いくつかの最良のモデルや最良のアーキテクチャを使うことに制約を受けてきました。ですので、ええと、それも採用上の課題として私が見てきたところです。さて、最後の質問に答える時間があります。下のほうに proven からの質問が見えます。ええと、これらにおける role-based accessed embedding をどう考えますか、これらの AI モデルにおける role-based accessed embedding をどう考えますか？言いたいことは分かると思います、proven。ええと、つまりこれは、異なる権限を持つ異なるユーザーについて話している secure enforcement に関するものだと思います。
ユーザーが質問をしに行って、ええと、取得されたコンテキストを得るときに、異なる結果を得るべきです。ですので、それをメタデータを使って行います。つまり、実際には埋め込み自体を変更するわけではなく、ええと、ベクトルを保存するときに、ええと、このドキュメントにどのグループやユーザーがアクセスできたかに関するメタデータも保存します。そして、アプリケーション内の、ええと、リトリーバーで安全な取得を実装する必要があります。ちなみにDAAは、これを行うために私たちが協力してきたパートナーです。
内部ではPuebloというオープンソースフレームワークです。ええと、ただし安全なリトリーバーは、アプリケーションへの認証イベントに基づいて、ユーザーのグループ、ええと、コンテキストを取得し、それらの、ええと、グループメンバーシップと権限を、私たちが保存したメタデータと照合します。そして、そのユーザーの適切な権限に一致する取得結果だけを返します。そしてその時点で初めて、それらの埋め込みに対してセマンティック検索を行います。つまり、ハイブリッド検索モデルです。
アプリケーションが、ユーザーの、ええと、認証コンテキストに関連付けられた適切な認可ルールを取得することを信頼し、それをメタデータと照合します。メタデータは、アプリケーション側全体を通じて本当に重要な要素として見えてくるでしょう。私はそれをかなり強調しようとしました。なぜなら、ハイブリッド検索、再ランキング、安全なアクセスの両方にとって本当に重要だからです。とても素晴らしいですね。時間切れのようで、そろそろ終了させられそうです。
では、ええと、そちらのチームの皆さん、ありがとうございます。Joeによろしくお伝えください。そして参加してくださった皆さん、ありがとうございました。スライドは入手できますし、ええと、この動画も入手できます。たぶん少しきれいにして、私たちを魔法のように見栄えよくするかもしれません。私はもっといいジャケットを着ることにします。ええと、改めてありがとうございます。またおそらく、ええと、来週お会いしましょう。
皆さん、本当にありがとうございました。Tim、どうもありがとうございました。お招きいただきありがとうございました。そして視聴者の皆さんにも感謝します。皆さんありがとう。さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Sam Lachterman
CTO, Datavalo
Sam Lachterman is a seasoned technology leader with over 18 years of experience at the forefront of the tech industry. Sam is an expert in data engineering, analytics, and AI/ML and prides himself on delivering impact for customers and partners. Currently serving as CTO at Datavolo, Sam shapes the company's product direction and leads the Field Engineering team. Previously, Sam led a team of Customer Engineers at Google Cloud, driving strategic partnerships on GCP with ISVs and previously held field positions at Databricks, Unravel Data, and Hortonworks. Sam's passion for innovation, forward-thinking approach, and industry insights make him an engaging presenter and thought leader in the evolving world of data engineering, analytics, and AI/ML.