OCR誤読をLLMが自動補正する——ナレッジグラフRAGパイプライン完成事例
Hiroba による自動要約
Document Intelligence の OCR 結果を既存のナレッジグラフ構築パイプラインに接続する変換層を実装し、紙PDFから回答生成まで一気通貫した処理フロー (PDF→OCR→ナレッジグラフ→検索→回答) を完成させた。OCR誤読(「O」を「〇」と誤認識)を人手補正せず下流に流したところ、LLM のエンティティ抽出段階で「Oリング」等として自動補正され、最終的な回答精度に影響しなかった。API フィールド（result.content vs tables/paragraphs）によって「見える誤り」が異なることも実測。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 4142 件あります。
関連する記事
同じタグの記事
Claude Code の消費量を調査したら、セッション放置が原因で1日384ドル使っていた
Qiita著者が Claude Code Opus の利用制限に毎日引っかかるため、30日間のセッションログを分析したところ、1日平均 $384（公式目安の約30倍）を消費していた。内訳は入力の97.5%がキャッシュ読み込みで、セッションを閉じずに放置することが主原因だった。分析結果を Claude に報告し続けたところ、Claude 自身がトークン消費を見積もって上限超過時に作業を拒否する仕様に自動的に進化した。
Claude Code v2.1.265/266で判明したLLMゲートウェイ全滅バグと主要変更点
QiitaClaude Code v2.1.265で混入したリグレッションにより、LLMゲートウェイ/プロキシ経由でAPIキーや認証ヘッダーを使う構成が全リクエスト失敗する問題が発生し、翌日の v2.1.266 で即時修正された。CLAUDE_CODE_USE_GATEWAY 単独設定でゲートウェイサインインが強制される仕様変化が原因で、影響を受ける環境は v2.1.266 へのバージョンアップで対応可能。同時に --plugin-dir によるプラグイン一括読み込みやプロンプトキャッシュ修正など約50件の更新が含まれる。
Claude Code v2.1.266〜v2.1.267 | maxEffortLevel で effort の上限を設定可能に | 毎日Changelog解説
QiitaClaude Code v2.1.267 で settings に maxEffortLevel が追加され、Bedrock・Vertex・Foundry を含む全プロバイダで effort の上限を一元管理できるようになった。同版では prompt cache とツール定義の書き換えによる問題を解決し、--system-prompt-snapshot off フラグで毎リクエスト system prompt を再描画できるようになった。v2.1.266 は v2.1.265 の CLAUDE_CODE_USE_GATEWAY 関連の回帰を修正。
Claude API の Files API で同じ PDF・画像の Base64 送信を削減する実装手順——beta ヘッダー 2 箇所・再ダウンロード不可など 3 つのハマりどころ
QiitaClaude API の Files API を使うと、PDF や画像を一度アップロードして file_id で参照でき、毎回 Base64 エンコードする手間とリクエスト容量を削減できる。実装は client.beta.files.upload() でアップロード後、Messages API 呼び出し時に file_id を参照するだけだが、beta ヘッダーは アップロード・Messages 両方に必要、content block の型と MIME タイプを一致させる、アップロード済みファイルは再ダウンロード不可という 3 つの落とし穴がある。