ChatGPT(OpenAI API)に回答のエビデンスを明確に示させるための仕組みをPoC実装してみた。
GitHub - tadano-akira/openai-query-app · GitHub
課題
というのも、ChatGPT(OpenAI API)の回答には、根拠となる参照先のURLは出ていても、
参照先のどこを根拠にしたのかまでは示されておらず、
自力で参照先のWebPageないしPDF内を検索して確かめるしかない。
これは不便なので、根拠となる情報までハイライトさせて、
一発で目視確認できるようにできないかと思い、構想・実装してみた。
前提として、企業の決算情報を扱った。
各企業IRサイトやEDINET、TDNETなど根拠に足りる原本が
しっかり管理されているので。
結果は以下。

結論
結論から言おうと、PoCレベルの実装は出来たのだが、いろいろ課題が多い。
上記では、「トヨタの直近の有利子負債はいくら?」
という質問にたいして、トヨタIRで公開されているPDFを参照して、
根拠となる箇所にダイレクトリンクしてハイライト表示もしている。
ここまでは便利な道具がそろっているので、すぐに実装できた。
エビデンスの担保
問題はエビデンスの担保から。
まず、エビデンスの確かさは、人間でないと判断できない。
というか、公式サイトやEDINET、TDNETからの情報なら信頼できるけど、
YouTubeだの株予想系のWebなどは根拠にならないが、AIはかまわず、そうしたソースも提示する。
そうした情報を根拠にした回答が混じると、幻視まではいかないが、
ビジネスシーンで求められる正確性、信頼性が担保できない。
おのすと、情報源は公的なものに絞られる。
データの構造化問題
また、PDFが情報ソースの場合、PDF内の情報構造を予め解析して、
位置情報も含めたMETA DB の整備が必要になる。
つまり公開情報を取り込んで事前解析したDB検索対象としたRAG SYSTEMになる。
ここが一番重い。データの構造化問題だ。整備・維持コストがきつい。専任担当が欲しいレベル。
META DBさえできていれば、あとはPDF内の参照元をハイライトしてダイレクトリンクさせるだけなのだが
ここでも問題がある。根拠が複数の場合だ。
あとえば「トヨタの直近の有利子負債はいくら?」という質問に対して、
有利子負債が2つのデータの合算なケースなどがある。
(流動負債分と非流動負債分の合計)
そうした定義も設定していくと、データの構造化をしていく作業がとにかく重い。
ある程度は自動化できるだろうが、最終的な正確性・信頼性の担保は、
人間による確認・承認プロセスに頼ざるおえない。
やはり、まともに運用するとなると担当者が欲しい感じ。
アーキテクチャ:

flowchart TD
UI[React UI] --> API[FastAPI]
API --> DB[(PostgreSQL)]
API --> FILES[原本・抽出成果物]
WORKER[バックグラウンドワーカー] --> DB
WORKER --> FILES
WORKER --> PARSER[PyMuPDF解析]
WORKER --> MODEL[LLM・埋め込みAPI]
UI --> VIEW[PDF.js・HTMLビューア]
VIEW --> API
採用コンポーネント
| 層 |
採用案 |
責務 |
| Web UI |
React + TypeScript + Vite |
資料管理、質問、根拠確認 |
| PDF表示 |
PDF.js |
原本描画、ズーム、回転、ページ移動 |
| API |
FastAPI + Pydantic |
認証、入力検証、根拠解決、履歴 |
| PDF解析 |
PyMuPDF |
文字・行・座標・表候補抽出 |
| DB |
PostgreSQL + pg_trgm + pgvector |
永続化、字句・ベクトル検索 |
| ORM / migration |
SQLAlchemy + Alembic |
スキーマ・トランザクション |
| ジョブ |
PostgreSQLのjobsテーブル + 専用Pythonワーカー |
再実行可能な非同期処理 |
| 数値処理 |
Python Decimal |
加算・減算・単位変換 |
| LLM接続 |
プロバイダーアダプター |
構造化JSON生成、使用量計測 |
| 配布 |
Docker Compose |
ローカル実行 |
本格実装時の規模感
今回のPoCではLangChain / LangGraph / Difyなどは利用せず、明示的なPythonの処理段階で実装。
PoCから本格実装時には、運用コストも勘案すると、LangChain、LangGraph、Difyなども活用すべき。
HNSW索引なども入れたい。
対象を全上場企業にすると、DBやストレージサイズが1.4TBくらいに膨らむ。
仮に100名のアナリストが利用すると想定して、 systemを1台のServerに収めるとすれば、
32コア・256GB メモリ・NVMe 8TB 級が望ましい。
AWSだとr7i.8xlarge+EBS gp3 8TBで、月額3000ドル(50万円弱)。
かなりのインフラがないと稼働は厳しい。個人でどうにかする規模ではない。