RAG

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件のエラーが発生しました： ...

(株)慶農ファーミングノート高度化プロジェクト — 農薬製品の写真1枚で製品情報を自動検索するAIシステムの設計と実装過程を共有します。 プロジェクト背景 慶農は以前、AWS、メガゾーンクラウドと共に生成型AI基盤の農業専門チャットボットを構築していました。Amazon Bedrock Claude Sonnet 3.5とOpenSearchを活用したRAGアーキテクチャで、農業者が自然言語で質問すると作物保護剤情報を自動で応答するサービスでした。 このチャットボットを運営する中、慶農から現場の意味のあるフィードバックと新しい提案を受けました。高齢の農業者が多い現場特性上、スマートフォンで長くて馴染みのない農薬製品名を直接タイピングするのは非常に煩わしいという点でした。 「現場でスマートフォンで製品を撮影するだけで情報をすぐに見つけられないか？」 — お客様のこのような悩みを基に、テキスト入力を超えた視覚的検索システムを構築する高度化プロジェクトが始まりました。 問題は単純ではありませんでした。現場で撮った写真はぼやけていたり回転していたりし、韓国語・数字・特殊文字が混在したラベルからVision LLMがテキストを完璧に読み取るのは困難です。約4,000種の類似した製品名の中から「バテスダ」が「バテスタ」の誤認識なのか全く別の製品なのかを区別する必要があります。そのためOCRが間違っても製品を見つけるシステムを作る必要がありました。 システムアーキテクチャ システムアーキテクチャ — AWSマネージドサービス連携 ユーザーが農薬製品画像をアップロードすると、システムは3段階を順次実行します。各段階は前段階の不完全さを補完するよう設計されています。 Stage 1 — Vision LLMがラベルを読み（製品名、登録番号、製造社抽出） TypoCorrectorがOCRタイポを補正 Stage 2 — OpenSearchが階層的フォールバックで候補群を検索 （完全一致から部分マッチングまで1回のクエリで） Stage 3 — LLM Rerankerが元の画像を再度見て最終順位を決定 この記事の残りの部分では各段階を詳細に扱います。 OCRが間違っても製品を見つける方法 Vision LLM：ラベルから情報抽出 画像からテキストを抽出するのは一般的なOCRとは異なります。単にテキストを読むのではなく、「農薬製品ラベル」というドメイン知識を基に構造化された情報を抽出する必要があります。 圧縮JSON戦略 Vision LLMの応答速度を最適化するため、出力トークンを最小化する圧縮JSONフォーマットを設計しました： LLMが返す圧縮形式： {"s":"C","n":"バテスタ","g":"46-除草-546","m":"ファームハンノン","i":"メトラクロル粒剤","c":{"n":0.95,"g":0.9,"m":0.9,"i":0.85}} サーバーで標準形式に変換： { "status": "CLEAR", "product_name": "バテスタ", "registration_number": "46-除草-546", "manufacturer": "ファームハンノン", "ingredient_name": "メトラクロル粒剤", "confidence": { "product_name": 0.95, "registration_number": 0.9, "manufacturer": 0.9, "ingredient_name": 0.85 } } max_tokens: 500、temperature: 0.0に設定して決定論的で簡潔な出力を誘導します。すべてのフィールドに0.0〜1.0の信頼度を一緒に返してもらい、後続処理を動的に調整します。信頼度が中間水準のフィールドにはタイポ補正を試み、補正後も信頼度が低いフィールドは検索クエリから除外して誤検索を防ぎます。 プロンプトによるデザインテキスト認識克服 農薬製品名は注目度を高めるため華やかなカリグラフィや独特なタイポグラフィでデザインされることが多いです。初期テストではVision LLMがこれらのデザインされた文字をテキストではなく絵として誤認する場合がありました。私たちはプロンプトに**「製品名はラベルで最も大きく目立つテキスト（largest text）である」**という視覚的コンテキストを明示的に提供しました。この簡単な指示だけでモデルは視覚的レイアウト内での重要度を把握するようになり、複雑にデザインされた製品名もテキストとして正確に抽出し始めました。 ...

1. 評価概要 目的： 韓国語法令および条例検索（RAG）システムに最適化された埋め込みモデルの選定 評価データセット KCL-MCQA（韓国正準法律ベンチマーク） 282個の質問、867個の判例（エキスパートタグ付けGround Truth） データ選定の理由 現在、韓国語法令・条例の公開ベンチマークデータセットが存在しない KCL-MCQAは法律ドメインで検証された唯一の韓国語検索評価データセット 判例と法令・条例は同一の法律用語および文体を共有し、同様の埋め込み性能を期待可能 将来、法令・条例専用評価データセット構築時の再評価を推奨 評価環境 検索エンジン：PostgreSQL pgvector with HNSW index 評価指標：Recall@5、Precision@5、MRR、NDCG@5 2. 比較モデル モデル プロバイダ 次元 特徴 Amazon Titan V2 AWS Bedrock 1024 AWS ネイティブ、低コスト Cohere Embed V4 AWS Bedrock 1536 多言語特化、高性能 KURE-v1 HuggingFace（SageMaker提供が必要） 1024 韓国語特化オープンソース 3. 評価指標の説明 Recall@K（再現率）⭐⭐⭐ 定義： 実際の関連文書のうち、上位K件の結果に含まれる割合 計算式： （上位K件で見つかった関連文書数）/（すべての関連文書数） 解釈 値が高いほど、関連文書を漏れなく検出 法律検索で最も重要な指標（漏れ防止） 例： 関連判例が5件あるが、上位5件結果に3件含まれる場合 → Recall@5 = 60% Precision@K（適合率）⭐ 定義： 上位K件結果のうち、実際の関連文書の割合 計算式： （上位K件で見つかった関連文書数）/ K 解釈 値が高いほど、検索結果に不要な文書が少ない ユーザーが確認すべき文書数を削減 例： 上位5件結果のうち3件が実際の関連文書 → Precision@5 = 60% ...