2 min readfrom Machine Learning

Hundreds of papers hit arXiv every day and maybe 3 matter to my research, so I built an open-source tool that finds them [P]

Our take

Navigating the daily deluge of arXiv papers can consume valuable research time. Research Radar, a newly released open-source tool, addresses this challenge by intelligently filtering and summarizing relevant findings. This daily cron job fetches, scores, and deep-reads papers based on your defined research interests, delivering concise HTML digests and optional Telegram notifications. Built for flexibility and model-agnosticism, it empowers researchers across diverse fields—consider it a focused alternative to broad newsletters. Explore the project on GitHub: [https://github.com/ramazan793/research-radar](https://github.com/ramazan793/research-radar).

The relentless expansion of the research landscape, particularly in fields heavily reliant on pre-print servers like arXiv, presents a significant challenge for researchers. Sifting through hundreds of daily submissions to identify genuinely relevant work is a time-consuming and often frustrating process. The creator of Research Radar clearly understands this pain point, and their open-source solution offers a compelling, and remarkably elegant, approach. It’s a welcome counterpoint to the often-superficial curation offered by traditional newsletters, which tend to prioritize popularity over relevance—as highlighted by our recent piece on [Chain of Thought is a scaling trap. the next wave is latent reasoning (Coconut / HRM / RecrusiveMAS)... but then we hit the black box wall. Where does BDH fit? [D]]. This tool represents a shift towards personalized, AI-powered knowledge filtering, echoing the increasing need for tools that adapt to individual research interests, a theme also explored in Davide de Paolis’ presentation on [Presentation: Road to Compliance: Will Your Internal Users Hate Your Platform Team?], where the importance of tailoring solutions to specific user needs is paramount.

What’s particularly impressive about Research Radar is its modular design and commitment to accessibility. The decision to keep the core code deterministic, relying on external models only for scoring and deep-reading, minimizes dependency and allows for easy customization. The model-agnostic backend, supporting everything from Claude Code to local LLMs like Ollama, further enhances its adaptability and reduces operational costs. This flexibility is crucial, especially given the rapidly evolving landscape of large language models. The author’s explicit acknowledgment of the need to calibrate the LLM judge, ensuring it consistently flags irrelevant papers without inflating scores, demonstrates a thoughtful approach to a common challenge in AI-assisted research. This focus on practical implementation and user control distinguishes it from many "revolutionary" AI tools that often prioritize flashy features over genuine utility.

The project's open-source nature is a significant asset, fostering community feedback and encouraging contributions from researchers across diverse disciplines. Given the reliance on prompt engineering and markdown context for scoring, the call for feedback on LLM calibration is especially valuable. It highlights the iterative and collaborative nature of developing effective AI tools for specialized tasks. This resonates with the broader trend of democratizing access to AI, moving away from proprietary solutions and towards community-driven development. The described workflow, which leverages both a quick scoring pass and a more intensive deep-read for top candidates, represents a pragmatic balance between efficiency and thoroughness, a crucial consideration when dealing with the sheer volume of new research being published daily. It’s a testament to the power of combining readily available tools—RSS feeds, APIs, PDF extraction libraries, and LLMs—into a cohesive and highly effective solution.

Ultimately, Research Radar underscores a growing trend: researchers are increasingly turning to custom solutions to manage the information overload. The project’s success hinges on its ability to continually refine the LLM’s judgment and adapt to the evolving nature of research. As models become more sophisticated and the volume of published work continues to grow exponentially, will we see a proliferation of similar, domain-specific AI assistants, each tailored to the unique needs of a particular research community? Or will we see the emergence of more generalized platforms capable of learning and adapting to a wider range of research interests, potentially integrating with tools like the ones discussed in [Java News Roundup: TornadoVM 5, JHipster, Google ADK, OmniFish Build of Payara, Introducing Vidocq], to streamline the entire research workflow?

Left: Telegram digest (optional); Right: detailed digest on HTML

Like probably everyone here, my to-read list only grows. Skimming arXiv listings or my feeds takes 30-60 minutes a day, 95% of it is irrelevant to what I actually work on, and newsletters don't really help: they surface what's popular, not what's relevant to my research.

So I built Research Radar, a daily cron job that:

  1. Fetches every new paper in your arXiv categories (RSS + API, deduped)
  2. Scores every abstract 1-10 against a markdown file describing your research interests (cheap model, batched)
  3. Deep-reads the top scorers: downloads the PDF, extracts full text, and a strong model writes a summary, key insights, limitations, and how it relates to your own work
  4. Delivers a morning HTML digest + optional Telegram ping with the must-reads

Design decisions:

  • Nothing domain-specific in the code. Your interests live in one markdown file. Edit it and the same pipeline works for ML, physics, bio, econ, whatever
  • Only the two scoring passes touch a model. Fetching, dedup, PDF extraction, and rendering are deterministic Python
  • Model-agnostic backend layer: Claude Code / Codex CLIs run it on the subscription you already pay for (no API key), or any OpenAI-compatible endpoint, including fully local via Ollama / vLLM. Backends mix per pass: cheap model for skimming, strong one for the 5-10 deep reads
  • Approximate costs, benchmarked in the repo (tokens, cost, latency, quality grades per model). Rough sizing: a 10-abstract scoring batch is ~18k input tokens with a small JSON out; a deep read sends the whole paper, 40-70k input tokens.

I've been using it daily for about a month and it's been genuinely useful in my field. The repo is a generalization of my personal setup to any domain, and I haven't deeply tested fields other than mine, so feedback and GitHub issues are very welcome.

The model has to say "not relevant, 3/10" a lot without drifting toward score inflation, and the whole scoring is just prompt + markdown context. So I'm curious how others would approach calibrating an LLM judge like this

GitHub: https://github.com/ramazan793/research-radar

submitted by /u/usedtobreath
[link] [comments]

Read on the original site

Open the publisher's page for the full experience

View original article