LocalLLaMAが注目したSQLite FTS5とNemotron 9Bによる350万件特許検索エンジン

今週末のr/LocalLLaMAで反応を集めたプロジェクトのひとつは、よくある“embeddings everywhere”型の検索スタックとはかなり違う道を選んでいる。名前はPatentLLMで、2016年から2025年までの米国特許350万件を対象にした無料検索エンジンだ。投稿者は2025年12月にcodingを始めたpatent lawyerだと説明しており、全文書を74GBの単一SQLite fileに収め、その上にfull-text search、local LLM分類、server-side renderingを組み合わせたという。

もっとも重要な技術判断は意図的に保守的だ。retrievalの土台にvector searchを置くのではなく、SQLite FTS5とBM25を採用した。理由はdomain-specificである。patent searchではsemanticに近い文書より、exact phrase matchingが優先される場面が多いからだ。たとえば“solid-state battery electrolyte”を検索するなら、広く関連しそうなenergy storage文書ではなく、その正確な表現を含む特許を上位に出したい、という考え方である。

もちろんLLMが使われていないわけではない。Nemotron 9BはRTX 5090上でlocalに動き、350万件すべてを100個のtech tagへ分類したとされる。投稿者によれば、この処理には約48時間かかった。さらに別のlocal LLM layerがnatural-language queryをFTS5のboolean queryへ展開する。rankingではtitle matchを最重視し、その次にassignee、abstractを評価し、claimsは冗長さを考慮して低めのweightにしたという。投稿者は、この調整の方がexperienced patent searcherの手動順位付けに近いとしている。

周辺スタックも興味深い。web appはFastAPIとJinja2で構成され、hostingはChromebookとCloudflare Tunnelの組み合わせだという。狙いは明快だ。運用面を小さく保ち、有料APIを避け、データを普通のツールでコピーや移動ができる単一fileにまとめることだ。数百万件の長い技術文書を扱う検索プロダクトで、こうした“boring infrastructure”の徹底はそれ自体が強いメッセージになっている。

この投稿がLocalLLaMAで刺さった理由もそこにある。local modelへの熱量を、具体的なuser needを持つend-to-end utilityへ落とし込んだからだ。このprojectは、LLMがleverageを生む場所にはmodelを使い、exact symbolic retrievalの方が強い部分には無理にneural methodを押し込まない。その役割分担が、多くのgenericな“AI search” demoよりもずっと信頼しやすい。

コミュニティ出典: r/LocalLLaMA投稿
原文: 技術記事, live search engine