【要約】Claude Codeと91本のPDFで知識グラフを作って卒論を書いた（そして何が壊れたか） [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
非エンジニアの著者が、91本の文献から仮説を導くLLMパイプラインを構築した。しかし、設計と実装の不備により、データが壊れる深刻な問題に直面した。
- ・コンテキスト管理の設計が、文献間の関係を遮断した。その結果、グラフの40%が孤立した。
- ・ハブノードの次数が過大であった。そのため、ギャップ検出が特定の概念に偏った。
- ・セッションを跨いだことでJSONのキー名が不一致となった。結果、集計が0件のまま提出日を迎えた。
// Approach
著者はClaude Codeを使い、LLMの特性を考慮した設計と、人間による「理屈の検品」を組み合わせた。
- ・即時永続化とprogress.jsonを導入した。これにより、セッション断に強いステートレスな再開を実現した。
- ・Sentence-BERTによる重複マージと、定義文ベースのエッジ追加を実施した。
- ・孤立ノードに対し、LLMの提案と人間による承認プロセスを導入した。
- ・ハブノードの除外と多様性制約を設けた。これにより、ギャップ検出の精度を向上させた。
// Result
著者は、研究に耐えうる知識グラフを構築し、具体的な研究仮説を導き出すことに成功した。
- ・622概念・846エッジのグラフを構築した。孤立率は40%から16.4%へ低減した。
- ・ハブノードの影響を排除した。その結果、15件の異国間比較仮説を生成した。
- ・一方で、スキーマ不整合や再現性の欠如といった、エンジニアリングの課題も浮き彫りにした。
Senior Engineer Insight
> LLMパイプラインでは、「理屈」と「配管」の検証を分離せよ。非エンジニアは理屈の検品は得意だが、スキーマ不整合等の「配管のバグ」を見逃しやすい。LLMにコードを書かせる際は、必ずassertやスキーマ検証を組み込ませるべきだ。また、セッションを跨ぐ際はスキーマを固定し、境界に検証を入れることが不可欠である。