AWS

執筆者：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）である」**という視覚的コンテキストを明示的に提供しました。この簡単な指示だけでモデルは視覚的レイアウト内での重要度を把握するようになり、複雑にデザインされた製品名もテキストとして正確に抽出し始めました。 ...