ロボットにコーヒーを作ってもらいたいと思ったのに、代わりにドキュメントから構造化された JSON 出力が返されます。 新しい技術が登場するたびに、誇張表現に埋もれてしまいます。私の Twitter には、1 つのプロンプトで完全な Web サイトを構築したと主張する「インフルエンサー」がたくさんいますが、Web サイトを構築しようとしている人なら誰でも、現在のところ、小さな機能を実装し、コード リポジトリ全体をコンテキストとして、あらゆる長期的なタスクに徹底的に取り組むには十分であることを知っています。 約 10 年前に、 自動運転車が登場すると約束されたことを覚えていますか? 究極の宣伝師であるイーロン マスクは 、「自動運転は解決済みの問題です」と述べました。 明日には 8 年前に テスラが独自にドーナツを作り始めるのを待っている間に、それほど華やかではない取り組みが順調に進んでいました。Mobileye 、何かにぶつかりそうになるとビープ音が鳴るセンサーを開発しました。彼らは数え切れないほどの命を救い、保険金請求を約 90% 削減しました。彼らは 170 億ドル規模の企業を築き上げました。 は 、法学修士課程向けの Mobileye テクノロジであると私は信じています。財務表の理解、保険金請求の集計、医師の診断書からの医療コードの推測は、壮大な夢に比べれば取るに足らないことのように思えます。しかし、この問題をダブルクリックすると、これまで解決されていなかったことがわかり、多くの価値が解き放たれることがわかります。 文書理解は 背景 10 年前、私は LinkedIn の有名なデータ標準化チームで働いていました。私たちは、一見単純な問題の解決に取り組んでいました。それは、どこから来たものであろうと履歴書の意味を理解し、その肩書きを少数の認知された肩書きにマッピングする方法です。 これは簡単だと思うでしょう。つまり、「ソフトウェア エンジニア」というのは、かなりわかりやすい役職ですよね。しかし、誰かが「アソシエイト」と書いたらどうなるでしょうか。その人は棚に商品を補充しているかもしれませんし、法律事務所で 6 桁の給料をもらっているかもしれません。ステーション ハンド (オーストラリアのカウボーイ) とは何でしょうか。コンサルタント (アドバイザー/フリーランスを意味する場合もありますが、英国人で適切な経歴がある場合は医師を意味する場合もあります) とは何でしょうか。検索や販売などのインデックスを作成できるように、認識されている項目のリストに職名を当てはめようとしている場合、すべての言語と文化のニュアンスを理解し、「エグゼクティブ アシスタント」をエグゼクティブと間違えず、アシスタント リージョナル マネージャーが実際にはリージョナル マネージャーの代理人であるようなモデルを構築するにはどうすればよいでしょうか。 これはいいのですが、 で作業する場合、具体的なデータ型が必要になります。 必要です。 LinkedIn JSON が 職名を標準の分類法、つまり許容可能な定義済みの職名の限定されたリストにマッピングするには、さらに作業が必要です。しかし、過去には非常に困難だったことが、いかにして簡単になるかがわかります。 オフィスワークがAIの遊び場になる 履歴書を読むのは良いユースケースですが、革命的ではないと思います。LinkedIn はテクノロジー企業であり、常にこの問題に対して最も鋭いカミソリを当ててきました。多少は改善できるかもしれませんが、私たちは 1 つのコード自動化プロセスを別のものに置き換えているだけです。 退屈な手作業を置き換えると、物事ははるかに面白くなります。経済の大部分は、要するに「文書を読み、そこに何が書かれているかを理解し、そのプロセスをうんざりするほど繰り返す」という専門的な作業を行う人々に基づいています。 いくつか例を挙げてみましょう: 請求書があり、それを数字のリストに変換する必要があります。つまり、いくら、誰に、どの通貨で支払われたかです。簡単そうに聞こえますか? 請求書が雑然とした余分な情報、不完全な表、または誰かがミキサーにかけたような PDF に埋もれていると、簡単ではありません。 経費管理: これは悪夢のような作業ですが、医療費請求審査官の軍団によって解決されます。彼らは、請求書、医師のメモ、重複して絡み合った請求書の山をふるいにかけ、既存の健康保険証と照合して、請求が補償されるかどうか、どのカテゴリに該当するか、金額はいくらかを判断しなければなりません。しかし、結局のところ、ほとんどは読み取り、並べ替え、ラベル付けだけです。決定は難しくありません。課題となるのは、データ抽出です。 医療費請求処理: 誰かの銀行取引明細書を確認し、キャッシュフローを分類します。繰り返しますが、これはロケット科学というよりも、構造化されていない情報を構造化することです。 ローンの引受: 魅力的？いいえ。役に立つ？そうだと思います。 文書抽出は基礎的な作業である 今では、法学修士課程の学生は幻覚、つまり作り話をすることで有名です。しかし、現実はもっと微妙です。幻覚は、世界に関する知識を求めるときには予想されますが、 では基本的に排除されます。 地に足のついた課題 LLM は、自分が「知っている」ことを評価するのが特に得意というわけではありません。明示的にそのためのトレーニングを受けていないため、それができるのはむしろ幸運な副産物です。主なトレーニングは、テキスト シーケンスを予測して完了することです。ただし、LLM にグラウンデッド タスク (予測を行うために明示的に与えられた入力のみが必要なタスク) が与えられると、幻覚率は基本的にゼロにまで下がります。たとえば、このブログ投稿を ChatGPT に貼り付けて、ペットのフェレットの世話の仕方を説明しているかどうかを尋ねると、モデルは 100% の確率で正しい応答を返します。タスクは予測可能になります。LLM は、テキストのチャンクを処理し、有能なアナリストが空白をどのように埋めるかを予測することに長けています。その 1 つは {“ferret care discussed”: false} かもしれません。 元 AI コンサルタントとして、私たちは、特に保険や金融などの業界で、ドキュメントから情報を抽出することに重点を置いたプロジェクトに取り組んできました。「LLM は幻覚を起こす」というのが一般的な懸念でしたが、実際には、最大の課題は、テーブル抽出のエラーやその他の入力の不一致によるものであることが多かったのです。LLM が失敗するのは、明確で明確な入力を提供できなかった場合のみです。ドキュメント処理を正常に自動化するには、次の 2 つの重要な要素があります。 – これには、表、手書きのメモ、さまざまなレイアウトの処理を含め、ドキュメントをクリーンで機械可読なテキストに変換することが含まれます。LLM では、明確で理解しやすいテキストを使用する必要があります。 完璧なテキスト抽出 – これらのスキーマは、どのような出力を求めているか、エッジケースをどのように処理するか、データの形式を定義し、システムが各ドキュメント タイプから何を抽出するかを正確に認識できるようにします。 堅牢なスキーマ 幻覚の潜在的なリスクと実際の技術的なハードルの間には大きなギャップがある可能性がありますが、これらの基礎が整っていれば、ドキュメント処理ワークフローで LLM を効果的に活用できます。 テキスト抽出は見た目以上に難しい LLM がクラッシュして失敗し、途方もなく悪い出力を得る原因は次のとおりです。 入力には 2 列レイアウトのような複雑な書式設定があり、たとえば PDF からテキストを左から右にコピーして貼り付けると、文章が完全に文脈から外れてしまいます。 入力にはチェックボックス、チェックマーク、手書きの注釈があり、テキストへの変換時にそれらを完全に見逃してしまいました。 さらに悪いことに、テキストへの変換を回避できると考え、ドキュメントの画像を貼り付けて GPT が独自に推論してくれることを期待します。これでは幻覚状態に陥ってしまいます。空のセルがいくつかある表の画像を GPT に転記するように依頼するだけで、GPT が喜んで狂ったように暴れ回り、勝手なことをでっち上げるのがわかります。 現実世界の書類ではどんなに混乱した状況になるかを思い出しておくと役に立ちます。以下はランダムな納税申告書です。 もちろん、実際の納税申告書にはこれらのすべての欄が手書きで記入されていることが多い。 または、ここに私の履歴書があります または、公開されているラボレポートの例（これは Google のトップページの結果です） ちなみに、絶対にやってはいけないことは、GPT のマルチモーダル機能を使って表を書き写すことです。勇気があるなら試してみてください。一見正しく見えますが、表のセルの一部にまったくランダムなものが作られ、文脈から完全に外れたものが作られるなど、さまざまな問題が起こります。 世界に何か問題があれば、SaaS企業を立ち上げて解決しましょう こうした種類の文書を理解するという課題に直面したとき、共同設立者の と私は、こうしたテキストを理解するための既成のソリューションが存在しないことに困惑しました。 Nitai Dean AWS Textract のように、この問題を解決できると主張する人もいます。しかし、私たちがテストした複雑なドキュメントでは、多くの間違いを犯します。さらに、チェックマーク、ラジオボタン、取り消し線付きのテキスト、フォーム上の手書きの落書きなどを認識するなど、細かい必要な作業が山積みです。 そこで、私たちは を構築しました。これは、まず、入力したページのクリーンなテキスト表現を生成します。左側には元の文書が表示され、右側にはテキスト出力が表示されます。 Docupanda.io 表も同様に処理されます。内部的には、表を人間が読み取り可能で LLM が読み取り可能なマークダウン形式に変換するだけです。 LLM でデータを理解する最後のステップは、厳格な出力形式を生成してそれに従うことです。AI に出力を JSON 形式に成形させるのは素晴らしいことですが、データにルール、推論、クエリなどを適用するには、規則的に動作させる必要があります。データは、コンテンツで埋める定義済みのスロット セットに準拠する必要があります。データの世界では、これを と呼びます。 スキーマ スキーマの構築は試行錯誤のプロセスです…LLMならそれができます スキーマが必要な理由は、規則性がなければデータは役に立たないからです。患者の記録を処理していて、それが「男性」「Male」「m」「M」にマッピングされている場合、それはひどい仕事です。 では、スキーマはどのように構築するのでしょうか。教科書では、長時間じっと座って壁を見つめ、抽出したいものを定義することでスキーマを構築するかもしれません。座って、医療データの操作について熟考し、「患者の名前、日付、性別、医師の名前を抽出したい。ああ、性別は M/F/その他でなければならない」と考えます。 現実世界では、文書から何を抽出するかを定義するには、文書をじっと見つめる必要があります... 何度も。上記のようなことから始めますが、文書を見てみると、そのうちの 1 つには医師が 1 人ではなくリストされていることがわかります。また、医師の住所も記載されているものがあります。住所にはユニット番号と建物番号が付いているものもあるので、そのためのスロットが必要になるかもしれません。このように、どんどん続きます。 私たちが気づいたのは、抽出したいすべてのものを正確に定義できることは、簡単ではなく困難だが、AI を使えば非常に解決可能であるということです。 これが DocuPanda の重要な部分です。LLM にすべてのドキュメントの出力を即興で作成するよう依頼するのではなく、次のことを可能にするメカニズムを構築しました。 自由な言語で文書から何を得たいかを指定します 当社の AI が 文書をマッピングし、すべての質問に答え、実際の文書で見られる不具合や不規則性に対応するスキーマを導き出します。 多数の フィードバックに基づいてスキーマを変更し、ビジネスニーズに合わせて調整します。 最終的に得られるのは、強力な JSON スキーマです。これは、すべてのドキュメントから何を抽出したいかを正確に指定し、数十万のドキュメントをマッピングして、常に同じ形式で日付を抽出したり、定義済みのカテゴリのセットを尊重するなどのルールに従いながら、すべてのドキュメントに対する回答を抽出できるテンプレートです。 他にもたくさんあります! ウサギの穴と同じように、そこにはいつも、一見しただけではわからないものが潜んでいます。時間が経つにつれて、さらに多くのものが必要であることがわかりました。 多くの場合、組織は匿名文書の流入ストリームを処理する必要があるため、それらを自動的に分類し、どのスキーマを適用するかを決定します。 文書は多くの文書の連結であることが多く、非常に長い文書を原子レベルの個別のコンポーネントに分割するためのインテリジェントなソリューションが必要になります。 生成された結果を使用して適切なドキュメントをクエリすることは非常に便利です この記事から得られる教訓が 1 つあるとすれば、LLM を活用して通常の方法で文書の意味を理解することを検討する必要があるということです。教訓が 2 つあるとすれば、 も試してみる必要があるということです。私がこれを構築している理由は、これに自信があるからです。試してみるには十分な理由かもしれませんね。 Docupanda.io
