NeuLitTrace

• 

  Hero Page

• 

  Search Query

• 

  3D Brain Atlas

• 

  Summary Tab

• 

  Retrieval Tab

• 

  Paritok Dashboard

Inspiration 🧠

Rare PET and neuroimaging findings live in scattered case reports buried across decades of literature. Existing search tools were built for high-volume, common-condition lookup, keyword search over well-indexed terms, not for surfacing the rare, underrepresented cases hiding in the long tail. Against that kind of query, they fall short, so radiologists and researchers still end up digging manually, and rare cases stay rare partly because they're this hard to find.

There's a second, less obvious problem underneath: naive RAG doesn't scale to this. Stuffing full papers into every prompt burns tokens linearly with how much literature you search, so a tool that can't control its token footprint can't scale into something practitioners could actually rely on. NeuLitTrace exists to solve both problems together: surface the rare cases, and do it on a token budget that holds up in production.

What it does ⚙️

NeuLitTrace is a retrieval-augmented generation system built specifically for rare neuroimaging cases. It mines PubMed and Orphanet literature, actively weights results toward rare and underexplored findings instead of letting common cases bury them, and outputs a sourced clinical summary with inline citations, so every claim traces back to a real paper. Token efficiency is engineered into the retrieval and generation path itself, not layered on afterward.

How we built it 🛠️

A hybrid retrieval engine ranks literature with BM25 and vector search side by side, then applies a custom rarity boost that pulls overlooked cases up where they belong. Before anything reaches the model, Paritok's compression pipeline strips the stuffed-abstracts prompt down to what the model actually needs. Groq's Llama 3.3 70B then turns that lean context into a clean, cited summary.

Paritok is load-bearing here, not decorative. Its proxy sits in front of Groq's API for reliable, low-latency routing with zero custom integration code. But the meaningful integration was that its compression pipeline is exposed as a directly-callable SDK primitive, not just proxy middleware. That distinction mattered: Paritok's proxy auto-compresses role: "tool" messages and long conversation history, the shape an agentic coding tool produces. A single-shot RAG prompt with abstracts stuffed into user never qualifies for that path. We only found this by running our own controlled measurement gate, an A/B test across two candidate call sites, which is what pointed us at calling CompressionPipeline directly on the one prompt that actually needed it: the large, expensive summary call.

By the numbers 📊

• 💰 88.3% token reduction with 385.86M tokens in / 45.04M tokens out / $107.25 saved, pulled straight from our Paritok account dashboard across the full project
• 🔻 40.9% token reduction on the sourced-summary call, a controlled A/B measurement against a 15% threshold, not a marketing estimate
• 📈 54% average reduction across a 14-query real-corpus batch, peaking at 80-95% on sparse or repetitive content

Challenges we ran into 🚧

Building a production-grade GPU-backed pipeline from scratch, on our own infrastructure, was the hardest part of this project, and we treated every rough edge as a robustness requirement to engineer around rather than something to work past. Cold starts on our hosted GPU backend could stretch past 90 seconds, so we designed an 8-second bounded wait with a graceful passthrough fallback, paired with a staged loading state on the frontend, so a slow start reads as expected behavior instead of a stall. We didn't trust our own pipeline blindly either: we built explicit before/after token verification into every compression call instead of assuming success, and caught and stripped a [REF:<hash>] reference marker before it could ever reach a user, since our single-shot summary calls have no tool loop to resolve it themselves. None of this was handed to us; we designed the verification and fallback layers ourselves because a real product can't afford to fail silently.

Getting the ranking itself right took real iteration too. Weighing relevance against rarity is a genuinely hard tradeoff, and several passes were needed before it felt right instead of just plausible.

Accomplishments that we're proud of 🏆

A meaningful, measured use of Paritok inside a genuine workflow. We didn't drop Paritok into a simple app and call it done. We ran a controlled A/B test across two candidate call sites, identified the one that actually mattered, and shipped a verified 40.9% reduction on our most expensive prompt inside a real retrieval-to-summary pipeline, backed by measurement rather than a claim.

Technical execution built to run end-to-end, not just work once. The compression call sits behind an 8-second bounded wait with graceful passthrough on a cold GPU, paired with a frontend loading state so the fallback never reads as broken. Clone the repo and it reproduces the same working state a judge would see, engineered for someone else to run and rely on, not a one-off we happened to get working.

Originality in where the compression lives, not just that it's there. Most integrations stop at wrapping the proxy around a call and moving on. We found that a single-shot RAG prompt never qualifies for Paritok's auto-detected compression, so we called CompressionPipeline directly on the one prompt shape that actually needed it, layered on top of a rarity-weighted retrieval ranking most search tools don't attempt at all. That's a real product decision, not a thin wrapper with Paritok bolted on.

Real-world usefulness for a problem practitioners actually face. Rare-case literature search is a genuine, unsolved workflow gap for radiologists and researchers, and the token-cost problem it creates is exactly the kind of scaling wall a team running AI at real volume would hit before they could ship a RAG tool like this into production.

What we learned 📚

Token efficiency isn't a backend cost concern, it's a product-quality lever. When compression is applied precisely, at the call site that actually carries the retrieval payload, rather than indiscriminately across every request, it directly expands what a product can afford to do: richer retrieval, faster responses, and a lower barrier for real people to actually use the tool. That reframing was the core lesson of this hackathon. Working with Paritok's CompressionPipeline as a directly-callable primitive, rather than opaque proxy middleware, gave us the control to apply that principle deliberately instead of hoping it worked by default. We're grateful for the chance to build with Paritok this hackathon and for what it taught us about engineering efficiency as a first-class part of product design, not an afterthought bolted on at the end.

What's next 🔭

The corpus is currently 14 hand-selected conditions, a scope we chose deliberately: prove the verification pipeline holds up against the hardest case first, sparse and inconsistent rare-disease literature, before expanding breadth on top of a foundation that already works. Next up is scaling ingestion to a live PubMed/Orphanet pipeline with automated quality filtering, so new conditions can be added without re-validating the whole system by hand.

We also want to turn citation flagging from a passive label into an active control, letting users filter or re-rank summaries by verification confidence directly in the interface, and move rate limiting from a hackathon-quota constraint (10 req/min on queries) to usage-based tiers with a request queue, so demand beyond the free tier degrades gracefully instead of hitting a hard wall.

Find out more in our repository and documentation below!

🔗 Built for Paritok's Token-Efficiency Hackathon

💻 GitHub: https://github.com/zenyaa07/NeuLitTrace 📖 Full Documentation: https://neu-lit-trace.vercel.app/

Built With

• bm25
• fastapi
• groq
• httpx
• langchain
• llama-3.3-70b
• next.js
• nilearn
• orphanet
• paritok
• playwright
• pubmed
• python
• radixui
• react
• sentence-transformers
• shadcn/ui
• slowapi
• tailwindcss
• typescript
• uvicorn
• vercel