▲ 2 r/Rag

I stopped optimizing RAG by vibes and built a retrieval baseline first

I've been learning RAG more seriously and decided to build a measurable baseline before adding hybrid search, reranking, query rewriting, etc.

My intentionally naive setup:

  • Fixed chunks: 1000 chars, no overlap
  • Dense retrieval + Qdrant
  • Top-K = 5
  • 30 eval queries with labeled evidence

First results:

  • Recall@5: 0.917
  • MRR: 0.626
  • nDCG@5: 0.696

The interesting part wasn't the scores, but the failure analysis. I found cases where the correct chunk was retrieved but ranked #4–5, cases where fixed chunking destroyed context, and even cases where my ground truth was incomplete.

My next plan is to change one variable at a time: chunking → hybrid retrieval → reranking → query rewriting, and compare each experiment against this baseline.

For people evaluating RAG in practice: would you improve the dataset first, or start running controlled retrieval experiments with this small benchmark?

reddit.com
u/AnneLister_ — 8 days ago

What is the right tool granularity for a football-analysis agent?

While building a football analysis agent, I realized that the hard part is not connecting an LLM to match data.

It is deciding what the agent should be allowed to do with that data.

For example, if someone asks:

“Why did this midfielder receive a 7.4 rating?”

I do not want to dump every match statistic into the context and ask the model to invent an explanation.

My current approach is to let the agent investigate the evidence step by step:

- retrieve the player’s match metrics
- inspect the rating breakdown
- check passing, chance creation, turnovers, or shot quality when relevant
- explain which factors actually moved the rating

That raises an interesting tool-design question.

A single `analyze_everything()` tool feels like a black box. But dozens of tiny tools such as `get_pass_count()` and `get_key_passes()` create too many decisions and make the agent harder to guide.

I’m experimenting with a middle layer: composable tools that represent meaningful football-analysis operations rather than raw database fields.

For people building sports analytics, agentic systems, or explainable AI: how would you choose the right level of tool granularity here?

reddit.com
u/AnneLister_ — 11 days ago

What is the right tool granularity for a football-analysis agent?

While building a football analysis agent, I realized that the hard part is not connecting an LLM to match data.

It is deciding what the agent should be allowed to do with that data.

For example, if someone asks:

“Why did this midfielder receive a 7.4 rating?”

I do not want to dump every match statistic into the context and ask the model to invent an explanation.

My current approach is to let the agent investigate the evidence step by step:

- retrieve the player’s match metrics
- inspect the rating breakdown
- check passing, chance creation, turnovers, or shot quality when relevant
- explain which factors actually moved the rating

That raises an interesting tool-design question.

A single `analyze_everything()` tool feels like a black box. But dozens of tiny tools such as `get_pass_count()` and `get_key_passes()` create too many decisions and make the agent harder to guide.

I’m experimenting with a middle layer: composable tools that represent meaningful football-analysis operations rather than raw database fields.

For people building sports analytics, agentic systems, or explainable AI: how would you choose the right level of tool granularity here?
reddit.com
u/AnneLister_ — 11 days ago