クイックアンサー
Quick Answer
複数行項目証明書抽出には、パーサーがテーブル境界を検出し、列ヘッダーを行全体の値と関連付け、複数のヒートまたは行項目を別個のレコードに分割し、テーブル内のページ区切りを処理する必要があります。これは単純なOCRパイプラインを圧倒する課題ですが、ビジョン言語モデルとテーブル認識抽出スキーマで対処できます。
単一ヒート製造所試験証明書は、最も単純な抽出ケースです：化学値1セット、機械試験結果1セット、ヒート番号1つ。実際のドキュメントフローはめったにそのようにきれいではありません。鋼鉄サービスセンターは数十のヒートをカバーする統合証明書を発行しています。板材製造所は単一ヒート全体の複数の試験位置を表にします。パイプメーカーは、本体と溶接化学を横並びの列に含めます。
複数行項目抽出は、単純なパーサーが失敗し、堅牢な抽出アーキテクチャがその価値を証明する場所です。
複数行項目ドキュメントの種類
障害モードを理解するには、ドキュメント構造を区別する必要があります：
タイプ1：複数ヒート統合証明書 1つのPDFが複数のヒート番号をカバーしており、各々がそれ自身の化学および機械試験データを持っています。鋼鉄サービスセンターおよび供給者MTCを統合形式で再発行する流通業者からの一般的です。典型的な構造：各行が別個のヒートであるテーブル。
タイプ2：複数試料機械試験テーブル 複数の試験試料結果を持つ単一ヒート（例えば、板上の5つの位置での-20℃でのシャルピー衝撃試験）。ヒートデータは単数です；機械試験テーブルのみが複数行を持ちます。
タイプ3：注釈付き複数要素化学テーブル 標準化学テーブルに加え、補足要素（ホウ素、窒素、残留物）が同じまたは後続ページの二次テーブルにあります。両方のテーブルが同じヒートに属します。
タイプ4：複数ヒート、複数ページ証明書 テーブルが複数ページにわたり、列ヘッダー行が最初のページにのみ表示される統合証明書。
タイプ5：行項目購買発注照合証明書 複数のPO行項目をカバーする証明書で、各々が異なる材料等級、サイズ、および関連するヒート参照を持つもの。EPCプロジェクトドキュメントパッケージで一般的です。
これらの各構造には異なる抽出戦略が必要です。
OCRパイプラインが複数行テーブルで失敗する理由
従来のOCRはページを読む順序の文字ストリームに処理します。8行のヒートにわたる12要素の化学テーブルでは、OCRは次のようなものを返します：
C Mn Si P S Cr Mo Ni
0.18 1.42 0.28 0.012 0.008 0.02 0.01 0.08
0.21 1.38 0.31 0.015 0.010 0.02 0.01 0.09
...
ヘッダー行は保持され、値は順序で表示されます。しかし、後処理パイプラインは次のことを実行する必要があります：
- どの行がヘッダーであるかを識別する
- 各データ行の各値を対応する列ヘッダーと関連付ける
- 各行を識別するヒート番号を検出する
- ヒート番号が別個の前行または統合セル内にある場合を処理する
この列関連付けロジックは以下で中断されます：
- 統合されたヘッダーセル（複数列にわたる）を持つテーブル
- 階層的ヘッダー（メイングループ+副要素）を持つテーブル
- 列幅が大きく異なるテーブル
- 空白セル（その要素について実行されたテストなし）を持つテーブル
- セルに埋め込まれた脚注参照を持つテーブル
ビジョン言語モデルがテーブル構造を処理する方法
VLMはページをイメージとして処理し、視覚的にテーブル構造を理解します。列ヘッダーが特定の幅にわたり、その下の値は読み順の文字シーケンスに関係なくそれらの列に属することを認識します。モデルは次のことができます：
- 統合されたヘッダーセルを特定し、すべてのサブ列にヘッダーを適用する
- 空白セルを誤読された値ではなく明示的な「テストされていない」として検出する
- 階層的ヘッダー（例えば、「化学%」と各要素のサブヘッダー）を認識する
- 最左列のヒート番号を値の各行と関連付ける
複数ページテーブルの場合、モデルはページ区切りケースの明示的な処理が必要です：ページ1の列ヘッダーは、ページ2のデータ行に伝播する必要があります（ヘッダーが表示されない場所）。これには、独立してではなく順序でページを処理するドキュメント層のコンテキストが必要です。
セグメンテーション：テーブルからレコードへ
テーブル抽出後、システムはテーブルを個別のレコード（各ヒートまたは行項目ごと）に分割する必要があります。このセグメンテーションステップはフィールド抽出ステップから論理的に分離され、独自のロジックが必要です：
行ベースセグメンテーション：テーブル内の各行がレコードです。最初の列のヒート番号は主キーです。これは複数ヒート統合証明書の一般的なケースです。
グループベースセグメンテーション：複数行が同じヒート（複数試料結果）に属します。システムはグループ境界（通常は統合セルまたは繰り返されるヒート番号）を検出し、複数試料データの行をネストされた配列を備えた単一のヒートレコードに集約する必要があります。
クロスリファレンスセグメンテーション：行項目はドキュメントの他の場所に表示されるヒート番号を参照します（例えば、梱包リストテーブルが別の化学セクションに表示されるヒート番号を参照）。抽出には完全なレコードを構築するためにドキュメント内でのクロスリファレンスが必要です。
TestCertなどのプラットフォームはスキーマ駆動の抽出パイプラインを通じて3つのセグメンテーションパターンすべてを処理し、適用可能なセグメンテーションパターンは取り込み時のドキュメント分類に基づいて選択されます。
複数ページテーブルでのページ区切りの処理
複数ページテーブルケースは大規模なプロジェクトドキュメントパッケージで一般的です。正しい方法：
- ページ1のテーブルを検出します（列ヘッダーとその位置を含む）
- テーブルが継続することを検出します（通常は「続く」ラベル、一致する列構造、または閉鎖ボーダーの欠如を通じて）
- ページ1から列ヘッダーマッピングを保存します
- そのマッピングを後続ページのデータ行に適用します
- レコードに分割する前に完全なテーブルを再構築します
ページを独立して処理する抽出器（コスト上の理由で一般的な設計）はこのケースを静かに失敗します。ページ1を正しく抽出し、継続ページに対して不完全または形式が正しくないレコードを生成します。
複数行抽出後の検証
抽出された各行項目レコードは独立して検証する必要があります：
- 化学合計チェックは合格しますか？（炭素+マンガン+ケイ素+...は指定された等級に対して妥当である必要があります）
- 機械値は指定された規格の限界内にありますか？
- ヒート番号が存在し、バッチ内で一意ですか？
- 必須フィールドは入力されていますか？（複数ヒートテーブルの一部は簡潔さのために繰り返された値を省略します；欠落値はフラグが立てられるべきで、黙ってゼロとして受け入れられるべきではありません）
ドキュメント層ではなくレコード層での検証により、1つの有効なヒートが同じ証明書上の他のヒートの問題をマスクするのを防ぎます。
FAQ
証明書抽出器が確実に処理できる最大行項目数はいくつですか？
固定最大値はありませんが、累積レイアウト推論エラーが原因で非常に大きなテーブル（50+行）の精度は低下する傾向があります。非常に大きな統合証明書の場合、抽出前にページまたはセクション別にドキュメントを分割し、その後結果をマージするとすることで信頼性が向上します。実際には、ほとんどの本番MTCはドキュメントあたり1–20のヒートを持ちます。
システムはいくつかの要素の化学が欠落している行項目をどのように処理すべきですか？
空白セルはゼロではなくnull（テストされていない）として記録されるべきです。ゼロの炭素値は化学的に無意味です；nullは要素が仕様で必要とされなかったか、テストされなかったことを意味します。レコードが標準検証に使用される場合、区別が重要です。nullは「最小値以下」の障害をトリガーすべきではありません。
各ヒートが異なる適用等級を有する証明書を抽出は処理できますか？
はい、抽出スキーマが行ごとの標準/等級フィールドをサポートしている場合。一部の統合証明書はすべてのヒートに対して単一の等級を指定します（より単純）；その他はヒートごとに異なる等級を一覧表示します（より複雑）。抽出器は適用されるパターンを検出し、それに応じてマップする必要があります。ダウンストリーム検証は、その後、各ヒートを自身の指定等級ではなくドキュメント層等級に対して確認する必要があります。
申し訳ございません、前の回答に誤りがありました。正しくは以下のとおりです：
ダウンストリーム検証は、その後、各ヒートをドキュメント層等級ではなく自身の指定等級に対して確認する必要があります。
テーブルヘッダー行がテーブルの中央で繰り返される場合（一部のツールがページネーションのために挿入する場合）はどうなりますか？
繰り返されたヘッダー行は既知のPDFアーチファクトです。堅牢な抽出器はデータ本体の繰り返されたヘッダー行を検出して無視し、データ行として扱いません。列ヘッダーパターンと正確に一致する行コンテンツはヘッダーとして分類され、データ抽出から除外されるべきです。
一部のヒートが補足試験データを持ち、他のヒートは持たない証明書をどのように処理しますか？
抽出スキーマは補足試験フィールドをオプションとして定義すべきです。補足データを持つヒートがそれらのフィールドを入力し；持たないヒートはnullのままにします。レビューアーインターフェースは補足データの存在または不在を表示すべきので、レビューアーは欠落している補足データが抽出ミスではなく実際のドキュメントコンテンツを反映していることを確認できます。
Ready to automate your certificate workflow?
Try TestCert free