LocalLLaMA가 주목한 SQLite FTS5·Nemotron 9B 기반 350만 건 특허 검색 엔진

이번 주말 r/LocalLLaMA에서 반응을 얻은 프로젝트 하나는 흔한 “embeddings everywhere” 검색 스택과는 다른 길을 택했다. 주인공은 PatentLLM으로, 2016년부터 2025년까지의 미국 특허 350만 건을 다루는 무료 검색 엔진이다. 작성자는 자신을 2025년 12월에 코딩을 시작한 patent lawyer라고 소개하며, 전체 코퍼스를 74GB짜리 단일 SQLite 파일에 넣고 그 위에 full-text search, local LLM 분류, server-side rendering을 얹었다고 설명한다.

가장 핵심적인 기술 선택은 의도적으로 보수적이다. retrieval backbone으로 vector search를 쓰는 대신 SQLite FTS5와 BM25를 채택했다. 이유는 도메인 특화적이다. 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는 verbosity 때문에 더 낮은 weight를 줬다고 한다. 작성자는 이 조정이 숙련된 patent searcher의 수동 우선순위와 더 가깝다고 주장한다.

주변 스택도 흥미롭다. 웹 앱은 FastAPI와 Jinja2로 구성됐고, 호스팅은 Chromebook과 Cloudflare Tunnel 조합이라고 한다. 메시지는 명확하다. 운영 복잡도를 낮추고, 유료 API를 피하고, 데이터를 평범한 도구로 복사하고 옮길 수 있는 단일 파일 안에 두겠다는 것이다. 수백만 개의 긴 기술 문서를 다루는 검색 제품에서 이런 “boring infrastructure” 선택은 그 자체로 의미가 있다.

이 글이 LocalLLaMA에서 반응을 얻은 이유도 여기에 있다. local model enthusiasm를 실제 end-to-end utility로 연결했기 때문이다. 이 프로젝트는 LLM이 leverage를 주는 지점에는 model을 쓰되, exact symbolic retrieval이 더 강한 구간에는 굳이 neural method를 강요하지 않는다. 그 역할 분담이 많은 generic “AI search” demo보다 훨씬 설득력 있게 보인다.

커뮤니티 출처: r/LocalLLaMA 게시글
원문: 기술 글, 라이브 검색 엔진