韓国ディープラーニングが、グローバルな文書AIのベンチマークで、またしても1位を記録した。
去る3月、韓国ディープラーニングのKDL Frontierは、OCRBench v2の英語部門で、Gemini、GPT、NVIDIAといったグローバルビッグテックのモデルを上回り、総合1位を獲得した。そして数か月後、LlamaIndexが主催する文書パーシングのベンチマークParseBenchでも、VLM部門で総合1位に輝いた。
最初の成果が韓国ディープラーニングのOCR技術力を示したものだとすれば、今回の成果は文書パーシングの技術力を示している。
今回評価されたモデルは、KDL-Frontier-Parser-nanoだ。12億個、すなわち1.2Bパラメータ規模の超軽量モデルである。従来のオープンソース1位モデルの約30分の1のサイズでありながら、Google Gemini 3 Flash、OpenAI GPT-5.5といったグローバルな商用VLMを上回った。
モデルが大きくなるほど性能も上がる、という潮流の中で、韓国ディープラーニングは小さなモデルで、より高い文書パーシング性能を証明した。
KDL-Frontier-Parser-nanoの開発に携わったAIエンジニアのGinnieに話を聞いた。小さなモデルが、どうやって複雑な企業文書を構造化できたのか、文書パーシングでレイアウトの理解がなぜ重要なのか、そしてParserがRAGやAIエージェントの性能にどんな影響を与えるのか、じっくり聞いてみた。
「大きなモデルでなくても、文書をきちんと見れば、性能は出ます。」
Q. まず、ParseBench VLM部門での1位達成の、率直な感想を聞かせてください。
うれしかったです。グローバルなベンチマークで1位を取ったことは、開発者として間違いなく意味のあることですから。特に、Google GeminiやOpenAI GPT-5.5のような商用VLMモデルよりも高いスコアを得られた点も、印象的でした。
ただ、今回の結果でまず目を向けたのは、順位よりもモデルのサイズでした。KDL-Frontier-Parser-nanoは1.2B規模の小さなモデルです。従来のオープンソース1位モデルだったInfinity-Parser2-Proは35.1Bでした。はるかに小さなモデルで、より良い性能を出したことになります。
私たちが最初から作りたかったのも、とにかく大きなモデル、というわけではありませんでした。企業や機関が実際に動かせるモデルを作りたかったのです。セキュリティ環境でも自ら展開でき、コストやインフラの負担を抑えながらも、文書構造を安定的に処理するモデルが必要だと考えました。
今回の結果は、文書パーシングにおいては、モデルのサイズと同じくらい、設計の仕方が重要だということを示したように思います。
OCRBenchとParseBench、二度の1位
Q. 韓国ディープラーニングは、OCRBench v2に続いてParseBenchでも1位を取りました。この二つの成果は、どうつながっていると見ていますか。
OCRBench v2の1位が文書認識の技術力を示した結果だとすれば、ParseBenchの1位は文書構造化の技術力を示した結果だと考えています。
実際の業務において、文書は単なるテキストの集まりではありません。見出し、本文、表、チャート、注釈、画像、数式、印鑑、チェックボックスが一緒に存在し、それぞれに役割があります。企業が求めているのは、これらの要素を業務システムが使えるデータへと変えることです。
たとえば報告書の中の表を見ると、数字だけを抽出しても足りません。その数字がどの行と列に属するのか、どの期間や項目を説明しているのか、表のタイトルやキャプションとどうつながっているのかまで、残っていなければなりません。そうしてはじめて、検索や分析、RAG、AIエージェントの業務に活用できます。
OCRとParserは、互いに異なる技術の軸です。しかし顧客の業務では、自然につながっていきます。文書を正確に認識し、その中の要素を構造化し、意味の単位に分けて、システムが使える形にする、という工程がまとめて必要になるからです。
今回の二度の1位は、韓国ディープラーニングが文書AIで積み重ねてきた技術が、異なる領域で検証された結果だと考えています。
ParseBenchとは、どんな評価なのか
Q. ParseBenchとは、どんなベンチマークなのでしょうか。
ParseBenchは、LlamaIndexが主催するグローバルな文書パーシングのベンチマークです。保険、金融、政府分野の実際の企業文書、約2,000ページをもとに、モデルが文書をどれだけうまく構造化できるかを評価します。
評価項目は、Visual Grounding、Content Faithfulness、Tables、Semantic Formatting、Chartsで構成されています。文書のレイアウトをどれだけよく理解しているか、原文の内容をどれだけ忠実に保っているか、表やチャートの情報を正しく処理しているか、文書の意味的な書式をどれだけ維持しているかを、あわせて見ます。
こうした評価が必要な理由は、近年RAGやAIエージェントにおいて、Parserの役割が大きくなっているからです。AIが文書をもとに回答したり業務を遂行したりするには、まず文書が信頼できる構造化データへと変わっていなければなりません。
文書が誤って構造化されると、その次の段階も一緒に揺らぎます。Embeddingは誤って整理された入力をもとにベクトル化され、VectorDBには不完全な意味の単位が保存されます。検索の段階では見当違いの根拠が返され、生成の段階では誤った根拠をもとに回答が作られてしまうことがあります。
だから文書パーシングは、RAGやエージェントの前段で、非常に重要な役割を担います。後段のモデルをいくら変えても、入力となる文書の整理が誤っていれば、性能改善には限界があります。
「Parserは、テキストを抜き出す道具ではなく、文書を書き直す方式に近いのです」
Q. KDL-Frontier-Parser-nanoの開発で、最も重視した観点は何でしたか。
Parserを、単なる抽出ツールとは見なさない、ということでした。
文書パーシングの結果は、その後のパイプラインの入力になります。文書がParserを経て構造化データになり、そのデータが意味の単位に分けられ、Embeddingを経てVectorDBに保存されます。その次に、検索、リランキング、生成の段階が続きます。
このとき、Parserが文書をどう整理するかによって、後段の性能が変わります。Embeddingモデルは、元の文書を直接見るのではなく、Parserが作り出した結果をもとに動くからです。
だから、Parserの段階ですでに、多くのことが決まってしまいます。
見出しと本文の階層が生きているか、表の行と列の関係が保たれているか、キャプションと画像がつながっているか、作成日や文書タイプといったメタデータが残っているか、意味の単位が自然に分けられているか、といった部分です。
これがきちんとできていなければ、後ろにどんなに良いLLMをつなげても、限界があります。検索のときに文脈が抜けたり、表の意味が崩れたり、古い文書と最新の文書が混ざって出てきたりすることがあります。
私たちはKDL-Frontier-Parser-nanoを開発するとき、文書を単なる文字列に変えるのではなく、AIが再び使える形へと整理することに集中しました。Parserは、テキストを抜き出す道具というより、文書を機械が理解できるように再構成する技術に近いのです。
「良いパーシングは、文書をElement単位で見ることから始まります」
Q. 「文書を構造化する」ということを、もう少し具体的に説明していただけますか。
文書を構造化するというのは、文書を構成する要素を見分け、それぞれの要素の役割と関係を残す作業です。
文書には、大見出し、セクション見出し、本文、リスト、表、キャプション、脚注、画像、チャート、数式、フローチャートといった要素があります。人は文書を見るとき、これらの要素を自然に見分けます。見出しは見出しとして見て、表は表として見て、表の下の説明はその表のキャプションとして理解します。
モデルも、この構造を理解しなければなりません。KDL-Frontier-Parser-nanoは、文書をElement単位で捉えるように設計されています。Title、Section-header、Text、List-item、Caption、Footnote、Table、Picture、Chart、Formula、Flowchartといった要素を見分け、文書の中でどんな役割を果たしているかを把握する方式です。
この構造は、成果物を見栄えよくするための装飾ではありません。その後のChunkingや検索の品質に、直接影響します。
たとえば、見出しと本文がつながった状態で分けられてこそ、検索するときにその文脈が生きてきます。表は、セルの中のテキストだけが残るのではなく、行と列の関係が保たれなければなりません。チャートは、画像としてだけ残るのではなく、その中のデータと説明が一緒に表現されなければなりません。
良いパーシングとは、文書の中の情報をできるだけ失わないことです。文書が持っていた構造を保ってこそ、その次の段階でも使えます。
「Visual Groundingでの1位は、文書パーシングにおいてかなり大きな成果です」
Q. 今回の評価で、Visual Grounding項目の総合1位を記録しました。この結果は、なぜ重要なのでしょうか。
Visual Groundingは、文書の視覚的な構造を理解する能力です。どのテキストがどこに置かれているのか、どの領域に属するのか、どの表や図、キャプションとつながっているのかを把握する能力だと考えればよいでしょう。
文書は、単に上から下へ読む文章ではありません。表、ボックス、多段構成、ヘッダー、フッター、注釈、画像、チャートが、すべて位置と構造を通じて意味を持ちます。
今回の評価で、KDL-Frontier-Parser-nanoはVisual Grounding項目で81.83点を記録し、参加した全モデルの中で1位になりました。総合1位もうれしいことでしたが、私はこの項目で1位を取れた点が、特に意味があると考えています。
Parserがレイアウトをきちんと理解できないと、結果が一見正しく見えても、実際には間違っていることがあります。多段の文書で左と右のカラムが混ざると、文の順序が崩れます。表でヘッダーと値が切り離されると、数字の意味が消えます。キャプションがどの表を説明しているのかを取り違えると、検索の段階で誤った根拠が返されることがあります。
文書の位置と関係をまず理解してこそ、その中の内容を安定的に構造化できます。Visual Groundingは、その土台となる能力です。
「表とチャートは、文書の中核となるデータです」
Q. 詳細項目の中でも、TablesとChartsは重要な評価項目です。実際の開発では、どんな点が難しかったですか。
企業の文書では、表とチャートは付属的な要素ではなく、中核となるデータである場合が多いです。財務報告書、保険書類、公共の行政文書、成果報告書、政策資料を見ると、重要な情報の大部分が表やチャートに入っています。
表で難しいのは、テキストを読むことではなく、関係を保つことです。行と列、結合セル、複数ヘッダー、単位、注釈、キャプションを、あわせて解釈しなければなりません。たとえば「30億」という値があっても、それがどの四半期の営業利益なのか、売上なのか、予算なのかがつながっていなければ、使えるデータにはなりません。
チャートも同じです。チャートは画像のように見えますが、実際にはデータの構造を持っています。軸、凡例、数値、色、ラベル、トレンドが、あわせて意味を作ります。これを単なる画像としてだけ処理すると、情報が失われます。
KDL-Frontier-Parser-nanoは、表とチャートを構造化された形で理解することに集中しました。今回の評価でも、Tables項目で84.56点、Content Faithfulness項目で86.63点を記録しました。
文書パーシングで表やチャートをうまく処理するというのは、見栄えの良いMarkdownやHTMLに変換するレベルにとどまりません。人が業務の中で解釈していた関係を、機械が使えるデータとして残す作業です。
「Chunkingは、文書をただ切り分ける作業ではありません」
Q. Parserは、RAGの性能にどう影響しますか。
RAGを導入するとき、多くの方がまずLLM、Embeddingモデル、VectorDB、リランキングモデルを検討します。もちろん、どれも重要です。しかし、それより前にあるParserを見落とすと、性能が期待どおりに出ないことがあります。
RAGのパイプラインは、たいてい文書、Parser、構造化データ、Chunking、Embedding、VectorDB、検索、Re-ranking、Generationの順に続きます。Parserが文書構造をきちんと保てないと、Chunkingの段階から問題が生じます。
Chunkingは、文書を一定の長さで切る作業ではありません。意味の単位が保たれるように分ける作業です。
一つの条項が二つのChunkに分かれてしまうと、必要な根拠が半分しか検索されないことがあります。逆に、異なる意味の内容が一つのChunkに混ざると、検索の精度が下がります。段落の境界、表のブロック、条項の単位、見出しと本文のつながりが保たれてこそ、検索結果が安定します。
Parserが構造をよく保てば、VectorDBには単なるテキストの断片ではなく、意味の単位のデータが保存されます。そうすると、検索の段階で必要な根拠をより正確に引き出せますし、LLMが回答を作るときも、根拠が揺らぎにくくなります。
私たちがParserを、RAGの前段の付加機能のようには見なさない理由が、ここにあります。Parserは、RAGの精度を左右する前段のインフラに近いものです。
「メタデータは、検索の品質を左右します」
Q. 文書パーシングでは、メタデータも重視されますか。
はい。企業の文書では、答えが本文のテキストの中だけにあるわけではない場合が多いのです。
同じ規定文書でも、バージョンが違えば答えが変わることがあります。同じタイトルの報告書でも、作成日が最新か、どの部署の文書か、どの文書タイプかによって、検索の優先順位が変わらなければなりません。契約書や政策文書では、日付、バージョン、文書タイプ、作成主体といった情報が、とても重要です。
こうした情報がParserの段階で残らないと、リランキングは単なる類似度に頼ることになります。似た文書を見つけることと、今の質問に合う文書を見つけることは、別のことです。
KDL-Frontier-Parser-nanoを開発するときも、本文だけでなく、文書が持つ周辺の手がかりをどう保つかを重視しました。見出し、セクション、ページ、キャプション、表、作成日、文書タイプといった情報が、検索やリランキングで活用できなければなりません。
企業向けの文書AIでは、「何が書かれているか」だけでなく、「その情報がどこにあり、どの文書のどんな文脈に属するのか」もあわせて残っていなければなりません。メタデータは、その文脈を保つための仕掛けです。
「1.2Bというサイズは、運用の実現可能性につながります」
Q. もう一度モデルのサイズの話に戻ると、1.2Bモデルであることは、顧客の環境ではどんな意味を持ちますか。
企業向けAIにおいて、モデルのサイズは単なるスペックではありません。運用できるかどうかに、直接つながります。
モデルが大きすぎると、コストが膨らみ、応答速度が遅くなり、展開できる環境も限られます。特に金融、保険、公共機関のようにセキュリティ要件の高い顧客は、外部のAPIに機密文書を送るのが難しい場合が多いです。社内ネットワークや閉域網、オンプレミス環境で自ら運用しなければならない状況もあります。
KDL-Frontier-Parser-nanoは、1.2B規模の超軽量モデルです。GPU1枚でも動かせるレベルを目標にし、オープンウェイトで公開されているため、顧客の環境に合わせて自ら検討し、展開できます。
良いモデルは、ベンチマークの中でだけ優れていてはいけません。実際の顧客の環境で動かなければなりません。文書が多くても処理速度を確保しなければならず、セキュリティ方針に沿って運用され、システム連携まで可能でなければなりません。
小さなモデルで高い文書パーシング性能を出せるなら、企業や機関が文書AIを導入するときの負担も減ります。
「オープンウェイトでの公開は、自信の表れでもあり、必要な選択でもありました」
Q. KDL-Frontier-Parser-nanoは、オープンウェイトで公開されました。どんな意味があるのでしょうか。
企業向けの文書AIでは、信頼が重要です。特に金融、保険、公共の分野では、どのモデルがどう動くのか、内部の環境に直接展開できるのか、外部のサーバーに文書を送らなくて済むのかが重要になります。
商用APIは便利ですが、すべての顧客に合うわけではありません。機密文書を扱う組織は、データを外部に送ること自体が負担になり得ます。この場合、顧客が自らモデルを検討し、内部のインフラに合わせて展開し、セキュリティ方針に沿って運用できなければなりません。
オープンウェイトのモデルは、こうした環境でより柔軟です。研究者や顧客が自ら性能を確認でき、必要な環境に合わせて実験したり、適用の可能性を検討したりできます。
私たちの立場からすれば、自信の表れでもありました。小さなモデルでも文書パーシングに特化した性能を示せますし、グローバルなベンチマークでも検証されたからこそ、公開できたのです。
同時に、必要な選択でもありました。文書AIがより多くの企業環境で使われるには、重くて閉じたモデルだけでは限界があります。より軽く、検証でき、展開しやすいモデルが必要です。
「文書パーシングで最も難しいのは、人が当たり前に見ている構造を、モデルにも理解させることです」
Q. 開発の過程で、最も難しかった部分は何でしたか。
人は文書を見ると、構造を自然に理解します。見出しと本文を見分け、表のヘッダーと値をつなぎ、キャプションがどの図を説明しているかを把握します。多段の文書でも、読む順序を自然につかみます。
しかしモデルにとっては、これらすべてが学習しなければならない情報です。文書の中の位置、間隔、線、ボックス、文字の大きさ、太さ、余白、ページの流れが、すべて手がかりになります。このうち一つを見落とすだけでも、構造が狂うことがあります。
実際の企業文書は、もっと難しいものです。PDFも多く、スキャン品質の低い文書もあり、表の中に表が入っていたり、セルが結合されていたりする場合もあります。公共文書のようにページが長く、ヘッダー、フッター、脚注が多い文書もあります。報告書には、表とチャート、画像が一緒に混ざっています。
だから最も難しかったのは、さまざまな文書でも構造を安定的に保つことでした。特定のサンプルにだけよく合うモデルではなく、初めて見る文書でもElementを見分け、関係を保つモデルを作ることが重要でした。
文書パーシングのモデルは、見えている情報を順に並べるだけで終わってはいけません。人が文書を見て自然に理解する構造を、できるだけ残さなければなりません。
「良いParserモデルは、RAGやAgentまで見据えて設計されなければなりません」
Q. 顧客企業の立場からは、今回の成果をどう受け止めればよいでしょうか。
顧客企業の立場から重要な問いは、「このモデルが、自社の文書業務にどんな変化を生み出せるのか」だと考えます。
文書パーシングの結果は、単独で終わりません。ERP、EDMS、RPA、RAG、LLM、AI Agentとつながります。だからパーシングの結果は、人が見て見栄えの良い出力物ではなく、システムがそのまま活用できる構造化データでなければなりません。
KDL-Frontier-Parser-nanoの強みは、文書の構造を保ち、意味の単位で活用できるデータを作る点です。表は表として、チャートはチャートとして、見出しと本文は階層を保った状態で、キャプションと本文はつながった状態で表現されなければなりません。そうしてこそ、検索や質問応答、業務自動化までつながっていきます。
特にRAGやAIエージェントを導入しようとする顧客にとって、Parserはより重要です。RAGで回答が揺らぐ原因は、LLMではなく、入力データの構造であることが多いのです。文書が誤って分解されてVectorDBに入ると、検索結果も揺らぎ、回答も揺らぎます。
良いParserは、このボトルネックを前段で減らします。意味の単位で文書を分け、必要なメタデータを付け、表とチャートの関係を保つことで、AIが信頼できる根拠を見つけられるよう助けます。
今回のParseBench1位は、韓国ディープラーニングの文書パーシング技術が、実際の企業向けAIパイプラインでも十分に競争力を持って使えることを示しています。
Ginnieが考える「良いAIエンジニア」
Q. AIエンジニアとして、最も大切にしている姿勢は何ですか。
問題を最後まで構造的に見る姿勢だと思います。
文書AIでは、小さなエラーのように見えても、実際の業務では大きな問題になり得ます。表のセル一つが誤ってつながったり、項目と値が入れ替わったり、チャートの数値を誤って抽出したりすると、後続の業務全体が影響を受けることがあります。
だから開発者は、モデルのスコアだけを見てはいけません。どんなエラーがなぜ起きたのか、そのエラーがその後の検索、リランキング、生成、システム入力の段階で、どんな問題を引き起こし得るのかまで見なければなりません。
もう一つは、効率をずっと考え続ける姿勢です。AIモデルはどんどん大きくなっていますが、実際の顧客環境では、とにかく大きなモデルを使う、というわけにはいきません。コスト、速度、セキュリティ、展開環境を、あわせて考えなければなりません。
私は、良いAIエンジニアとは、性能と現実のあいだのバランスを見られる人だと思います。研究として良いモデルを作ることも重要ですが、顧客が実際に使えるモデルを作ることも、それと同じくらい重要です。
KDL-Frontier-Parser-nanoも、そうした観点から開発しました。グローバルなベンチマークで性能を証明すると同時に、実際の企業環境で動かせるモデルでなければならないと考えました。
「文書AIの次の課題は、より小さく、より正確に、より簡単につながることです」
Q. これからGinnieさんと韓国ディープラーニングの開発チームが集中したい方向は、何でしょうか。
精度は、これからも高め続けなければなりません。文書パーシングには、まだ難しい問題が多くあります。表、チャート、複雑なレイアウト、さまざまな文書の書式、低品質のスキャンなど、解決すべき課題が今も残っています。
しかし、精度と同じくらい、効率と連携も重要です。より小さなモデルでより良い性能を出し、より少ないリソースでより速く処理し、さまざまな顧客環境に簡単に展開できなければなりません。
もう一つは、パーシングの結果を、実際の業務システムとよりよくつなげることです。Parserの結果がJSON、Markdown、HTMLといった構造化された形式で提供され、その後ERP、EDMS、Agent、RAG、LLMのパイプラインと自然につながっていかなければなりません。
企業や機関は、環境がそれぞれ異なります。あるところはクラウドを使え、あるところはオンプレミスが必要で、あるところは閉域網の環境でしか運用できません。文書AIが実際に普及するには、こうした環境に合わせて柔軟に適用できなければなりません。
KDL-Frontier-Parser-nanoは、その方向への出発点だと考えています。小さなモデルですが、文書パーシングに特化した性能を示し、オープンウェイトで公開されて、さまざまな環境で活用の可能性を確かめることができます。
これからは、より正確で、より軽く、より簡単に業務システムにつながる文書AIを作ることに、集中していきたいです。
文書をパーシングするAIから、エージェントが信頼できるデータへ
ParseBench VLM部門の1位は、韓国ディープラーニングにとって重要な成果だ。特に1.2Bの超軽量モデルで、Google GeminiやOpenAI GPT-5.5といったグローバルな商用モデルを上回った点で、意味が大きい。
しかしGinnieは、インタビューを通じて「大きなモデルに勝った」という言葉よりも、「実際の業務で使えるモデル」や「信頼できる構造化データ」について、より多く語った。
文書AIの競争は、より精緻になっている。企業や機関は、文書を単に処理する技術を超えて、文書の中の構造と文脈を正確に理解し、業務システムにつなげられる技術を必要としている。
AIエージェントが実際の業務を遂行するには、文書を信頼できなければならない。契約書の条件、請求書の金額、公文書の項目、報告書の表とチャートが、正確な構造へと変換されなければならない。そうしてはじめて、AIはその情報をもとに次の行動を取ることができる。
RAGもまた同じだ。検索の品質は、LLMだけで決まるものではない。Parserが文書をどう表現し、どんな意味の単位に分け、どんなメタデータを残すかが、VectorDBや検索、リランキング、生成の品質に影響を与える。
韓国ディープラーニングが集中する方向も、ここにある。
文書を単なるテキストに変えるのではなく、業務に使えるデータへと構造化すること。大きなモデルだけに頼るのではなく、実際に展開できる小さなモデルで高い性能を出すこと。顧客のセキュリティ環境や運用条件のなかでも、安定的に動く文書AIを作ること。
Ginnieは最後に、こう語った。
文書パーシングのモデルは、結局のところ、人が手直しをしなくて済むほど正確な構造を作らなければなりません。モデルが大きく複雑に見えることよりも、顧客の環境で安定的に動き、実際の業務にそのまま使える結果を出すことのほうが重要です。私たちが作りたいのは、そういうモデルです。
ParseBenchでのグローバル1位は、その方向を示す一つの結果だ。
そしてこの結果は、韓国ディープラーニングが文書AIをどこまで広げていけるのかを示す、もう一つの出発点でもある。
