研究報告書を社内審査に出す前に、データ表・グラフの数値と本文の数値・単位・有効数字の食い違いを点検する

処理の起点を決める

起点は、提出用のフォルダに報告書のPDFが保存されたことです。 研究員が提出したその場で点検を動かし、審査担当が読み始める前に指摘の一覧ができている状態にします。

審査会の前日にまとめて動かすことはしません。 指摘が審査会の直前に出ると、研究員が直す時間が残りません。提出のたびに1本ずつ点検し、結果を研究員本人にも同時に返します。 研究員が自分で直してから再提出できれば、審査担当の手に渡る前に片付く指摘が増えます。

再提出の版も、同じ点検を最初から通します。 指摘した箇所だけを見直すと、直したときに別の箇所の数値を書き換えてしまった誤りを見逃します。

入力データを集める

質を決めるのは、記載規程を表にできるかです。 「本文では有効数字を表に合わせる」「丸めは四捨五入」「『約』を付けたら上位2桁まで一致すればよい」といった規則が、文章で書かれた規程のままでは Python で判定できません。 規則を1行ずつの表にします。

3行目は、規程によって扱いが分かれる行です。 桁を増やして書くのを誤りとするか、許すかは研究所ごとに違います。この表を研究企画グループが決めることが、最初の作業です。

データの取得方法を決める

PDFは Gemini API に直接渡します。 30ページ程度なら、呼び出しの中にそのまま入れられます。何度か呼び出しを分けて同じPDFを読む場合は、ファイルを先にアップロードしておく方法があり、アップロードしたファイルは48時間保存されるとされています。

呼び出しは、拾うものごとに3回に分けます。

3回に分けるのは、拾い漏れを減らすためです。 1回で全部を拾わせると、表のセルを拾うのに集中して本文の数値を飛ばしたり、その逆が起きたりします。拾うものを1種類に絞ると、それぞれの拾い方の指示を細かく書けます。

値は文字列のまま受け取ります。 「12.30」を数値にすると「12.3」になり、有効数字の情報が消えます。 桁の判定は Python が文字列から行います。表の側も同じで、元のスプレッドシートの表示形式で桁が落ちたまま貼られていることがあります。比べる対象は、PDFに表示されている文字列です。

AIへ渡す前に整形する

1. PDFであることを確かめる … ワープロ文書で提出されたものはPDFに変換します
2. ページ数とサイズを確かめる … 50MBまたは1,000ページの上限を超えるものは分けます
3. テキストの有無を確かめる … スキャンして作られたPDFは、本文の数値の読み違いが増えるので、指摘の一覧にその旨を付けます
4. ページの向きを直す … 横向きの大きな表が回転したまま入っていれば、正しい向きにします
5. 表番号と図番号の付け方を確かめる … 「表3」「Table 3」「表 3-1」などの書き方をそろえる規則を Python に持たせます
6. 付録を分ける … 付録の生データの表は、本文から参照されている表だけを点検の対象にします

4番目は、公式のドキュメントでも勧められています。 ページを正しい向きに回転させてから渡し、ぼやけたページを避けるよう案内されています。研究報告書の大きな表は横向きのページに入っていることが多く、向きが違うまま渡すと行と列を取り違えます。

6番目を省くと、指摘の一覧が埋まります。 付録の生データの表には数百のセルがあり、本文から参照されないものがほとんどです。本文と突き合わせる意味があるのは、本文が参照している表だけです。

AIに処理させる

させるのは、数値を拾うことと、その数値がどの表のどのセルを指しているかを結び付けることだけです。 比べることはさせません。

真ん中の列の「参照先を結び付ける」が、この構成で最も難しい部分です。 本文には「表3に示すとおり」と書かれていることもあれば、「試料Bの引張強さは12.8 MPaであった」とだけ書かれていることもあります。後者は、どの表の、どの行と列かを、試料名と量の名前から探す必要があります。 これは生成AIに向いた作業で、規則だけでは書けません。

3行目が、最も起きやすい失敗です。 本文の「約45％」をグラフの棒の高さから「44％くらい」と読み、一致と判定してしまうことがあります。グラフからは軸の単位と増減の向きだけを取り、値は取らせません。 本文がグラフだけを根拠に数値を書いている場合は、その数値は「グラフのみ」として審査担当に回します。

指示内容を固定する

2回目（本文の数値）の指示の例です。

あなたは研究報告書の社内審査の事務局で、本文に書かれた数値を拾う担当です。
添付のPDFの本文から、数値をすべて拾い、指定のJSONで返してください。
数値が正しいかどうか、表と合っているかどうかは判断しないでください。

【拾う対象】
- 本文の文章に書かれた数値（測定値、条件、増減率、試料の数、範囲）
- 表のセルの中の数値と、図の中の数値は、この回では拾わないでください。
- 図番号・表番号・章番号・参考文献の番号・年は拾わないでください。

【拾い方】
- value には、書かれた文字列をそのまま入れてください。
  「12.30」を「12.3」に、「1.2×10³」を「1200」に直さないでください。
- unit には、数値の直後に書かれた単位をそのまま入れてください。
  書かれていなければ空にしてください。前後の文から推測しないでください。
- qualifier には「約」「以上」「未満」「〜」「±」などの修飾をそのまま入れてください。
- 範囲（10〜20）と誤差（12.3±0.4）は、1つの数値として拾い、
  value に書かれたとおりに入れてください。

【参照先】
- その数値が、どの表のどの行・列の値を書いたものかを ref に入れてください。
  本文に表番号が書かれていなくても、試料名・条件・量の名前から
  対応する表のセルが1つに決まる場合は、ref に入れてください。
- 図のグラフを根拠に書かれた数値は、ref に図番号だけを入れてください。
- 対応する表のセルが1つに決まらない場合は、ref を空にし、
  candidates に候補を最大3つ入れてください。推測で1つに決めないでください。

【増減の記述】
- 「向上」「低下」「増加」「減少」「倍」などがあれば、
  比べている2つの条件（例：試料Aと試料B、処理前と処理後）を compare に入れてください。
- 増減率を計算しないでください。

【報告書】{pdf}
【表の一覧（1回目の結果）】{tables}

「書かれた文字列をそのまま入れる」を例付きで書いているのは、指示しないと正規化するからです。 「12.30」は「12.3」に、「1.2×10³」は「1200」に、親切に直して返します。そうすると、有効数字の食い違いという、見つけたかった誤りが消えます。

「推測で1つに決めない」は、参照先の結び付けのためです。 候補が2つあるときに片方に決めると、たまたま違う方を選んで「値違い」の誤った指摘が出ます。 候補を並べさせ、決まらないものは審査担当に回します。

出力形式を固定する

本文の数値は、次の形のJSONで受け取ります。

{
  "report_id": "",
  "mentions": [
    {
      "id": "m-0001",
      "page": 12,
      "sentence": "",
      "value": "12.8",
      "unit": "MPa",
      "qualifier": "",
      "ref": { "table": "表3", "row": "試料B", "col": "引張強さ" },
      "candidates": [],
      "compare": null,
      "status": "linked | unlinked | figure_only"
    }
  ]
}

Python が比べたあとの指摘は、次の形の一覧にします。

1つ目の理由は、value を文字列で持つことで桁を判定できることです。 「12.30」と「12.3」の違いは、数値にした時点で消えます。有効数字の点検は、文字列でなければできません。

2つ目は、status で人に回すものを分けられることです。 linked のものは Python が比べ、unlinked と figure_only は比べずに一覧の別の欄に並べます。比べられなかったものを「問題なし」に混ぜません。

3つ目は、計算の内容 を残すことで、審査担当が確かめやすくなることです。 「表3の試料A 10.0、試料B 12.5 から計算した増減率は25.0％、本文は30％」と並べれば、電卓をたたかずに指摘が正しいか分かります。

Python は、linked の数値を次の順で比べます。

1. 単位をそろえる … 本文と表の単位が違えば換算表で換算します。換算表に無ければ unit_mismatch にして終わります
2. 値をそのまま比べる … 文字列として同じなら一致です
3. 丸めとして許されるかを見る … 表の値を本文の桁で四捨五入して一致すれば、記載規程の「丸めの許容」に照らします。本文の桁が表より多ければ sigfig にします
4. 「約」を見る … 修飾が「約」なら、上位2桁の一致で判定します
5. 増減率を計算し直す … compare の2つの条件の値を表から引き、本文の桁で丸めて比べます

順番に意味があります。 単位をそろえる前に値を比べると、「1.2 Pa·s」と「1,200 mPa·s」が値違いとして出ます。換算した結果が一致したものは、指摘ではなく「単位を換算して記載」とだけ記録します。

システムへ連携する

報告書のPDFには書き込みません。 指摘を報告書に直接書き込むと、研究員の原稿と事務局の指摘が混ざります。指摘は管理表の側に置き、直すのは研究員です。

人が確認する

審査担当が見るのは、指摘の一覧だけです。 一覧の上から、次の順で確かめます。

1. unlinked と figure_only を先に見る … 参照先が決まらなかった数値です。表に無い値を本文に書いていることもあり、ここに重い誤りが入っていることがあります
2. value_mismatch と rate_mismatch を確かめる … 報告書の該当の文と表を開き、計算の内容を見ます
3. unit_mismatch と sigfig を確かめる … 記載規程に照らして、研究員に返すかを決めます
4. 研究員に返す … 指摘の一覧から返すものを選び、管理表の状態を「返却」にします
5. 誤った指摘に印を付ける … 指摘が外れていたものは理由を書き、記載規程の表と指示を見直す材料にします

1番目を最初にするのは、比べられなかったものが最も危ないからです。 比べた結果の食い違いは目に見えますが、参照先が決まらなかった数値は、比べられないまま通ってしまいます。

目標は、1本28分です。 指摘の一覧を見て、該当の箇所を報告書で確かめ、研究員に返すまでです。

例外に対処する

上の3行が、指摘の一覧の質を決めます。 どれも報告書の書き方の問題で、研究員に「表は画像で貼らない」「前報の値は引用の番号を付ける」と頼むほうが、点検の精度を上げるより早く効きます。

記録を残す

• 提出された報告書のPDFと、版・提出日
• 3回の呼び出しで受け取ったJSONの全文
• Python が比べた結果と、そのとき使った記載規程の表と換算表の版
• 指摘の一覧と、審査担当が研究員に返したもの
• 誤った指摘に付けた印と理由
• 再提出の版で指摘が解消したか

3つ目で記載規程の版を残すのは、規程が後から変わるためです。 丸めの許容を変えると過去の指摘の意味が変わり、当時の規程が残っていないと、なぜ指摘したかが説明できません。