ドキュメント前処理用の新しいSQL関数により、SnowflakeでのエンドツーエンドのRAG開発を加速

会話型アプリケーションを通じて文書内の知識にアクセスできるようにすることで、意思決定を強化し、運用効率を高めようとする組織が増えているため、RAGベースのアプリケーションフレームワークが、急速に最も効率的でスケーラブルなアプローチになっています。RAGベースのアプリケーション開発は拡大し続けており、これらのアプリケーションを動かす文書を処理および管理するためのソリューションは、スケーラビリティと効率性を念頭に置いて進化する必要があります。これまで、RAGのドキュメント準備（抽出やチャンクなど）は、Pythonライブラリを使用して関数を開発、展開する必要があり、管理や拡張が困難になる可能性がありました。  

生成AIアプリの開発を促進するために、PDFなどのドキュメントをAI対応にするためのSQL関数を提供しています。この度、 Cortex Searchの一般提供開始が発表され、新たに以下の2つのドキュメント前処理機能が追加されました。 

• PARSE_DOCUMENTによるレイアウト対応文書テキスト抽出（パブリックプレビュー） 

と

• テキストチャンキング用のSPLIT_TEXT_RECURSIVE_CHARACTER（プライベートプレビュー） 

これらの機能により、PDFなどのドキュメントの準備が合理化され、AI対応になります。AI対応データは、RAGアプリケーションを通じて価値を提供するカギです。ドキュメントがAI対応になると、RAGエンジンに取り込むことができます。これにより、AIアプリケーションの全体的な品質が向上します。

大規模言語モデル（LLM）を使用して自社の製品ポートフォリオに関する質問に答える会話アプリをセールスチームに提供するとしましょう。事前トレーニング済みのLLMだけでは、自社の製品に関する深い専門知識がないため、生成される回答は正しくなく、価値がない可能性があります。正確な回答を提供するために、開発者はRAGベースのアーキテクチャを使用できます。このアーキテクチャでは、LLMがドキュメント、Wiki、FAQから関連する内部知識を取得してから回答を生成します。ただし、これらのドキュメントをRAG品質を高めるためには、コンテンツを抽出して、段落やドキュメントセクションなどの小さなコンテンツブロック（チャンク）に分割し、意味検索用のベクトルとして埋め込む必要があります。前処理が完了すると、RAGエンジンを開始できます。 

言い換えると、RAGは検索機能と同等であり、検索はインデックスされたデータチャンクと同等であり、高品質のテキスト抽出はこれらすべての基礎となります。

最も関連性の高い結果を提供する

Cortex Searchは、埋め込み生成とベクトル管理を統合したフルマネージド型のサービスであり、エンタープライズグレードのRAGシステムに不可欠なコンポーネントです。正確なキーワードマッチングとセマンティックな理解を組み合わせたハイブリッド検索ソリューションとして、検索精度を高め、クエリのフレーズが異なる場合でも関連情報を取得します。 

このハイブリッドアプローチにより、RAGシステムはクエリが特定の用語に絞られている場合でも、より抽象的なコンセプトを探ろうとしている場合でも、より正確で文脈に即した回答を提供できます。たとえば、「headphones SKU：ABC123」は、「ABC123」に完全に一致する結果を優先し、ヘッドホン、エレクトロニクス、音楽などの関連結果を返します。つまり、各クエリは意味的に似た結果だけでなく、製品SKUや会社IDなどの特定の用語に完全一致します。 

この機能は、特にレイアウトアウェアなテキスト抽出とチャンキングを使用して文書が作成され、コンテンツが検索に最適な構造になっている場合に有用です。短いSQL関数によってドキュメントの前処理を簡略化することで、データエンジニアは複雑で長いPython関数を記述することなく、PDFやその他の生成AI用ドキュメントを効率的に準備できます。この合理化されたプロセスにより、文書をAI対応にするために必要な時間と労力が大幅に削減されます。

ドキュメントの前処理は、成功するRAGアプリケーションを構築するための基礎であり、PARSE_DOCUMENTとSPLIT_TEXT_RECURSIVE_CHARACTERがこのプロセスの重要なステップとして機能します。これらの新機能により、ドキュメントの前処理の複雑さと時間が大幅に軽減されます。これにより、ドキュメントをより迅速かつシンプルにRAGチャットボットで使用できるようになり、組織はAIソリューションをすばやく構築して改善できるようになります。 

このブログ記事では、Snowflakeの統合機能により、RAGベースのアプリケーションの構築と展開がどのように簡素化されるかをご紹介します。

RAGシステム用のドキュメントの準備  

RAGアプリのLLMの応答は、そのアプリで利用できるデータによってのみ有効となります。そのため、適切なデータ準備は、パフォーマンスの高いRAGシステムを構築するための基本です。このプロセスは、内部文書、外部データベース、業界固有のコンテンツなどの適切なデータソースの選択から始まります。目標は、データの関連性、最新性、信頼性を確保することです。

ステップ 1：テキストとレイアウトを抽出

必要なデータを収集したら、まずクリーニングと前処理を行います。ほとんどのエンタープライズユースケースでは、検索システムを最適化するために、PDFドキュメントからテキストを抽出し、高度なドキュメント構造分析を組み合わせる必要があります。これを簡単に行うために、段落境界、画像、テーブルに基づいて文書を解析できるレイアウト認識抽出のためのPARSE_DOCUMENTを開発しました。組織は、 PARSE_DOCUMENT SQL関数を使用して、外部ステージ（Amazon S3など）経由でアクセス可能なクラウドストレージサービスで利用できるPDFドキュメントを、元のファイルをSnowflakeにコピーすることなく処理することで、迅速に開始できます。 

すべてのドキュメントが同じであるとは限らないため（一部のPDFでは、段落が分割された大量のテキストが含まれる場合もあれば、テーブルを含む複雑なレイアウトのPDFもある）、カスタマイズされた構文解析戦略は、抽出されたテキストがRAGエンジンで有用であることを確認するのに役立ちます。SQL関数PARSE_DOCUMENTは レイアウトを無視するOCRモードと テーブルを含むドキュメント構造を維持するLAYOUTモードの 2つのモードをサポートしていますOCRモードは通常、テーブル、画像、セクションなどの定義されたレイアウト構造を持たないフラットドキュメントまたはテキストファイルに最適です。技術マニュアル、ビジネスレポート、法律文書など、レイアウト構造が豊富な文書では、検索精度を高めるためにLAYOUTモードをお勧めします。このSQL関数は、複数のマシンにまたがって処理を自動的にスケーリングし、スループットを最適化します。開発者はアプリをシームレスにスケーリングし、何百万ものドキュメントを同時に処理できます。 

ローンチ時、この機能は英語、スペイン語、フランス語、ポルトガル語、ドイツ語、スウェーデン語、ノルウェー語で使用される言語と文字のテキスト抽出に対応しています。最新の詳細とドキュメントの制限事項については、Cortex Parse Documentを参照してください。

ステップ 2：チャンクまたは分割

ドキュメントから関連するテキストとレイアウトを抽出した後、それを管理しやすい小さなチャンクに分割する必要があります。これは、インデックス作成と検索に不可欠です。最も一般的な手法は、ドキュメント内で意味的に似たフレーズを保持しようとするルールベースの分割（例：文、段落、セクションによる）と意味的分割（例：トピックやコンテキストに基づく）の2つです。 

ルールベースの分割を効率化するために、開発者は使いやすい新しいSQL関数SPLIT_TEXT_RECURSIVE_CHARACTERを使用できるようになりました。情報検索時にコンテキストと関連性を維持するには、適切なチャンキングが重要です。各チャンクのサイズは、システムによるデータの取得性能に直接影響します。小さすぎるチャンクはコンテキストが欠落し、大きすぎるチャンクは関連性が薄れる可能性があります。適切なバランスを取ることが不可欠です。SQL関数を使用すると、開発者は適合しやすいチャンクサイズと重複変数を使用して、複数のチャンク戦略を迅速にテストおよび評価できます。プライベートプレビュー中にこの機能にアクセスするには、営業チームにお問い合わせください。その間、開発者は、クイックスタートで示されたように、LangChainなどのカスタムPythonライブラリをSnowpark Python UDFとして実行し続けることができます。 

場合によっては、文字ベースの分割よりも、セマンティックチャンク（意味のある、意味的に完全なチャンクに基づいてテキストをグループ化する）の方が効果的です。たとえば、テーブルを含むドキュメントからテキストを抽出する場合、セマンティックチャンキングはテーブル全体のコンテンツが1つのチャンクに留まるようにするのに役立ちます。マークダウンを出力するPARSE_DOCUMENTレイアウトモードを使用してドキュメントの構造要素を抽出すれば、チャンク間の一貫性が高まり、検索精度が向上します。この戦略により、ドキュメント内のセクションごとに的を絞った要約が可能になります。Arctic Embed（Cortex Searchで使用される埋め込みモデル。HuggingFaceからダウンロード可能）など、好みの埋め込みモデルを使用できます。データ準備パイプラインの一部としてのセマンティック分割の実行例は、この「RAGベースのLLMアシスタントの構築」クイックスタートでご覧いただけます。 

ステップ 3：ベクトル化（埋め込み）とインデックス化

テキストが分割またはチャンクされると、Cortex Searchが残りを処理します。各ドキュメントチャンクは、Snowflake Arctic Embedモデルを使用してベクトル表現に変換（埋め込み）されます。これらの埋め込みはテキストの意味を捉え、効果的な類似度マッチングを可能にします。その後、クエリの類似性に基づいて迅速に検索できるように埋め込みにインデックスが付けられます。このサービスでは、基になるデータソースから変更された行のみを処理し、データのインデックス作成と埋め込みを段階的に行います。

検索サービスの構築に伴う運用上の複雑さはすべて、サービス作成のために単一のSQLステートメントに集約されます。これにより、取り込み、埋め込み、提供のための複数のプロセスを作成、管理する必要がなくなり、最先端のAIアプリケーションの開発に注力できるようになります。

エンタープライズ向けのよりスマートなRAGチャットボットの構築を今すぐ開始

データ準備をマスターすることは、RAGシステムを最適化するための前提条件です。そのために、ドキュメントのテキストとレイアウトの抽出を簡素化するPARSE_DOCUMENTと、効率的なテキストチャンキングを実現する予定のSPLIT_TEXT_RECURSIVE_CHARACTER関数をご紹介します。これらの機能と、すでに組織で信頼を得ているCortex Searchを組み合わせることで、お客様はSnowflake内でエンドツーエンドのRAGワークフローを簡単に合理化できます。Snowflakeのソリューションは、企業がデータの可能性を最大限に引き出すために役立ちます。 

よりスマートで高性能なRAGアプリケーションの構築を、すべてSnowflake内で開始。Cortex Searchを使用して完全なRAGチャットボットをどれほど簡単に構築できるかについては、RAGクイックスタートをご覧ください。