liteparse

LiteParse

高速でモデル不要のパーサーである lit CLI を使って、ドキュメントからローカルでテキストを抽出します。このスキルでは、低コストで使う方法を扱います。lit parse を実行するたびに抽出がすべてやり直され、会話に出力した各行のコストは、その後のターンごとに発生します。以下のパターンは、同じ PDF を最大 9 回解析し、画像を 1 枚読み取るだけでコンテキストを14 万文字以上消費した実際のエージェントトレースを分析して得られたものです。同じ失敗を繰り返さないでください。

鉄則：ファイルに一度だけ解析し、その後はファイルを検索する

lit parse は呼び出すたびにドキュメント全体を再抽出します。検索のたびに再解析するのは、トレースで確認された無駄の第 1 位です。ドキュメントは一時ファイルに一度だけ解析し、そのファイルを対象にすべての検索を実行します。

# ONE TIME, per document. --no-ocr for born-digital PDFs (almost all reports) — much faster.
lit parse "/abs/path/doc.pdf" --format text --no-ocr -o /tmp/doc.txt && wc -l /tmp/doc.txt

その後は安価なシェルツールでファイルを検索してください。検索のために lit parse を再実行することは絶対に避けてください。

検索の心得 — 往復回数を最小限にしてから、結果を絞り込む

Bash を呼び出すたびに、モデルとの往復が丸ごと発生します（レイテンシーとコンテキストの再読み込み）。解析後の最大の無駄は、逐次的なループです。grep → 確認 → 再度 grep → 範囲を読むために sed → 再度 grep、という流れです。トレースでは、この方法はドキュメントを読むだけの場合と比べてターン数が倍増していました。次の 2 つのルールで防げます。

1. 同じコマンドで周辺情報も取得する — grep の後に sed を使わない。 grep -C を使うと、該当箇所とともに周辺の行も取得できます。一般的なケースで、後から sed を使うターンを省けます。

grep -n -i -C4 "total assets" /tmp/doc.txt | head -40      # location AND its window, one turn

-C で取得した範囲よりも広い範囲が必要で、正確な行番号がすでに分かっている場合に限り、sed -n 'A,Bp' を使います。

2. 関連する検索を 1 つのコマンドにまとめる。 質問でいくつかの異なる事実（たとえば、排出量と売上高）が必要な場合、用語ごとに 1 ターン使わないでください。ラベルを付けてまとめて検索します。

for q in "carbon intensity" "scope 1" "total revenue"; do \
  echo "=== $q ==="; grep -n -i -C3 "$q" /tmp/doc.txt | head -25; done

その後、結果を絞り込みます。

• 出力には必ず head を使って上限を設け、行番号には -n を指定します。
• 無計画に検索を広げないでください。 1 つの質問は 3 回以下の検索コマンドで解決することを目指します。対象を絞った grep を 2 回使っても特定できない場合は、キーワードを 1 ターンずつ変えて検索し続けず、以下の search.py に切り替えてください。
• Read と Grep のツールよりも、保存したファイルに対する Bash の grep／sed を優先してください。往復回数を減らせ、出力サイズも正確に制御できます。

キーワードが定まらない場合のランク付け検索（同梱ヘルパー）

対象を絞った grep を 2 回使っても答えを特定できない場合は、grep を続けないでください。キーワードを 1 ターンずつ変えて繰り返すのではなく、同梱の BM25 ランカーを 1 回実行し、関連性の高い行の範囲を 1 つのコマンドでまとめて取得します。

scripts/search.py /tmp/doc.txt -q "materiality assessment priority topics" -k 8 -e 5

-k は一致件数、-e は前後のコンテキスト行数です（範囲がインラインで取得されるため、後から sed を使うターンは必要ありません）。行番号付きの範囲が関連度順に返されます。キーワードを 1 つだけ指定するのではなく、複数の類義語を含む、情報量の多い自然言語のクエリを使ってください。これにより、推測に基づく grep を長々と繰り返す必要がなくなります。

デジタル文書とスキャン文書

• デジタル文書の PDF（実際のテキストレイヤーを持つもの。企業・金融・ESG レポートのほとんどが該当）：必ず --no-ocr を指定してください。はるかに高速で、テキストも同じです。OCR を有効にしたままにすると時間を無駄にします。
• スキャン PDF／画像：--no-ocr を外してください。値が欠けていたり、数字が正しくないように見えたりする場合は、OCR を信用せず、下記の手順でページを視覚的に確認してください。

ページを視覚的に読む — 最終手段として、スクリーンショット 1 枚、控えめな DPI で

スクリーンショットは、コンテキストを消費するデータの中でも特にコストが高いものです。あるトレースでは、高 DPI のページ PNG 1 枚で約 14 万文字を消費し、エージェントが同じページを 2 回（標準解像度と高解像度で）レンダリングすることもよくありました。

テキストや表だけでは質問に答えられない場合（複数列の複雑な表、図、グラフなど）に限り、スクリーンショットを撮ります。その場合は次の点に従ってください。

• --target-pages "N" を使い、一度に 1 ページだけレンダリングします（--pages ではなく --target-pages なので注意してください）。
• **控えめな DPI（約 150～200）**を使います。最初から 300 以上にしないでください。テキストが実際に判読できない場合を除き、同じページをより高い DPI で再レンダリングしないでください。

lit screenshot "/abs/path/doc.pdf" --target-pages "13" --dpi 150 -o /tmp/shots/   # then Read the PNG

同じドキュメントについて多くの質問がある場合

一度ファイルに解析しておけば、これで対応できます。再解析する代わりに、/tmp/doc.txt を保持して、すべての質問で再利用してください。

前置きでターンを無駄にしない

lit --version、ls -la、lit … --help は、実際に失敗した場合を除いて実行しないでください。すぐに解析に進みます。必要な基本フラグは次のとおりです。

--format text|json · --no-ocr · --target-pages "1-5,10" · --dpi <n>（デフォルトは150）· --ocr-language <iso>。バウンディングボックスやレイアウトが必要な場合のみ --format json を使ってください。ファイルサイズがかなり大きくなります。全体を読み込まず、検索してください。

セットアップ

PDFはそのまま使用できます。lit がない場合は、npm i -g @llamaindex/liteparse を実行してください。Office文書にはLibreOffice、画像にはImageMagickが必要です（どちらもPDFに自動変換されます）。