惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
WordPress大学
WordPress大学
博客园 - 司徒正美
罗磊的独立博客
D
Docker
Last Week in AI
Last Week in AI
爱范儿
爱范儿
M
MIT News - Artificial intelligence
V
V2EX
Google DeepMind News
Google DeepMind News
小众软件
小众软件
Apple Machine Learning Research
Apple Machine Learning Research
Microsoft Security Blog
Microsoft Security Blog
T
Tailwind CSS Blog
MyScale Blog
MyScale Blog
V
Visual Studio Blog
博客园 - 叶小钗
B
Blog RSS Feed
A
About on SuperTechFans
F
Fortinet All Blogs
T
The Blog of Author Tim Ferriss
Martin Fowler
Martin Fowler
P
Proofpoint News Feed

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
Why RAG needs context judgment, not just better retrieval
Immanuel Gabriel · 2026-06-07 · via DEV Community

Why RAG needs context judgment, not just better retrieval

Most RAG systems optimize for retrieval.

That makes sense.

Search better.
Embed better.
Chunk better.
Rank better.
Fetch more sources.

All of that matters.

But retrieval alone does not answer a different question:

Should this context actually influence the model?

That is the problem FreshContext is built around.

FreshContext is context judgment infrastructure for AI agents, RAG systems, and retrieval workflows.

The simple version:

candidate context in
decision-ready context out

Retrieval is not judgment

A retriever usually answers:

What might be relevant?

A context judgment layer asks:

What should happen to this context before it reaches the model?

Those are different problems.

A source can be relevant but stale.

A source can be recent but low-confidence.

A source can be useful as background but not strong enough to cite.

A source can have no reliable date.

A source can be a duplicate.

A source can need verification before it should influence an answer.

A normal RAG pipeline can retrieve all of that and still pass it straight into the prompt.

That is where things get messy.

The model may reason fluently from weak context, and the final answer can look confident even when the input material was stale, uncertain, or not citation-grade.

The missing layer between retrieval and reasoning

FreshContext sits after retrieval and before reasoning.

It does not try to replace search, vector databases, RAG frameworks, or agent frameworks.

It focuses on the boundary between them and the model.

The product spine looks like this:

candidate context
-> FreshContext Core
-> freshness / provenance / confidence / utility / source profile
-> decision helper
-> decision-ready output
-> model / agent / app

The goal is not just to produce another score.

The goal is to turn candidate context into a decision.

Example decisions include:

cite_as_primary
cite_as_supporting
use_as_background
needs_refresh
needs_verification
watch_only
exclude

That output is much more useful than only saying:

relevance: 0.84

Relevance is only one part of the story.

Freshness is not truth

One important boundary:

FreshContext does not claim that freshness equals truth.

A fresh source can be wrong.

An old source can still be valid.

An undated source can be risky.

A historical source may be useful, but not for a current claim.

So freshness should not be treated as a magic truth signal.

It should be one part of a broader context judgment process.

FreshContext evaluates candidate context with signals like:

  • source
  • published time
  • retrieved time
  • source type
  • semantic score
  • source profile
  • freshness
  • provenance
  • confidence
  • utility

Then it helps decide whether the source should be used, cited, refreshed, verified, backgrounded, watched, or excluded.

Source profiles matter

Different kinds of context decay differently.

A job post does not behave like a research paper.

A finance signal does not behave like official documentation.

A social pulse signal does not behave like an academic citation.

That is why FreshContext uses Source Profiles.

Examples:

academic_research
jobs_opportunities
market_finance
official_docs
social_pulse

The profile helps define how the system should treat freshness, confidence, provenance, and risk for that kind of source.

This keeps the interface simple while allowing the internal judgment to be more specific.

The current front door: evaluate_context

The current practical front door is:

evaluate_context

The caller brings candidate context.

FreshContext evaluates it.

That boundary is intentional.

evaluate_context does not fetch, crawl, browse, scrape, read folders, or retrieve by itself.

It evaluates caller-provided candidate context and returns decision-ready output.

A simplified input shape looks like this:

{
  "profile": "academic_research",
  "intent": "citation_check",
  "signals": [
    {
      "title": "Example source",
      "content": "Candidate context text...",
      "source": "https://example.com",
      "source_type": "official_docs",
      "published_at": "2026-06-01T00:00:00Z",
      "retrieved_at": "2026-06-07T00:00:00Z",
      "semantic_score": 0.92
    }
  ]
}

The important part is the output.

Instead of only returning raw retrieved material, FreshContext can return something closer to:

Decision: cite_as_supporting
Meaning: Useful supporting context, but not the primary source.
Action: Use with citation and keep stronger sources ahead of it.
Warnings: Date confidence is limited.
Why: Relevant, recent enough, but weaker provenance than official documentation.

That is the layer I think RAG and agent systems need more of.

Reference adapters are not the product

FreshContext includes reference adapters and proof surfaces.

Those matter.

But they are not the product identity.

The product is not “a pile of tools.”

The product is the judgment layer.

The stronger framing is:

FreshContext decides what context deserves to reach the model.

That is the category I am trying to clarify.

Why this matters for agents

Agents often pass information between steps.

One step retrieves.

Another summarizes.

Another decides.

Another writes.

Another acts.

If weak context enters early, the error can travel through the whole chain.

A context judgment layer gives the system a checkpoint before the next reasoning step.

It asks:

  • Should this be cited?
  • Should this be refreshed?
  • Should this be verified?
  • Should this only be background?
  • Should this be excluded?
  • Is the date reliable?
  • Is the provenance strong enough?
  • Is the source useful for this specific intent?

That is different from retrieval.

And it is different from final-answer evaluation.

It is judgment over the context before reasoning happens.

What is live now

FreshContext currently includes:

  • evaluate_context as the generic front door
  • Source Profiles
  • Core evaluation pipeline
  • Decision Helper
  • freshness, provenance, confidence, and utility evaluation
  • BYOC demos
  • arXiv signal-to-decision proof
  • trust/release gates
  • reference adapters as proof surfaces
  • public website
  • npm package

The simple use case is:

Bring candidate context.
Apply a source profile.
Evaluate the signals.
Return decision-ready context.
Let the model reason with cleaner input.

Product Hunt launch

FreshContext is scheduled for Product Hunt on Monday, June 8.

Product Hunt:
https://www.producthunt.com/products/freshcontext?launch=freshcontext

Website:
https://freshcontext-site.pages.dev/

GitHub:
https://github.com/PrinceGabriel-lgtm/freshcontext-mcp

npm:
https://www.npmjs.com/package/freshcontext-mcp

Final thought

RAG does not only need better retrieval.

It needs a stronger boundary between retrieval and reasoning.

That boundary should not blindly pass everything forward.

It should judge the context first.

FreshContext is my attempt to make that layer explicit, testable, and useful.

candidate context in
decision-ready context out

FreshContext decides what context deserves to reach the model.