- Events
RAGパーティションを超えて：ユーザー単位・チャンク単位のアクセスポリシー
ウェビナー
RAGパーティションを超えて：ユーザー単位・チャンク単位のアクセスポリシー
Join the Webinar
Loading...
何を学べるのか？
ベクトルデータベースのパーティショニングは、プライバシーとテナントごとの分離に有用なツールであることが実証されています。Milvus を含むベクトル DB ソフトウェアの最近のリリースでは、パーティション数を数百万規模に押し上げることや、テナントごとのパーティション選択を改善することなど、パーティショニング機能の向上が続いています。
こうした進歩にもかかわらず、パーティション数が増えるにつれて管理オーバーヘッドも増加します。企業が必要とし、既存のストレージシステムやデータベースに期待するようになった機能と比べると、まだ不足があります。ベクトルデータベースがデータを保存する方法や、RAG アプリケーションで使用される方法に特有の新しい機能が必要です。
扱うトピック:
- ストレージシステムにおける詳細なアクセス制御とポリシーに対する企業要件の起源。
- 機密データの識別: データ分類とアクセス制御の違い。
- ドキュメントからチャンクへ権限をコピーする際に、企業データセット内のデータ重複がもたらす問題。
- ユーザーごと、チャンクごとのアクセス制御によって企業のアクセス要件をどのように満たせるか
- ケーススタディと実装例。
本日は、今日のセッション「Beyond Rag Partitions」とゲストスピーカーのRob Cursをご紹介できることを嬉しく思います。Rob Cursは、ネットワーキングとセキュリティにおけるエンタープライズクラスのソリューションを30年以上にわたり構築し、率いてきた技術者であり起業家です。彼の最初の仕事は、IPO前のCiscoと競合するルーターを構築することでした。その後、量子エレクトロニクスのPhD取得に向けて取り組みながら、uc, Berkeleyで最初のハードウェアraidシステムの作成に貢献しました。それ以来、Ciscoで年間10億ドル規模の製品ラインの成長を率い、またWAN最適化のリーダーであるRiverbed、そしてSoja Systemsで現在では数百万ドル規模となっているsecureaccess secure edge市場の先駆けにも貢献しました。
そして、Akamaiでもです。彼の現在のミッションは、Cap A SystemsのCEO兼共同創業者として、生成AIネイティブアプリケーションの課題に対応する新しいソリューションを市場に投入することであり、そこでは初期チームメンバーであり役員でもありました。では、Rob、ようこそ。では、引き継ぎます。わかりました、Stefan、ご丁寧な紹介をどうもありがとうございます。そして皆さん、ようこそ。今日お話しできることをとても嬉しく思っています。
そして、Stefanが言ったように、私はかなり長い間Silicon Valleyで、テクノロジー製品やネットワーキング、セキュリティ、データの分野に携わってきました。そして今特に興味深いのは、生成aiによってデータの利用がどのように変化したかということです。ですので、すぐに本題に入り、生成AIアプリケーションという観点で世界がどのように進化していると私が見ているかについて、少しお話ししたいと思います。繰り返しになりますが、質問が出てきたら遠慮なくしてください。できる限りお答えするようにします。
私たちは皆、aiにおけるデータ利用のガバナンスに対する強い必要性を認識していると思います。ここではGLEを例として使います。gleanは、AIでエンタープライズに非常に素晴らしく浸透してきた企業の一つです。そしてそれは主に、明らかにAI機能によるものですが、同時にデータ利用に関する権限とガバナンスを提供できる能力によるものでもあります。これは、企業内では非常に重要です。なぜなら、企業が持つ膨大な量のデータ、コンプライアンス要件、プライバシー、セキュリティ、そしてパフォーマンスやコストといった他の要素があるからです。そのデータ利用をガバナンスできることは、もちろん非常に重要です。最も根本的には、なぜパーティショニングやユーザーごとのアクセス制御について話しているのかというと、ポリシーが何であれ、ユーザーは自分が見ることを許可されたデータだけを見るべきだからです。あるいは、もし彼らが、つまりある顧客やある会社のものであるなら、SaaSプロバイダーのような場合に、別の会社が他の誰かのデータを見ることは望ましくありません。ですので、この場合の認可は決定論的でなければならないことが分かっています。しかし、生成AIの世界で私たちが直面する課題の一つは、もちろんAIそのものが確率的であるということです。
それは非決定論的です。あるプロンプトから次のプロンプトへ、正確に何が得られるかを予測することはできません。それでも、企業が抱く期待、あるいは期待していると言うべきものは、まさにそれです。さて、パーティショニングには、異なる顧客や異なるユースケース間でデータを分離できるという多くの有用性があります。そして、SaaSアプリケーションにおけるこの種のマルチテナント分離を行うために使用する場合、非常に効果的です。なぜなら、データベースでベクトルを受け入れたり、移動したり、構築したりする前から、どのデータがどの顧客に属しているかを事前に知っているからです。
したがって、私たちは、各顧客のデータに応じて、ベクトルデータベースやRAGを決定論的に構築できます。ユーザー、ええと、ユーザーアクセス制御のためのパーティショニングを検討し始めると、あるいはユーザー権限を扱う場合には、少し複雑になります。なぜなら、どのチャンクを特定のユーザーに渡せるのかというレベルになるからです。そして、たとえ特定の企業や顧客のユーザーを対象にしている場合でも、あるいは生成AI向けで、企業内で構築されているアプリケーションの場合でも、ユーザー単位の権限とそれらがこれらのチャンクにどのように対応するかは、かなり曖昧です。これは非常に複雑なテーマになり、パーティショニングが最善の解決策ではない可能性があります。したがって、問題が生じるのは、権限の複雑さ、つまり権限が現れるさまざまな方法の数そのものにあります。
チャンク化されたデータでは問題が生じます。というのも、通常、企業ではオブジェクトやデータベーステーブルを扱うことに慣れているからです。ええと、そしてチャンクを扱う場合には、考慮しなければならない特有の事項がいくつかあります。もう1つはサービスアカウントです。ユーザーに代わってリクエストを行うエージェントがあります。では権限の複雑さから始めると、これは私が以前いた会社に関係しています。その会社は、SE領域、つまりセキュアアクセスサービスエッジの分野にあり、企業内のアプリケーションへのアクセスを仲介していました。
そこで私たちが直面したことの1つは、企業が自社のアプリケーションに関して求める認可の種類が非常に多岐にわたるということでした。ユーザーであるか、さまざまなポリシーであるか、時間帯に基づくポリシーであるか、アプリケーションの管理者であるか、開発者であるか、あるいは単なるユーザーであるかに基づくポリシーであるか。ここには非常に多くの可能性があります。そして、それらの膨大な権限を再現しようとすると、特に、今後普及しつつある認可スキーム、たとえばリレーションシップベースのアクセス制御、つまりReBACのように、動的な権限を持ち、それを最終的にはベクトルデータベース内の静的な権限に対応付ける必要があるものを見ると、多くの複雑さが生じます。では、メタデータに基づいてパーティショニングするためにメタデータキーを取得する際、適切なメタデータキーを持っているでしょうか？これらのアクセス制御ルールが必要とするものに基づいてパーティショニングできる適切なキーを持っているでしょうか？そして、それはアプリケーションを設計している初期段階で判断するのが非常に困難です。
もう1つの大きな問題はデータのチャンク化です。ソースデータ、つまりRAGに投入するデータの元となるドキュメントを見ると、それは非常によく整理されています。先ほど言ったように、ファイルやオブジェクト、データベーステーブルを扱っており、それぞれには比較的明確に定義された権限や、アクセスに使用できる特性があります。RAGの領域に入り、それらのさまざまなドキュメントからデータを取り出してチャンク化するとすぐに、以前とは大きく異なるものになります。そしてこれにより、チャンク上の権限をどのように扱うのか、またオブジェクトからそれらの権限をどのように対応付けるのかという点で複雑さが生じます。なぜなら、もはや単純な一対一の対応ではないからです。
というのも、チャンクは複数のドキュメントに現れることがあるからです。たとえば、同じドキュメントをコピーする場合、あるいは企業内で同じドキュメントを複数のSaaSアプリケーションにコピーする場合、またはユーザーがメールで受け取ったドキュメントから切り貼りして、それを別の形式で誰かに送信する場合を考えてみてください。そしてそれもRAGに取り込まれます。あるいは、ファイル共有などをしている場合もあります。結果として、チャンクレベルで非常に大量のデータ重複が発生することになります。
そして、私たちは、ええと、Riverbedやストレージ領域の他の企業でも同様のことが見られるのを確認しました。そこでは、データがワイヤ上を移動しているとき、または保存されているときに重複排除するだけで、保存されるデータ、あるいはネットワーク上で送信されるデータを、だいたい50〜90%削減できています。そして同じ効果はRAGにも適用できます。なぜなら、私たちは同じレベルのチャンク化を行っているからです。ですから、たとえば、あるドキュメントが別々のSaaSアプリケーションに移動され、それらのSaaSアプリケーションからデータを取り込んでRAGを構築しているとします。その場合、たとえば、そのうちの1つのアプリケーションではBobにそのドキュメントへのアクセスを許可していて、もう一方ではBobにそのドキュメントへのアクセスを許可していないとしたらどうなるでしょうか？そのチャンクが、ええと、その両方のドキュメントに存在している場合、チャンク単位で権限をどのように解決するのでしょうか？同様に、複数のドキュメントに現れるチャンクがある場合、これは後で取り上げるAppleの10-Q報告書の例でも見られますが、ええと、複数の異なる10-Q提出書類に共通するデータが多く見られます。そしてそれらの権限は、ええと、ドキュメントから直接継承すると曖昧になります。どの権限を、ええ、受け入れるのかを解決できなければなりません。つまり、Bobにこれらのチャンクへのアクセスを許可するのか、それとも、ええ、これら各チャンクへのアクセスを拒否するのか、ということです。しかし、チャンク単位の権限を、ええ、正しく設定できたとしても、もう1つ大きな問題に対処しなければなりません。それは、BobがRAGに直接アクセスするのではなく、エージェント、チャットボット、いわばフロントエンドサービスがBobの代わりにRAGへアクセスしており、そのエージェントはサービスアカウントを使用しているということです。ええと、では、ユーザー単位で、エージェントがRAG内のデータにアクセスすることを、ええ、どのように認可するのでしょうか？1つの方法としては、ええ、ユーザーのIDをなりすますことが考えられますが、そうすると、ええ、発生するさまざまなセキュリティ問題という点で厄介なことになります。
つまり、いったん、ええと、サービスやエージェントに、ええ、ユーザーになりすます能力を与えると、そのユーザーができることは何でもそのエージェントにとって可能になります。そして、ええ、悪意のある第三者や悪意のある内部者によって侵害された場合、そのなりすまし能力を使って、基本的にインフラストラクチャ内のどこにでも到達できてしまいます。そしてそれは本当に悪いことです。したがって、これら3つの問題は、ええ、私たちがRAGシステム内のセキュリティやデータアクセスのガバナンスに、ええ、どのように対処する必要があるかにとって、非常に重要になります。そしてそれこそが、ええ、私の会社caprが、ええ、取り組んでいることであり、AIデータのガバナンスを提供することです。ただし、RAG内で見られる、またはネットワーク上を移動するチャンクのレベルでです。
ええと、そして、これらの各チャンクを、それらの元となったさまざまなオブジェクトに結び付け、それらがどのように移動しているかを見ることで、ええ、これらの問題のいくつかを克服し、ガバナンスの面で大きな利点を提供できるようになります。ええと、製品については後ほど、どのようにデプロイされ、どのような見た目になるのかという点でもう少しお話しします。ええと、ただし基本的な考え方は、これらのチャンクを構成するバイトシーケンスのリネージを、それらがAPI内を移動しているとき、ストレージから、ええ、消費されているときに追跡するというものです。そして、このデータがアプリケーション内でどのように移動するかのグラフを本質的に構築できます。そしてそれを行うことで、グラフ内の各ポイントで見られるメタデータをデータに関連付けることができ、そのうえでそのグラフを決定論的にもAIを用いても分析し、各チャンクにどの権限セットを付与すべきかを判断し、また、ええ、実際にそれらを受け取ることになるユーザーが、ええ、誰なのかを帰属させることもできます。
それでは例として、Appleの10-Q報告書を見てみましょう。ええと、そして、私が話してきた問題のいくつかをお見せします。では、Appleの2023年の10-Q報告書は公開されていて、誰でもアクセスできるものだと想像してみてください。そして、2024年の報告書は仮に非公開、つまり重要な非公開情報だとします。もしあなたが上場企業にいるなら、おそらく、インサイダー取引に関するSECの規則をすべてご存じでしょう。彼らはこれを非常に深刻に受け止めています。
そして企業は、非公開情報に対して厳格なアクセス制御を提供しなければなりません。また、その非公開情報にアクセスできる人は誰でも、SECに登録され、そのすべてのアクセスについて監査証跡が提供されなければなりません。それはすべてインサイダー取引を防ぐためです。しかし、これらの中のデータを見ると、特にRAGシステムに取り込んだ場合、それぞれに共通して存在する定型文や共通の言い回しが非常に多いことがわかります。ええと、そして、これら2つの異なる文書セットに存在するデータの違いは予測不能です。
AIに、これらの各文書を読み込ませて、どのデータが公開でどれが非公開かを分類させるのは非常に困難です。AIにはその情報がないからです。ええと、これら2つの文書は、分類しようとすれば、まったく同じように分類されます。どちらも10-Q報告書であり、実際まさにそのとおりです。しかしチャンクレベルでは、ユーザーが何にアクセスできるべきで、何にアクセスすべきでないかをどう判断するのでしょうか？そこでCRでできることは、これらすべてのチャンクのリネージを、それらが由来する文書までマッピングすることです。
すると、次のようなグラフが得られます。下部にある大きな青い点のそれぞれは、オブジェクト、つまり10-Q報告書であり、このすべてのデータを含むPDFそのものです。ええと、そして上部の赤い点は、それらすべての文書に共通して存在するチャンクの集合です。共通するチャンクが非常に多いだけでなく、それらはある意味で興味深い形で分布しており、これらの文書間で見られる共通チャンクはさまざまであることがわかります。ええと、したがって、これらの文書間で共通して見えるチャンクがどれになるかさえ予測できません。ええと、しかし、前に述べたように、これらそれぞれのリネージを動的にマッピングできることで、これらの各文書に属する認可、あるいはメタデータを継承すると言ってもよいものを、それぞれのチャンクに帰属させることができます。これは、たとえば優先順位によってこれらの権限を解決することで行えます。つまり、誰がそのデータを最初に書いたのか、どれが先に来たのか、本質的には優先順位、あるいは出現頻度です。
たとえば、あるチャンクが公開チャンク、あるいは公開文書内のチャンクとして100回出現するなら、おそらくそれは公開アクセス可能なチャンクだと仮定すべきかもしれません。そして、それが非公開の1つの文書にしか出現しないのであれば、ここでは出現頻度に基づいて判断できます。あるいはポリシーによって、「最小権限ポリシーが勝つ」とし、出現頻度や優先順位に関係なく、常に最も厳格なアクセス制御を選ぶ、と言いたいかもしれません。ええと、そしてもう1つできることは、文書上に存在するさまざまな種類のポリシーを横断して見ることです。たとえば、S3バケットの権限オブジェクトを取得する場合、あるいはSalesforce内の文書に対する権限ポリシーを取得する場合、これらはまったく異なるものになります。
そして、ここでAIが非常に役立ちます。なぜなら、こうした、ばらばらのポリシー群を見て、それらを突き合わせ、正規化することで、その後、ええと、こうした異なる、あー、先例に基づく問題やポリシーベースの決定論的な、あー、ええと、解決を適用できるからです。さて、エージェントの、あー、APIコールをユーザーに結び付け直すというもう一つの問題は、これらのAPIコール、つまりリクエストやAPIレスポンスの中で見えるデータをトレースするだけで実現できます。非常に簡単な例として、Bobがプロンプトを入力すると、そのプロンプトのデータがエージェントに渡り、次にエージェントはそれを使ってragやベクトルデータベースでルックアップを行います。したがって、同じデータを持っているため、2つの異なるAPIコールを結び付けることができる、と言えます。そしてその後、ragから返ってくるデータがBobのリクエストに使用されることを判断できます。
そして、それを見て、ユーザーがエージェントではなくBobであるという事実に基づいて、ええと、それらのチャンクの一部を許可するか、またはリダクトするかを判断できます。では、このすべてが、ええと、システム内でどのように機能するのかの、ええと、例をお見せします。デモに、あー、画面を切り替えるので少しお待ちください。同じエンドポイントにアクセスしているので、プライベートブラウジングを使う必要があります。おっと。
はい。では上部に、ユーザーAmyがログインしているのが見えます。そしてこれは繰り返しになりますが、これらのApple 10 Qステートメントで構築されたragです。前にも述べたように、2024年のものは重要な非公開情報で、2023年のものは誰でもアクセス可能です。さて、ユーザーAmyは、たとえばAppleのCFOだとしましょう。ですから当然、彼女はこのすべてのデータにアクセスでき、2023年から2024年にかけて物事がどのように変化したのかについて質問したいと考えています。
そこで彼女は、Appleの売上総利益率は2023年、2024年でどのように推移しましたか、と尋ね、それを、あー、チャットエージェントに送信します。そしてこれは実際には、あー、visが構築したragデモをベースにしています。ここではLLMにOpenAIを使用しているため、ええと、OpenAIへのアクセスに関して少しレイテンシがあります。しかしご覧のように、返ってくるのは、すべてのデータに基づいた回答で、Appleの売上総利益率は2023年、2024年で注目すべき推移を示しており、ええと、彼女の質問に対する完全な回答になっています。左側で、実際にragからどのデータが取り出されたかを見ると、彼女がこれらの異なる文書全体にわたってかなり完全な情報セットを得ていることがわかります。ここには2024年のデータと2023年のデータの両方が見えます。では、ユーザーBobを見てみましょう。
彼は本質的に同じ質問をします。教えてください、Appleの売上総利益率は2023会計年度から2024年にかけてどのように推移しましたか？さて、Bobは2024年のステートメントにアクセスできないので、この質問をすると、何が起こるか見てみましょう。繰り返しますが、私たちはこの質問を使って、OpenAIに送信される前にragからデータを引き出しており、そのデータを検査して、チャンクレベルでリダクトし、ええと、Bobがそれにアクセスすべきかどうかを判断できるのです。すると、Bobの回答は、あー、彼が任意の回答を得る際に期待するのと同じくらい流暢であることがわかりますが、「提供されたコンテキストには、2023会計年度から2024年までの具体的な売上総利益率データは含まれていません。しかし、」と述べ、その後そこから推論が進みます。そしてこの場合、ragから取得された行を見ると、まあ、2024年のステートメントから来ているかなり多くの情報をリダクトしています。
ええと、ただし、2023年と2024年の両方に存在する共通のチャンクと、2023年の明細書に存在するすべてのチャンクの両方を許可します。そうすることで、この非常に細かなレベルで、権限を決定論的に適用し、ユーザーBobがアクセスすべきデータのみにアクセスできるようにできます。これは、もちろん、多くの企業が現在直面している重要な問題の1つですが、ガバナンスの観点から生成AIにおいて検討できる問題はこれだけではありません。もう1つの問題はデータの清潔性です。そしてこれは、LLMをどのように構築するか、データをどのようにトレーニングするか、データでLLMをどのようにトレーニングするかという点で重要であることがわかっています。
ええと、重複のないクリーンなデータがなければ、LLMの挙動においてかなり偏った結果に至る可能性があります。さて、重複データを含むチャンクでRAGを構築し、それらのチャンク内にかなりの量の重複データがある場合、それもまた重大な問題になります。なぜなら、誰かが質問するたびに、ベクターデータベースから100個の情報チャンクを取得するだけかもしれず、それらのチャンク内には、似たような情報が含まれていて、その結果、そこに存在する重複や反復のために、得られる結果は大きく偏ることになるからです。したがって、データがどのように移動するかを確認し、どこから来たのかを確認し、データのリネージュを理解できることが重要になり始めます。それは、アクセス制御のためや、Bobがアクセスすべきでないデータにアクセスできないようにするためだけではなく、チャンクレベルでデータがどのようにベクターデータベースへ移動されているかを理解するためでもあります。そして、これらのチャンクのリネージュを再び追跡することで、それを行うことができます。特定のアプリケーション内でデータがどのように移動するかを見ることができます。この例では、ユーザーAmyがドキュメントをアップロードした時点から、たとえばフロントエンドまたはチャットアプリケーションを通じて、それがS3バケットに保存される場所まで、さらにそのデータが他のサービスや他のS3バケットを通じてどのように移動されるかを確認し、アプリケーション内のデータ移動に関して何が起きているかの完全なビューを提供できます。
これにより、データの重複がどこに存在するかを理解できます。単に、完全に同一のドキュメントや、ある場所から別の場所へコピーされたドキュメントを見るだけではなく、たとえばテキストの1段落がこのドキュメントからコピーされ、まったく別のドキュメントに貼り付けられたという粒度まで把握できます。そしてそれを示し、サブチャンクレベルでデータの重複に関する可視性を提供できます。AIアプリケーション内のすべてのフローにわたってこれを実行できることにより、非常に細かなレベルでこれらのアプリケーション内でデータがどのように移動しているかを観察し、チャットエージェントがどのように機能しているかを分析およびデバッグする強力な能力が得られます。そしてこれは、ユーザーに代わって複数のアクションを実行する自律性をエージェントに与えるエージェント型AIについて話し始めると、特に重要です。ユーザーがプロンプトを入力してから応答を受け取るまでの間、その途中のすべてのステップで何が起きているのかが、常に明確であるとは限らないからです。
その応答を出すために、エージェントが取ったすべてのステップは何ですか？実行された可能性のあるSQLクエリ、ストレージシステムへのアクセス、場合によってはインターネットサイトへのアクセスも含めて。ええ、ここでは、正確に何が起きたのかの完全な証跡を得ることができます。分析の可観測性と、最終的にはそのデータのガバナンスの両方のためです。ええ、これこそが最終的にCRが目指していることであり、そのデータ、そのデータがこれらのエージェント型AIアプリケーションを通じて流れる流れを検査する能力を提供し、私たちのプライバシー目標を満たしているのか、ポリシーに照らしてコンプライアンス目標を満たしているのかを判断できるようにすることです。そして、そのデータを会話形式で検査できるようにし、アプリケーション内の問題を検出して解決できるようにすることです。ですから、まさにそこに、この力があると私たちは見ています。そして次のステップは、これを市場に投入することです。
私たちは非常に初期段階の会社です。これを試してみたい方を探しています。ご興味があれば、ぜひ私に連絡してください。もっとお話しできればと思います。それでは、質問を受け付けて、Stefanに戻します。はい、Ron、本当にありがとうございました。
本当に素晴らしいプレゼンテーションでした。これはAIインフラの道のりにおいて発展させるべき、とても重要な側面だと思います。私自身は、データエンジニアというわけではあまりないのですが、Metaで応用研究者として働いていたとき、アクセス制御や、自分のデータがどこから来たのかを追跡するような関連事項の重要性を目の当たりにしました。そうしたものなしでは、そのビジネスを運営することはできません。ですので、非常に重要だと思います。
では質問の時間があります。実際、かなり時間があります。聴衆に開きましょう。ええと、Questの質問があります。ああ、これはZillowへの質問ですね。ええと、world zealot。
com/resources は、partitioning melvic vector databasesに関する詳細情報を得るために行く場所でしょうか。ええと、そうですね、私たちが必要なのは、はい、つまり、おそらくそうだと思います。CERとmelvicの統合を示すようなコンテンツをもう少し作成する必要があります。ですので、それは近い将来に出てくる予定です。Rob、その点について何か考えはありますか？はい、実は、このデモのコードを公開すべきですね。現時点ではPython SDKを介して既存のチャットアプリケーションに統合できますし、プロキシ経由でも統合できます。つまり、エージェントに出入りするAPIトラフィックを検査しているだけです。
将来的には、他の統合や他の言語サポートも提供する予定です。わかりました。では、他にどなたか？質問はありますか？また、もし実際に質問を声に出して話したい場合は、参加者リストで発言を許可できます。ああ、Flory、ええと、あ、すみません。私は、あ、はい、よかったです。
Robからの本当に重要なトピックについて話します。ええ、では、私自身からRobへの質問かもしれません。もちろんです。では、このようなインフラパイプラインの一部としての採用のタイムラインをどのように見ていますか？たとえば3年以内に、これはワークフローの標準的な一部になると思いますか？これまでの traction はどのような感じですか？そうですね、現時点での大きな推進要因はAgTech aiであり、企業内でのAgTech AIに関する採用予測を見ることができると思います。そして、それが私たちも進路として描いているものです。
ええと、そこに複雑さが生じるんですよね？今日、私たちには解決できる基本的な、ええと、基本的な問題がいくつかあります。そして私は多くのお客様と話してきましたが、つまり、彼らは懸念していますし、権限については確かに懸念していますが、それが必ずしも優先事項というわけではありません。ええと、しかしエージェントAIに進み、リクエストの種類や、これらのエージェントの応答に取り込まれているデータの種類に対する可視性を失うようになると、ええと、プライバシーとコンプライアンスの観点だけから見ても、そのデータがどのように使われているのか、そしてそれが責任ある方法で使われているのか、ええと、そしてそのデータの知識から恩恵を受けることになるユーザーのために使われているのかを理解できることが、信じられないほど重要になります。ええと、そしてそれこそが、つまり、私たちが賭けているところです。そして、ええと、時間軸に関しては、私が、ええと、物事がどれだけ速く進むかを予測しようとするたびに、Jenny、私は間違っています。
はい、私も、私たち全員そうだと思います。はい。ええと、いくつか良いポイントがありました。ではArthurから質問があります。ええと、データのコレクションを作成する代わりに、データをパーティション分割する利点は何ですか？ええと、これが私が答えるべき質問かどうかはわかりません。
ええと、つまり、ある意味では、私は、ええと、パーティションを作成する能力とコレクションを作成する能力を、同じコインの両面として見ています。Mm-Hmm。ええと、わかりませんが、Stepan、これについて何か考えはありますか？ええと、はい、いや、私は、ものすごく洞察に富んだことを何か言えるかはわかりませんが、つまり、おそらく、非常に密接に関連した2つの抽象化のようなものだと思います。ええと、もしかするとコレクションというのは、ええと、その抽象化が、このアクセス制御の意図された目的に、ええと、静かにというか、完全には一致しないということなのかもしれません。ええと、そしてパーティション分割には、データ間に、ええと、物理的な、ええと、分離も何らかの形で含意し得るような側面もあるのでしょうか？はい。
つまり、そのパーティション分割がどうあるべきか、あるいは特定のコレクションの境界がどうあるべきかを判断できる範囲では、ええと、そうですね。顧客Aのデータであるとか、それが財務データであるとか、HRデータに対する財務データであることが明らかであれば、はい。ええと、その場合は、ガバナンスルールを定義するために、ええと、そうした境界を使うという点で比較的効果的でいられます。ええと、それらの間に重なりが生じ始め、その線引きが曖昧になり始める範囲で、ええと、そこで問題に直面し始めます。
そうですね。ええと、例えば、HRにアップロードされた履歴書が、SharePointにも存在するかもしれません。Mm-Hmm。ええと、ではそれはHRデータなのか、それとも単に、つまり、誰かがメール内で、ええと、例えばエンジニアリングマネージャーに送ったデータにすぎないのか？ええと、そこが注意し始めなければならないところです。そうですね。
わかりました。わかりました。ええと、では、ええと、フォローアップの質問があるようです、ええと、まあ、実際には、ええと、考えているのですが、Arthurからのこの質問は、ええと、最初の質問に関連しているのでしょうか、それともRowanの質問に関連しているのでしょうか？ええと、見てみましょう。では、何を、ええと、彼らにとっての境界は何ですか？境界は何ですか？ああ、わかりました。ただ、ただ、ただのコメントです。
ああ、わかりました。ではRowanの質問を取り上げましょう。はい。完璧です。
では、ええと、では、ええと、このチャンクレベルのアクセス制御は、追加のアプリケーションレイテンシを導入する可能性があります。では、私たちは、ええと、この追加レイヤーを、ええと、推論スタックに追加することによるパフォーマンスレベルについて、定量的な理解のようなものを持っていますか？はい、つまり、私がたった今行ったデモのようなものを見ると、レイテンシの大部分はLLMへのリクエストにあります。ええと、基本的に私たちが、ええと、施行の面で行うことは、データベースへのルックアップです。ええと、したがって私たちが追加するレイテンシは、本質的にはvisへのルックアップから得られるものと同じです。はい。そして、つまり、プロンプトから応答までのトランザクション全体のごく小さな部分です。
はい。それは、それは聞けてよかったです。それに、私も思うのですが、多くの状況では、たとえば法的にこれをやらなければならない場合もあるかもしれません、ええ、あの、いずれにせよ。なので、ええ、聞けてよかったです。それは全体の、ええ、あの、laso のごく小さな一部にすぎません。Vincent から質問が来ています。
データとチャンクに対する権限は時間とともに変化します。cable はアクセス制御の動的な変更をどのようにサポートしており、他のアクセス制御、あの、システムとはどのくらいの頻度で同期しますか？ええ、つまり、それは、それは素晴らしい質問です。ええ、私たちは、ええ、見ているデータに関しては、ソースオブジェクトを見ています。これは顧客が、たとえばどこを更新の対象として見るべきかを設定するものです。ええ、たとえば、Salesforce 内や S3 バケット内で権限またはオブジェクトが更新されるたびに、私たちは、その、ログデータ、イベントデータを取り込んで、ああ、変更があった、再スキャンしに行くべきだ、と判断できるようにします。ですから本当に、ええ、それを行うのは実質的にオンデマンドです。そしてもちろん、それに時間枠を設定したい場合は、それも可能です。
つまり、ログは取り込むけれど、実際には何もしない、たとえば一日の終わりまで、ということです。そうすれば、環境内の他のアプリケーションの、あの、パフォーマンスに影響を与えません。わかりました。それで、ええ、あの、たとえば、cable は他の、あの、アクセス制御システムと統合するようなことはありますか？はい。そして実際、それは重要な部分です、そうですよね？ユーザー ID の観点から IDP と統合して、彼らの、あの、権限、つまり所属しているグループ、あの、どのような権限を持っているかを取り込めるようにする必要があります。
ええ、そして、さまざまなデータソースすべてと、ええ、統合できる必要があります。うん。では、実際にデータ自体を読み取り、あの、アクセスを得るという観点では、それは比較的単純です。そこには、かなり多くの、ええ、インジェストプロジェクト、ええ、私たちが活用できるものがあります。ええ、私たちが実際に、ええ、作業を行い、そして、あの、継続的に統合を拡大しなければならない場所は、権限そのものに関する部分です。
ええ、これは製品利用のもう一つの、ええ、推進要因だと言えると思います。というのも、あらゆる場所からデータを取得できるこれらのインジェストパイプラインを使用しているとき、それらのパイプラインは権限を取得するために開発されたものではない、という点を認識しておく必要があるからです。それらはデータを取り込むために開発されたものです。ですから、そのメタデータを取得しに行くことができるようにすることは、私たちが現在サポートしている統合の数を増やすために取り組んでいることです。わかりました。素晴らしいです。
では、ええ、Vincent から追加の質問です。チャンク単位とファイル単位の粒度でアクセス制御を使用することの長所と短所は何ですか。特にアクセス制御が頻繁に変更される場合についてです。ええ、つまり、権限変更の処理に関しては、それはリアルタイムでは起こりません。ええ、遅延があります。ええ、ですので、ファイルの権限が変更され、誰かが s を、あの、アクセス制限に設定した場合、ええ、私たちはそれをすぐには検知しません。ですから、それらは、つまり、もちろんストレージシステム内では即座に有効になります。
ええと、ただ、それはつまり、ファイルに対する純粋なアクセス制御だけを見ているなら、それがCRの観点から使いたい主要なメカニズムになる、ということです。チャンク単位のアクセス制御によって、単一のチャンクが存在し得る複数のファイル、ええと、複数のオブジェクトにまたがって存在する可能性のある権限を集約し、分析し、解決したうえで、そのチャンクにアクセスできるべきかどうかを判断できるようになります。ごく、ごく一般的な例として使えるのは、ええと、PDF上の会社ロゴです。その画像自体はあらゆる場所に存在することになります。現時点では、ファイル権限によって、そのロゴが含まれている可能性のあるドキュメントへのアクセスは制限されますが、そのロゴ自体には、誰でもアクセスできるわけですよね？おそらくPRの観点から、人々がダウンロードできるようにインターネット上に掲載しているでしょう。ですので、ええと、それこそがチャンク単位で行うことの利点です。つまり、誰かがアクセスすべきでない、またはアクセスすべきファイル固有のデータと、非常に多くの場所に存在していて、ええと、まったく権限を設定する必要がないかもしれないデータとを分離できるのです。
なるほど。では、ええと、そうですね、私の考えもかなり似た方向です。つまり、チャンクは情報の基本単位のようなもので、たとえばVICデータベースから取得して、ragのためにLMに入れるものですよね。ですので、ええと、ああ、それは自然なことのように思えます。アクセス制御をファイルではなく、チャンクに対して設定するということです。ええと、そうですね、より長いコンテキストでは、ええと、埋め込みモデルにおいて、チャンクは、たとえば、あなたのドキュメントと同じ長さになるかもしれませんし、ドキュメントとチャンクが同じものになるかもしれません。なぜなら、ええと、100万くらいの、ええと、ええと、トークン文字ウィンドウがあるからです。
ええと、少し、少し、ええと、ここで少し哲学的になってみます。データのアイデンティティについて考えたいのであれば、ユーザーのアイデンティティについては非常によく定義された視点があります。つまり、ユーザー名とパスワードから、生体認証、MFAに至るまで、人物を確実に識別するために使える要素が100種類もあります。そうですね。データに関しては、それは非常に少ないですよね？ファイル名や、ファイル上に存在するlesがあります。ええと、しかし、それらのファイル自体を構成する1と0、バイトを見たとき、そのアイデンティティとは何でしょうか？そして、チャンクレベルで行うことの利点が何かを考えるなら、それはそれらのデータチャンクを一意に識別できることなのです。
このチャンクは何で、誰がアクセスできるべきなのか、そして、ええと、その許容される利用は何であるべきなのか。うーん、そしてそれは新しい概念です。つまり、人々はこれまでデータをこのようには考えてきませんでしたし、ほら、今や、ええと、生成AIがそのようにデータを消費しているので、ええと、私たちはそろそろ、まあ、それによってデータをその観点で考えざるを得なくなっているのだと思いますよね？ええ、まったくです。うーん、うーん、では、明確にすると、つまり、私は、うーん、あなたが言っているのは、ええと、たぶん、ある意味でそのチャンクの埋め込みのようなものが、うーん、そのデータが何であり、したがって誰がそれを所有しているのかという点で、最良のシグナルの一つのようなものだ、ということですか？それとも文字どおり、その、その、そのチャンクのゼロと1について話しているのですか？まあ、それは、うーん、一意性に行き着きますよね？たとえば、ええと、DNAについて考えると、うーん、人間のDNAの、ええと、70%はバナナと共有されています。だから、もしDNAを見るなら、そのDNAのどの部分が実際に私たちのアイデンティティで、どの部分が、ほら、バナナやオランウータンや他の何かのものなのか、というと、それは非常に小さな部分ですよね？ですから、もし私たちがファイルを、その本質、つまりデータのチャンクとは何か、そのファイルを一意に識別するバイト列は何か、あるいはそのファイルの特性を一意に、ほら、形成するものは何か、というところまで煮詰めたいなら、チャンクレベルで見る必要があります。なぜなら、データ重複排除で見られる割合のようなものは、DNAと非常によく似ているからです。
うーん。ええ。ええ。いや、うーん、それは本当に良い指摘です。Rowanから質問があります。
では、CAPAのチャンク化戦略の変更はどのくらい動的なのですか？その場合、チャンクレベルのACLも変わるのでしょうか？ええと、ほら、チャンクは同じではなくなるでしょうし、もしかすると、ええと、そういうものにはならない、つまり、それらはある意味で、うーん、特にいくつかの点で重なり合うかもしれません。そして、異なる、うーん、ええと、ACLを持つ2つのチャンクがある場合、ええと、その場合はどうなるのですか？ええ、では、うーん、Cabrが行うチャンク化と分析、つまり私たちがインデックスを構築するために行うことは、ええと、ベクターデータベースの構築で起こることと似ています。つまり、私たちはデータを取り込むのを、うーん、埋め込みやトークン化を行ってベクターデータベースを構築するのにかかる時間よりも速くできます。ですから、うーん、ある意味では、もしチャンク化戦略を変更して、ベクターデータベースを再構築するのであれば、ほら、それに合わせてRインデックスも再構築することになります。うーん、チャンク化戦略が何であるかを私たちが知ることは非常に有益です。私たちは、ええと、うんうん、あなたがベクターデータベースで使用しているチャンク化戦略と整合できるようにしたいのです。
うーん、しかし同時に、うーん、私たちはベクターデータベースにあるものよりも、ええと、より細かい粒度にしたいのです。なぜならそうすれば、全体としては同じではない異なるチャンクの中にある、うーん、共通性を見つけることができるからです。そうですよね？つまり、1000バイトの2つの異なるチャンクは完全に異なるかもしれませんが、その中に、ほら、ええと、誰かがアクセス権を持っていない文書に一意に由来する256バイトのシーケンスが含まれているかもしれません。そして、私たちはそれをそのレベルで識別できるようにしたいのです。うーん、それによって、うーん、以前に取り上げた問題、つまり、ほら、あなたのRAGの中に、サブチャンクレベルでさえ重複しているデータがどれだけあるのか、という点で役立てるためです。はい。ええ、まったくです。つまり、つまり、その、その、その、コストは非常に低いということですね、この、うーん、ええと、ACLインデックスを構築する、構築するための。だから、ほら、全部もう一度やればいいと。
うーん、まあ、つまり、誰かを誤解させたくはありません。コストは、コンピュートの面では存在します。これはコンピュート集約的なタスクです。うーん、ただ、私たちはその時間枠の中で、つまり、ここでは相対的な時間枠の話をしているのですが、ベクターデータベースを構築し、私たちのインデックスを構築する時間枠の中で、ほら、インデックスを構築できます。うーん、あなたがベクターデータベースを構築しているであろう時間の中で、容易に構築できます。わかりました。わかりました。
ええと、では、あー、他に質問はありますか？さて、締めくくる前に、あ、Vincent からもう1つ質問が来ています。ええと、チャンクへのアクセス制御情報はどこに保持されているのでしょうか。C の中ですか、それとも、ええと、チャンクのメタデータの中ですか？つまり、これらは本当に素晴らしい質問です。ですので、その、ええと、私たちが保持しているメタデータは、ええと、もしそれが本当に重要であれば Elasticsearch の中にあります。ええと、私たちは、その、すべての、ええと、すべてのチャンクについて、イベント単位でチャンクに関連付けられたメタデータを追跡しています。ですので、ええと、つまり、私たちは実際には環境内でかなりの量のデータを収集しています。ええと、API 経由でチャンクがアクセスされるのを見るたびに、私たちは、その API リクエストのメタデータを保持し、そのイベントについてチャンクに関連付けます。
それから、ええと、それからリアルタイムで分析を行うことができます。そしてそれにより、これらをどのように適用するかという点で非常に柔軟性が保たれます。今、執行を行う場合には、ええと、少し違った扱いをしたいと考えています。権限を解決したいのです、うんうん、そして、それから、それらの権限とチャンクとの関連付けを、ええと、非常に高速なデータベースに入れたいのです。それによって、それらをリアルタイムで取得できます。ええと、ただしそれは、ええと、他の、ええと、ええと、私たちが行う他の分析と並行して実行されます。
わかりました。ええと、はい、とても効率的な、ええと、実装のように聞こえます。では、ええと、終わる前に、Rob、あなたにお聞きしたかったのですが、つまり、その、ええと、聴いている皆さんは、CA について聞かれました。ええと、おそらくそれを自分たちの製品に統合したいと思っているかもしれません。あなた方に連絡するには、ええと、ええと、最良の方法は何でしょうか？rob@caper. com に直接メールを送ればよいのでしょうか？ええと、ウェブサイトに行くべきでしょうか、え、HH、皆さんは、ええと、どのように連絡を取るのが一番よいでしょうか？ええと、皆さんは私に直接連絡していただいて構いません、Rob、at caper.
com です。ええと、現時点では、誰かを断らなければならないほど大量のメールは受け取っていませんが、ただ、ええと、この、この動画が、ええと、ウェブ上に掲載されている期間によっては、それは変わるかもしれません。その場合は、ええと、info@caper. com 宛に送ってください、と言うでしょう。わかりました。
素晴らしいです。では、Rob、改めてありがとうございます。本当に、本当に興味深いお話でした。これは本当にクールな技術だと思います。ええと、そうですね、そしてこれは、ええと、重要性や、ええと、どれほど広く普及するかという点で、ある種ますます増していくものだと思います。
ですので、ええと、それについて聞けて本当に良かったです。ええと、ウェビナーにご参加いただき改めてありがとうございます。そして、ええと、今後、あなたから、ええと、お話を伺えるのを楽しみにしています。ええ、こちらこそ本当にありがとうございます。そして、ええと、私を招いてこれを行う機会をくださったことに感謝します。また、ウェビナーに参加してくださった皆さんに、素晴らしい質問をしていただいたことについてお礼を言いたいです。そして、ええと、今後つながることができればと思います。ありがとうございます。ご参加いただいた皆さん、ありがとうございました。
はい。はい、それではお元気で。さようなら。
Meet the Speaker
Join the session for live Q&A with the speaker
Rob Quiros
CEO & Co-Founder, Caber Systems, Inc.
Rob Quiros is a technologist and entrepreneur with more than 30 years building and leading enterprise-class solutions in networking and security. His first job was to build a router to compete with pre-IPO Cisco. Later, he contributed to the creation of the first hardware RAID controller at UC Berkeley while working toward a PhD in Quantum Electronics. He has led the growth of $1B/yr product lines at Cisco, and WAN optimization leader Riverbed, and helped pioneer in the now multi-billion dollar Secure Access Secure Edge (SASE) market at Soha Systems and Akamai. His current mission is to bring new solutions to market to meet the challenges of GenAI-native applications as CEO & co-founder of Caber Systems, Inc. Secure Edge (SASE) market, where he was an early team member and executive.