LazyResearch OS：替用戶閲讀未讀資料的 AI

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

LazyResearch OS — Save the reading. Find what matters. Keep the evidence.

What I Built

I built LazyResearch OS, a tool for people who keep saving things they intend to read later — PDFs, articles, notes, quotes, meeting notes, emails copied as text — and then never get around to organizing or acting on them.

The basic idea is:

Give LazyResearch the things you were too lazy to read, organize, or research. It finds what matters, keeps the evidence, and tells you what may actually need your attention.

A user can:

1. Add URLs, PDFs, TXT/Markdown files, or pasted text.
2. Let an open-weight Gemma model analyze each source.
3. Open What Matters to see which saved items deserve attention.
4. Give simple feedback so LazyResearch can learn their preferences over time.
5. Ask a research question across a specific collection of saved material.
6. Get a cited research brief showing exactly which saved sources support the answer.
7. Review source-backed actions such as deadlines, follow-ups, or things that need verification.
8. Accept, edit, complete, dismiss, or reopen those actions.

A real example from my testing

I added a short meeting note comparing three project-management tools:

• Tool A costs €12/user/month and includes time tracking.
• Tool B costs €9/user/month but does not include time tracking.
• Tool C costs €15/user/month and includes automation.
• The team has to decide before 15 November 2026.
• Before choosing, Tool B's SSO support and Tool C's data-export capability need to be confirmed.

LazyResearch automatically:

• summarized the note,
• detected the decision deadline,
• classified it under Action required,
• proposed:
  • Confirm Tool B SSO support
  • Confirm Tool C data export capability
• let me ask: > “What should we verify before choosing office software?”
• created a research brief using only the selected Office software collection,
• cited the original note as evidence,
• disclosed that the answer had partial coverage because only one personal source was available,
• and preserved the action provenance all the way back to the original text.

The point is not just summarization. The goal is to turn saved information into priorities, evidence-backed research, and things worth doing.

Demo video

Live demo

https://lazyresearch-os-demo.onrender.com/

The public deployment is intentionally a synthetic shared demo workspace.

Please do not upload personal or private information. The current challenge demo has no authentication and stores demo data persistently in PostgreSQL rather than temporary browser storage.

Some research/analysis features depend on a separately supervised worker and local model host, so they may not be continuously available.

Demo flow

For the final video I will demonstrate:

1. Add a new source.
2. Put it in a collection.
3. Analyze it with Gemma.
4. See it appear under What Matters.
5. Give explicit relevance feedback.
6. Start a research mission limited to that collection.
7. Inspect the generated brief.
8. Open the exact evidence used by the answer.
9. Review the generated source-backed actions.
10. Accept one of those actions.

Code

GitHub:

https://github.com/rishabh-hasija/lazyresearch-os

The project is released under the MIT License.

How I Built It

LazyResearch OS is a Python modular monolith backed by PostgreSQL.

The architecture deliberately keeps original sources, AI-generated analysis, evidence, research history, user feedback, and actions separate instead of treating an AI response as disposable chat output.

The simple version

The flow looks like this:

You provide

• URLs
• PDFs
• TXT / Markdown files
• pasted notes or email text

↓

LazyResearch

• saves the original material,
• extracts readable content,
• analyzes it,
• learns what you care about,
• searches your saved material,
• performs longer research jobs,
• keeps evidence attached to generated claims.

↓

You receive

• a What Matters priority view,
• cited research briefs,
• preserved research history,
• coverage limitations,
• source-backed actions.

What happens technically

Gemma

I use Gemma locally through Ollama for source analysis and research synthesis.

It extracts:

• summaries,
• topics,
• claims,
• uncertainty,
• candidate deadlines,
• source-backed actions,

and later synthesizes structured research briefs from selected evidence.

The project does not assume that model output is automatically trustworthy. Citations are validated against the evidence selected for the mission, and partial coverage is disclosed instead of pretending the system knows more than it does.

Embeddings and pgvector

Saved source text is split into deterministic chunks.

I use qwen3-embedding to create semantic embeddings, which are stored with pgvector in PostgreSQL.

LazyResearch combines:

• PostgreSQL full-text search for lexical/exact retrieval, and
• semantic/vector retrieval for meaning-based matching.

A deterministic Reciprocal Rank Fusion step combines the two.

Lexical retrieval remains available as a fallback.

Temporal

Long research jobs run through Temporal.

A Research Mission is not just a large function call. It moves through durable stages such as:

• personal-source retrieval,
• evidence selection,
• evidence freezing,
• synthesis,
• citation validation,
• result publication.

During the challenge I explicitly tested worker restart and recovery. An in-flight mission survived worker interruption without producing a duplicate publication.

Research results are immutable: rerunning a topic creates another version instead of overwriting the previous answer.

TabPFN

TabPFN powers the personalized relevance path behind What Matters.

The important part is the cold start.

LazyResearch does not claim to know the user immediately.

At first it shows:

Learning your preferences

The baseline ranking uses transparent signals such as recency, deadlines and source-backed actions.

Users then give explicit feedback such as:

• Read now
• Useful later
• Action required
• Low priority

Only after enough labeled examples exist, and only if the personalized model passes the evaluation gate against the baseline, can the UI honestly switch to:

Personalized for you

My synthetic held-out benchmark produced:

• TabPFN macro-F1: 1.000
• baseline macro-F1: 0.544

That proves the integration works on the benchmark, not that real-user ranking quality has already been solved. Real-user personalization remains something to validate further.

Render

The public Streamlit demo runs on Render using a Docker web service.

The hosted application connects to the database through the provider-neutral DATABASE_URL configuration.

Render hosts the public web interface, while the supervised research worker and local inference stay separate for this challenge demo.

PostgreSQL / Neon

Neon PostgreSQL is the canonical durable store for the hosted demo.

It holds things such as:

• source captures,
• extracted content,
• analyses,
• chunks,
• vector embeddings,
• collections,
• feedback,
• research topics,
• missions,
• immutable research results,
• citations/evidence,
• actions and revisions.

The original source and AI-generated analysis are kept separately.

This also means the public demo is not temporary browser storage. Because the challenge demo is one shared workspace without authentication, it is explicitly restricted to synthetic/demo material.

Public web search

LazyResearch also contains a provider abstraction and implementation for public-web research through SerpApi.

However, I did not use a live SerpApi key in the final hosted verification, so I am not claiming live SerpApi use in this submission.

The saved-source research path is the one demonstrated and verified end-to-end.

Why Does Open Innovation Matter?

Open innovation is central to this project rather than an add-on.

The part of LazyResearch that actually reads and synthesizes a user's material runs through an open-weight model that I control.

That gave me several useful properties during development.

I could run inference locally

Gemma and the embedding model run through Ollama on my own machine.

I did not have to design the application around one proprietary model API before I even knew whether the product idea worked.

Models are replaceable

The domain and application layers depend on provider-neutral ports rather than a specific model vendor.

Gemma is the current implementation, but the architecture does not require rebuilding the product around a different API if the inference model changes.

I could inspect and constrain the pipeline

The system separates:

• original source,
• extraction,
• model analysis,
• evidence,
• research synthesis,
• user decisions.

That made it possible to test failures honestly.

For example, during my own end-to-end walkthrough, a research mission failed because strict lexical retrieval returned zero evidence. Instead of weakening the evidence invariant and allowing the model to answer anyway, I fixed the retrieval path so an explicitly selected collection could provide bounded fallback context and the final result was marked Partial coverage.

That behavior is much closer to what I want from personal research software:

When evidence is weak, say so.

Open tools let the pieces cooperate

The project combines:

• Gemma for reasoning/synthesis,
• Ollama for local inference,
• qwen embeddings,
• PostgreSQL + pgvector,
• Temporal for durable workflows,
• TabPFN for personal relevance learning,
• Streamlit for the application UI,
• Render for public hosting.

Because those pieces can be inspected, replaced and composed, I could build around the product behavior I wanted instead of around the limitations of one closed AI endpoint.

My Agent Session

I used coding agents heavily while building LazyResearch OS.

Rather than keeping one enormous agent conversation, I split development into small roadmap slices such as:

• domain foundation,
• persistent intake,
• Gemma analysis,
• retrieval,
• Temporal Research Missions,
• TabPFN ranking,
• Streamlit application,
• deployment,
• final UX walkthrough fixes.

Each fresh agent session reconstructed the project from repository documentation such as AGENTS.md, STATUS.md, NEXT.md, architecture docs and ADRs.

That turned out to be especially useful during the final manual walkthrough.

Instead of assuming that passing tests meant the product was finished, I used the application myself from scratch and found several real usability and workflow problems:

• collection creation failed in a stale Streamlit session,
• “Analyze next source” could process refresh jobs before a new source,
• feedback saved successfully but its confirmation appeared offscreen,
• collection context initially did not carry consistently into Research or Actions,
• strict lexical retrieval caused a real Temporal mission to fail with no evidence,
• completed partial research existed but could not initially be opened from the UI.

Those issues were found by manually acting like a real user, then giving the agent a minimal reproducible case and requiring it to fix the root cause rather than hide the error.

DevRelay session:

To be added if I export one before submission.

The Lazy Payoff

I built LazyResearch because my own pattern is very simple:

I save things because they seem important.

Then I don't read them.

Or I read them once and forget why I saved them.

Or something in the document requires an action later, and that action disappears into the pile.

LazyResearch tries to remove those steps.

In the Office Software walkthrough, I only entered a short meeting note.

From that one source, the system:

• preserved the original,
• summarized it,
• identified the decision deadline,
• surfaced it as requiring action,
• proposed two things that need verification,
• accepted explicit feedback about its relevance,
• researched a question across only that collection,
• disclosed that the research had limited coverage,
• cited the original note,
• and turned one of those proposals into an accepted task.

I am deliberately not claiming a precise “X hours saved” figure yet.

The payoff is simpler:

I should not need to repeatedly reread everything I saved just to rediscover what mattered.

That is the kind of laziness this project is built to reward.

Prize Categories

I am entering the categories the project uses and has verified meaningfully:

Best Use of Gemma

Gemma is the core open-weight model for source analysis and cited research synthesis.

It was exercised through real local inference during both benchmarks and the manual end-to-end walkthrough.

Best Use of TabPFN

TabPFN powers the evaluated personalized relevance path for What Matters.

The product begins with an honest deterministic baseline and only activates personalization after explicit user feedback and evaluation justify it.

Best Use of Temporal

Temporal coordinates durable Research Missions.

The project includes real Temporal Cloud execution, retries, failure handling, worker-restart recovery and immutable publication behavior.

Best Use of Render

The public LazyResearch OS demo is deployed as a Docker-based Streamlit service on Render and uses the live Neon-backed application state.

Current Limitations

This is a challenge build, not a production personal-data service.

Current limitations include:

• the public demo uses one shared synthetic workspace,
• no authentication,
• users must not upload personal/private information,
• research/model processing depends on a separately supervised worker,
• public SerpApi research is implemented but not live-verified,
• Gmail/RSS connectors are not implemented,
• TabPFN's benchmark is synthetic and real-user personalization still needs validation,
• research can disclose partial coverage when evidence is insufficient,
• OCR is not implemented.

I prefer listing those limitations rather than making the demo look more production-ready than it is.

LazyResearch OS started with a very lazy question:

What if I could save something once and never have to remember why it mattered?

The answer turned into a system that preserves the source, finds the evidence, tells me what deserves attention, and still lets me inspect where every important conclusion came from.