ドキュメントはテキストではないため、ほとんどの検索が静かに失敗するのは解析です。

取得プロジェクトは上からデバッグされる傾向があります。答えは間違っていたため、プロンプトが調べられ、次にモデル、次にチャンキング戦略が検査されます。ほとんど検査されることのないレイヤーは最初のレイヤーです。つまり、文書から出てきたテキストが実際にどのように見えるかです。

私たちの経験では、問題の驚くべき部分がそこにあります。

ドキュメントと文字列の間で何が問題になるのか

読む順番。 2 列のレイアウトでは、両方の列から断片が交互に抽出され、個々には文法的で、全体としては意味のない文が生成される可能性があります。

テーブル。テーブルはその構造に意味があります。一連のセル値に平坦化されると、行ラベルとその数値の間の関係がなくなり、数値について尋ねられたエージェントは、その数値を近くにあるものと関連付けることになります。

ヘッダー、フッター、ページ家具。すべてのページで繰り返され、毎回抽出されると、それらは到達するすべてのチャンクを薄め、短いチャンクを支配する可能性があります。

脚注とキャプション。何らかの理由で下部に表示され、注釈を付けた段落に直接接続されることがよくあります。

スキャンしたページ。場合によっては、テキスト レイヤーがまったく存在せず、抽出が大声で壊れるのではなく、静かに空になることがあります。

気づかれない理由

これらはすべて、テキストのような出力を生成します。エラーも例外も、警告するものもありません。パイプラインは成功を報告し、インデックスが構築されますが、劣化が現れるのは、ずっと後になってからであり、エージェントが 1 つのクラスの質問に対して不可解に信頼できないことになります。

誰かが調査する頃には、解析ステップは 3 層の抽象化が完了しており、プロジェクトの開始以来、正常に動作しています。

それについて何をすべきか

自分で抽出したテキストを読んでください。きれいな文書のサンプルではなく、ぎこちない文書です。スキャンされた契約書、横長の表を含むレポート、フォームなどです。抽出出力を 10 分間読み取るだけで、1 週間以上の迅速な調整が可能になります。

存在する場所に構造を保存します。見出し、テーブル、セクション境界はチャンク化の自然な単位であり、パーサーがそれらを保持している場合にのみ使用できます。

文書、ページ、セクションなど、あらゆる部分に出所を伝えます。答えが間違っていると、デバッグが検索ではなく検索になってしまいます。

スキャンした文書は期待せずに慎重に処理してください。テキストレイヤーのないページは認識が必要であり、認識には独自の品質チェックが必要です。

他のすべてのものとどのように接続するか

解析には上限が設定されます。抽出時に構造が破壊されたテーブルは、取得戦略もモデルもプロンプトも回復できません。すべての下流の改善は破損したベースラインに対して測定されるため、これは修正するのが最も安価なレイヤーであり、無視するのが最も高価なレイヤーです。

これは、評価セットに代表的な文書ではなく、難しい文書を含めるべき理由でもあります。クリーンな PDF から構築されたセットは、誰かがスキャンした PDF について尋ねるまでは、すべてが正常であると報告します。

次へ

解析ページでは、サポートされている形式と構造の保存について説明します。開発者ドキュメントでは、チャンキングと取得について説明しています。チャンクと取得は、このレイヤーのすぐ上のレイヤーであり、完全にそれに依存しています。