January 28, 2026
Subs, search, and spicy takes
Tuning Semantic Search on JFMM.net – Joint Fleet Maintenance Manual
Ex‑Navy builds faster search for a 3,470‑page manual—comments explode over cost, models, and peanut‑butter “Jiff‑m” vibes
TLDR: A former Navy QA officer built a smarter, cheaper way to search a massive manual. Commenters clash over pricey databases vs. simple setups and OpenAI vs. local models, while trading laptop horror stories—because faster, more accurate search for critical instructions can save time and prevent costly mistakes.
A former Navy quality assurance officer got sick of scrolling through a 3,470‑page maintenance manual and built a smarter search tool for it. Instead of literal word matches, he used “semantic search,” which finds results by meaning, not exact phrasing. He first ran it on a hosted Postgres database with a vector plugin, then rewrote it to make it cheaper and faster. That’s where the comment section lights up. One user gushes about these “battlefield notes” from real‑world search projects, while another cheers the move away from pricey hosted databases—“paying $20/month to find one paragraph is a vibe,” joked one reply. The hot split: folks who swear by Postgres because it’s easy on their setups vs. the “SQLite and chill” crowd. Model wars flare too: some lean on OpenAI embeddings, others hype local tools like “llama‑server,” and everyone has opinions about CPU vs. GPU and speed on sad government laptops. The funniest meme? People pronouncing JFMM as “Jiff‑m,” comparing semantic search to choosing the right peanut butter, and turning “QA forms are not self‑invoking” into a catchphrase. The biggest gripe: results that are close but not perfect, sparking debates about ranking tweaks, hybrids, and RAG (retrieval‑augmented generation) add‑ons to actually answer questions.
Key Points
- •The author built JFMM.net to semantically search the 3,470-page Joint Fleet Maintenance Manual used in Navy QA.
- •Semantic search was implemented via vector similarity search with pre-embedded document chunks and query-time embedding.
- •Initial stack: Unstructured for chunking, nomic-embed-text-v1.5 for embeddings, PostgreSQL with PGVector, FastAPI, and Sentence Transformers for queries.
- •Issues identified: hosted Postgres cost (~$20/month on DigitalOcean), high RAM/CPU usage for Sentence Transformers, and imperfect result ranking.
- •A rewrite began late last year to address cost, performance, and relevance, starting with replacing PostgreSQL, which was deemed overkill.