ドキュメントは何十年もの間、そのコンテンツをソフトウェアから頑固に保護してきました。 1960 年代後半、最初の OCR (光学式文字認識) 技術により、スキャンしたドキュメントが生のテキストに変換されました。これらのデジタル化された文書からテキストを索引付けして検索することにより、ソフトウェアは以前は骨の折れる法的証拠開示および調査プロジェクトをスピードアップしました。 現在、Google、Microsoft、および Amazon は、クラウド サービスの一部として高品質の OCR を提供しています。しかし、ドキュメントはソフトウェア ツールチェーンで十分に活用されず、貴重なデータは .課題は、ドキュメント内のテキストを識別することから、ソフトウェアベースのワークフローで直接使用したり、記録システムに直接保存したりするのに適した構造化データに変換することへと移行しています。 数兆の PDF 多くの場合「AI」として装飾される機械学習が、時代遅れで脆弱なテンプレートベースの手法に取って代わり、これを達成するための最良の方法であるというのが一般的な仮定です。この仮定は間違っています。 最善の方法は、人が行うのと同じようにドキュメント内のデータを検索する、次世代の強力で柔軟なテンプレートを使用することです。 大部分のドキュメントを構造化データに変換する 機械学習の約束と失敗 機械学習の約束は、代表的なドキュメントの大規模なコーパスでモデルを一度トレーニングしてから、再トレーニングなしでサンプル外のドキュメント レイアウトにスムーズに一般化できることです。たとえば、会社 A、B、および C の住宅保険証券で ML モデルをトレーニングし、会社 Z が発行した同様のドキュメントから同じデータを抽出したいとします。これは、次の 3 つの理由から、実際には非常に困難です。 ドキュメント抽出は、機械学習にとって非常に細かいタスクです 多くの場合、目標は、各ドキュメントから数十または数百の個別のデータ要素を抽出することです。ドキュメント レベルの粒度のモデルでは、これらの値の一部が失われることが多く、これらのエラーを検出するのは非常に困難です。モデルがサンプル外のドキュメント タイプから数十または数百のデータ要素を抽出しようとすると、一般化が失敗する可能性が爆発的に増加します。 ドキュメント内のデータ要素は通常、相互に階層的な関係を持っています 一部の単純なドキュメントにはフラットなキー/値のオントロジーがある場合がありますが、ほとんどのドキュメントには下位構造があります。住宅検査レポートの欠陥リストや銀行取引明細書の一連のトランザクションを考えてみてください。場合によっては、複雑にネストされた下位構造に遭遇することさえあります。それぞれが請求履歴を持つ保険証券のリストを考えてみてください。これらの階層を推測するために機械学習モデルが必要になるか、トレーニングの前にこれらの階層と全体的な目的のオントロジーを使用してモデルを手動でパラメーター化する必要があります。 「ドキュメント」は、Ml プロジェクトのあいまいなターゲットです ドキュメントとは、1 枚または複数枚の紙に収まるデータを含むものです。ドキュメントは、実際には多様で恣意的なデータ表現の袋にすぎません。表、ラベル、フリー テキスト、セクション、画像、ヘッダー、フッター: 名前を付けると、ドキュメントでデータをエンコードするために使用できます。たとえセマンティクスが同じであっても、2 つのドキュメントが同じ表現ツールを使用するという保証はありません。 ML ベースのドキュメント解析プロジェクトが数か月かかり、事前に大量のデータが必要であり、印象に残らない結果につながり、一般的に「厳しい」ものになることは驚くことではありません (この分野の主要なベンダーとのそのようなプロジェクトの参加者を直接引用すること)。 ）。 テンプレートの課題 これらの問題は、ドキュメントを構造化するための適切な攻撃角度が、ドキュメント全体レベルではなくデータ要素レベルであることを強く示唆しています。つまり、テーブル、ラベル、フリー テキストからデータを抽出する必要があります。総合的な「文書」からではありません。また、データ要素レベルでは、ドキュメントに見られる表現モードの世界とソフトウェアに役立つデータ構造との関係を表現するための強力なツールが必要です。 それでは、テンプレートに戻りましょう。 歴史的に、テンプレートには、表現モードとデータ構造の間のマッピングを表現する手段が不十分でした。たとえば、次のように指示する場合があります: 3 ページに移動し、これらのボックス座標内のテキストを返します。これは、次の場合を含め、さまざまな理由ですぐに故障します。 スキャンが傾いている 表紙があるか、 ドキュメントの作成者は、ターゲット データの前にセクションを追加しました。 ドキュメント レイアウトに対するこれらの小さな変更は、人間の読者を驚かせるものではありません。 ドキュメントのクエリ言語 ソフトウェアが複雑なドキュメントをうまく構築するためには、数か月にわたる ML プロジェクトと脆弱なテンプレートとの戦いを回避するソリューションが必要です。代わりに、(適切な場合) ML をドキュメント レベルではなくデータ要素に埋め込む、ドキュメント固有のクエリ言語を構築しましょう。 まず、表現モード (ラベル/値のペアやサブセクションの繰り返しなど) を記述し、典型的なレイアウトのバリエーションに対する回復力を維持する言語のプリミティブ (つまり、命令) が必要です。たとえば、次のように言います。 「この単語で始まる行を見つけて、そこから最低金額を取得してください」 空白の変化、縦方向のジッター、表紙、ドキュメントのゆがみに強い「行」認識と、強力なタイプ検出とフィルタリングが必要です。 第 2 に、表、チェックボックス、フリー テキストの段落など、視覚的または自然言語コンポーネントを含むデータ表現の場合、プリミティブに ML を埋め込む必要があります。このレベルの分析では、Google、Amazon、Microsoft、および OpenAI はすべて、すぐに使用できるツールを備えています。 北極星として価値を生み出すまでの時間 は、強力で柔軟なテンプレートと機械学習を融合させるというまさにそのアプローチを採用しています。と 、ドキュメント用の JSON ベースのクエリ言語を使用すると、1 つの参照サンプルだけで、ほとんどのドキュメント レイアウトから数分で構造化データを抽出できます。何千ものトレーニング ドキュメントやアルゴリズムの微調整に何ヶ月も費やす必要はありません。また、わずかなレイアウトの違いを考慮して何百ものルールを記述する必要もありません。 Sensible SenseML SenseML の幅広いプリミティブにより、表現モードを複雑なネストされたサブ構造を含む有用なデータ構造にすばやくマップできます。プリミティブが ML を使用しない場合、それらは決定論的に動作し、強力な動作と精度の保証を提供します。また、テーブルなど、ML を利用したプリミティブの非決定論的な出力であっても、検証ルールによって ML 出力のエラーを特定できます。 つまり、Sensible を使用したドキュメントの解析は、信じられないほど高速で、透過的で、柔軟です。テンプレートにフィールドを追加したり、エラーを修正したりするのは簡単です。 Sensible の迅速な価値実現のトレードオフは、意味のある個別のドキュメント レイアウトごとに個別のテンプレートが必要になることです。しかし、このトレードオフは、現実の世界ではそれほど悪くないことが判明しました。ほとんどのビジネス ユース ケースでは、数え切れないほどの数のレイアウトがあります (たとえば、米国でレート確認を生成する数十のトラック運送業者や、住宅検査レポートを生成する少数のソフトウェア システムなど)。当社のお客様は、何千ものドキュメント テンプレートを作成するわけではありません。ほとんどのテンプレートは、ほんの数個で大きな価値を生み出します。 もちろん、広く使用されているすべての納税申告書、保険証書、および雇用の検証について、まとめてテンプレートを作成する必要があるのは 1 回だけです。そのため、導入したのは… Sensible のビルド済みテンプレートのオープンソース ライブラリ 私たちのオープンソース は、最も頻繁に解析される 100 を超えるドキュメント レイアウトのコレクションです。 に 、 、 、 と .幅広い関心のあるドキュメントがある場合は、オンボーディングを行い、一般に無料で公開します。また、無料アカウント層では、1 か月あたり最大 150 回の抽出に無料で使用できます。 賢明な構成ライブラリ 自動車保険 アコードフォーム 連敗 納税フォーム もっと このハイブリッドなアプローチは、ロジスティクス、金融サービス、保険、ヘルスケアなど、さまざまな業界で文書を構造化データに変換するという問題を透過的かつ効率的に解決するための道であると考えています。この旅に参加して、ドキュメントをソフトウェアに接続したい場合は、 また ! デモをスケジュールする 無料アカウントにサインアップする
