LLM時代、検索性能を決めたのはモデルではなく「文書構造」でした
あわせて読みたい記事：PDF・HWPパース技術を理解する
生成AIとRAG（Retrieval-Augmented Generation）が急速に広がるなか、多くの企業がLLMベースの検索システムを構築しました。しかし現場では、また別の壁にぶつかります。
「モデルは最新なのに、検索精度が上がらない。」
「VectorDBを積み上げたのに、回答が的外れだ。」
「同じ文書なのに、結果が安定しない。」
韓国ディープラーニングは、この問題をLLMの限界とは見ませんでした。問題の本質はモデルではなく、文書をどう分解（チャンキング）して保存したかにあったのです。
DEEP Parserが市場で選ばれた理由は、単なる性能の優位ではありません。RAG構造のボトルネックを正確に突いたからです。
従来のParserはどこで止まったのか
OCRベースParserの構造的な限界
初期のParserはOCRベースでした。画像内のテキスト全文を認識し、表はHTMLで表現しました。
表面的には「構造化」のように見えました。しかし、次のことは不可能でした。
見出しと段落の階層の認識
文書構造の意味の解釈
画像・グラフの説明および要約表現
テキストは抽出できても、文書を理解することはできませんでした。文書の見た目を「再現」するにとどまっていたのです。
この状態でChunkingを行うと、見出しと本文が切り離され、表とキャプションが分断され、文脈が崩れたままVectorDBに保存されます。
RAGの精度が頭打ちになる理由は、ここから始まります。
LLM時代にParserが重要になった理由
LLM事業で検索性能を高めるには、VectorDBの構成が非常に重要です。LLMを直接チューニングするよりも、不足しているドメイン知識を別のDB（VectorDB）で補い、学習していない情報にも答えられるようにする構造が一般化したからです。
しかしVectorDBの品質は、どれだけ意味単位で正確にChunkingできたかにかかっています。つまり、文書を細かく分けることではなく、意味を保ったまま分解することが核心です。
この点で、従来のParserは限界を見せました。そしてDEEP Parserは、別の問いから出発しました。
DEEP Parserの出発点
「この文書は、どんな構造で成り立っているのか。」
「各要素は、どんな意味単位なのか。」
DEEP Parserは、Vision-Language Model（VLM）ベースです。文書をテキストブロックとしてではなく、画面全体の意味構造として理解します。
MS Office、HWP、PDF、画像などさまざまな文書からデータを抜き出し、VectorDB構成のためのChunk単位に再構成する文書AI技術です。
単なるOCRの拡張ではなく、LLM時代を前提に設計されたParserです。
DEEP Parserの主要機能
Elementベースの文書表現
DEEP Parserは、文書を次のようなElementに分解します。
Title – 文書の大見出し
Section-header – 段落の見出し
Text – 一般テキスト
Page-header – ヘッダー
Page-footer – フッター
List-item – 箇条書き
Caption – 表・画像のキャプション
Footnote – 脚注
Table – 表
Picture – 画像
Chart – チャート・グラフをHTMLテーブルとして解釈
Flowchart – フローチャートを自然言語として解釈
Formula – 数式を論文表記に変換
この構造は、単なる可視化のためのものではありません。Chunkingの基準になります。
意味単位が保たれたままVectorDBに保存されるため、検索精度が構造的に変わります。文書上でどの情報がどんな役割を果たすのかを明示するので、検索精度は上がらざるを得ないのです。
構造化データの提供
文書の分析および情報抽出の結果は、JSON、Markdown、HTML形式で提供します。
これは人が見るための画面ではなく、システム連携を前提としたデータです。
ERP、EDMS、Agent、RAG、LLMのパイプラインと即座に連携できる構造です。
運用環境で検証された性能
最近のテスト条件は次のとおりです。
テスト環境：DGX B200 × 2
テスト文書：オンナラ文書 第5次 国家安全管理基本計画（100ページ基準）
総所要時間：52秒
1ページあたりの処理速度：0.52秒（B200 1枚基準で0.71秒）
この数値は単なるテキスト抽出の速度ではなく、構造解釈まで含んだ処理速度です。これは業界でも目を見張る数値だと言えます。人が自分で読んで分析する時間と比べれば、途方もない時間短縮です。
対応環境とファイル形式
対応ファイル形式は次のとおりです。
.pdf, .hwp, .hwpx
.doc, .docx
.xlsx, .ppt, .pptx
.jpg, .png, .tif, .tiff
.txt, .csv
.odt, .hwtx, .owpml
これは公共・企業の文書環境を幅広くカバーします。
オンプレミス環境を前提に設計されており、HWプラン、インストールディレクトリ構成、大容量処理まで考慮しています。セキュリティが重要な組織でも、データを外部に持ち出すことなく運用できます。
京畿道庁への導入事例
導入の構成はシンプルです。
Agentを通じて文書をアップロード
DEEP Parserで構造を分析
抽出したデータをVectorDBに埋め込み
RAGベースで質問応答を実行
フローは次のとおりです。
Parser → VectorDB → RAG → LLM
モデルを替えなくても検索精度が上がる構造です。
なぜDEEP Parserは市場で勝ったのか
DEEP Parserは、OCRの性能競争をしませんでした。モデルの大きさを競うこともしませんでした。もちろんそれらも重要ですが、実際に動作し、意味のあるデータを抽出することのほうが重要だと考えたのです。その代わりに、RAGのボトルネックがParserにあるという点を突きました。
文書を理解できなければ、VectorDBは積み上がっても、検索は正確になりません。
DEEP Parserは、文書をElement単位で再構成し、意味単位でChunkingし、構造を保ったまま保存します。
その結果、モデルを替えなくても性能が上がります。
LLM時代の競争は、誰がより大きなモデルを使うかではなく、誰がより正確に文書を構造化するかです。
その点でDEEP Parserは、機能ではなくインフラになりました。
そして市場は、最終的にインフラを選びます。