Claude

TL;DR: LLMには「どこからどこまで」だけを聞き、テキストはサーバーが直接取り出せばよいのです。3ページの実測値でOutputトークン90%削減、レイテンシ87%削減、コスト61%削減。 背景：DoclingからPyMuPDF + VLMへ 建築法規審査AIを開発する中で、建築告示・指針PDFを意味単位のチャンク（chunk）に分割する必要がありました。RAGパイプラインの検索単位として使用するためです。 当初はIBMのDoclingを使用していました。OCRモデルで文書構造を把握してからチャンキングする方式ですが、2つの課題がありました。 処理が重い：OCR・レイアウト分析モデル（RT-DETRなど）が含まれており、Dockerイメージサイズと処理時間が大きい カスタマイズが困難：内部パイプラインがブラックボックスに近く、建築文書特有の階層構造（章 > 条 > 項 > 号）や表の処理をきめ細かく制御しにくい そこでOCRモデルを排除し、PyMuPDFでテキストとフォントメタデータを直接抽出する方式に切り替えました。構造分析はマルチモーダルLLM（VLM）のVision機能で代替すれば、OCR依存を完全に排除しながらも自由にカスタマイズできます。 PDF → PyMuPDF テキスト抽出 → ページ分類 → LLM 構造分析 → チャンク生成 → エンベディング 以下は実際の処理対象である建築告示PDF — 大邱法院総合庁舎設計公募指針書の本文3ページです。 3ページ 4ページ 5ページ 「1. 公募の目的」「2. 事業の概要（가〜마）」「3. 公募要綱（가〜마）」など、階層的なセクション構造を持つ本文です。これをLLMが意味単位で自動分割するのが目標ですが、ここで新たな課題が発生しました。 課題：LLM Outputトークンのコスト LLM APIではOutputトークンの単価はInputの3〜5倍です。 モデル Input (/1M tokens) Output (/1M tokens) 倍率 Claude Haiku 4.5 $1.00 $5.00 5x Claude Sonnet 4.6 $3.00 $15.00 5x 最もシンプルなアプローチは、LLMに分割されたセクションの内容をそのまま再出力させることです。 ...

執筆者：Kim Bo-geun 建築法規レビューAIで「4階以下」と「4階以上」を混同するとどうなるか。高さ上限が逆転し、違法建築が合法と判定される。この記事は、その一文字の違いを捕まえるための取り組みの記録です。 問題：PDF表は検索されるが信頼できない 建築法規レビューシステムは、地区単位計画告示や設計指針書などの建築関連PDFを分析し、建ぺい率、容積率、高さ制限などの基準を抽出します。PDF前処理パイプラインではDoclingを使用して文書をパースし、テキストをチャンキングした後、エンベディングを生成してハイブリッド検索（キーワード＋セマンティック）を実現しています。 DoclingのHierarchicalChunkerは表の内容もMarkdown形式でチャンキングし、検索インデックスに含めます。表が完全に欠落するわけではありません。問題はそのMarkdownの品質でした。 結合セル構造が壊れ、「建ぺい率60%」がどの街区番号に該当するかの関係が失われる OCRエラー（「以下」→「以上」、「커」→「키」）がそのまま検索結果に表示される エージェントが「街区1 建ぺい率」で検索してチャンクを見つけても、その値が正しいか信頼できない 地区単位計画告示の建ぺい率・容積率・高さ基準は、ほとんどが複合表に存在するため、これは致命的な問題でした。 テスト対象：大邱蓮湖公共住宅地区 地区計画告示 テストに使用したPDFは「国土交通部告示第2024-598号」（54ページ）で、Doclingが抽出した表は合計109個、全54ページに分布しています。 以下は核心となる表を含む36ページの実際のPDF画像です： 図1. 告示PDF 36ページ — 街区別建ぺい率/容積率/高さ基準表。結合セルが複雑に絡み合っている。 Docling Markdownの限界 DoclingはPDFの表を2Dグリッド（行×列配列）とMarkdownで抽出します。単純な表では問題なく動作しますが、建築告示PDFの複合表では結合セルの関係が失われ、韓国語OCRエラー（「커」→「키」）が発生し、どの値がどの街区に該当するかの関係が不明確になります。 アプローチ：Vision＋OCRハイブリッド なぜVisionなのか LLMのVision機能は画像を直接見て解釈します。PDFページを画像としてレンダリングすれば、人間が表を読むのと同じ方法で結合セルの視覚的な境界を認識し、行と列間の論理的関係を把握して、構造化JSONとして出力できます。 しかし、Visionだけでは不十分でした。 Vision単体の限界：体系的エラー Bedrock Claude Haiku 4.5でVision単体テストを実施したところ、高さと容積率フィールドで体系的な「以下」→「以上」エラーが発生しました。 36ページの実際のVision単体結果（エラー部分抜粋）： { "区分": "공1, 공2", "建ぺい率": "60%以下", "容積率": "400%以下", "高さ": "20階以上" // ← 原文: "20階以下" }, { "区分": "공3, 공4", "建ぺい率": "60%以下", "容積率": "400%以下", "高さ": "10階以上" // ← 原文: "10階以下" }, { "区分": "초1", "建ぺい率": "60%以下", "容積率": "200%以下", "高さ": "5階以上" // ← 原文: "5階以下" }, { "区分": "키1 ~ 키2", // ← 原文: "커1, 커2" "建ぺい率": "60%以下", "容積率": "400%以下", "高さ": "8階以上" // ← 原文: "8階以下" } 37ページでも容積率1件のエラーが発生しました： ...