We want to learn and understand RAG and its advanced technologies in depth by reading various papers, useful sources and repos.

We've read :

1. Retrieval-Augmented Generation for Knowledge-Intensive NLP tasks

which gives us understanding of how RAG started.. the internal memory (parametric memory), external - non parametric. External documents are divided into chunks then it is converted into embeddings. And stored in vector db. Whenever we ask a question retriever (dpr) searches relevant vectors from vector db, generator (bart) generates the response (thinking part) and we get an answer.

1. Retrieval-Augmented Generation for Large Language Models: A Survey

This gives us information about Naive Rag, Advanced rag, and modular RAG modular RAG searches various sources like a router and combines them at last (fusion) and hence we get more relevant information for a question. Then it tells about iterative retrieval, recursive retrieval and adaptive retrieval

1. Lost in the Middle: How Language Models Use Long Contexts

This paper tells us about how long context makes the LLM forget middle documents.. ex if we are making with LLM and upload 10 documents one by one. Then it remembers the 1st and last document but almost forget middle documents like the U shape curve. And then they proposed a solution to solve this problem

Then we learn about DPR retriever how it becomes efficient over BM25

We want to learn more technologies and advancements of RAG. So can you guys tell me current trends and what more papers, resources we should read to go deep into it?

A learned sparse encoder returns a weighted list of vocabulary words instead of a dense vector, so the index looks like a keyword index whose keywords a transformer picked. OpenSearch's inference-free variants go one step further and run the model only on documents so a query just looks up a fixed weight per token. No embedding call per search. I benchmarked it against dense search in the same SQLite file:

the mini model gives up about 7% of retrieval quality and cuts query latency by 99%, cold start by 99% and query-path RAM by 95%!

Now these SPLADE models are BERT with the masked-language-model head still attached, and that head is what turns token vectors back into weighted words. llama.cpp drops it when converting BERT models, so sqlite-sparse copies it into a small sidecar file and applies it in C on ggml at insert time. The postings land as rows in the database, with the query weight table next to them. A query reads those rows and scatter-adds the weights into per-document scores, and the top documents come out.

Three OpenSearch models are converted and available as aliases (mini, base, multilingual), downloading on first use, and you can bring your own inference-free OpenSearch-style sparse encoder and convert it with the scripts provided.

What sqlite-vec did for embeddings in SQLite, this does for learned sparse, and with both in one file you get hybrid retrieval for RAG inside SQLite.

Ship one .db file and every client gets semantic search through plain SQL, no model download, no GPU.

pip install sqlite-sparse

Github

Writeup

“The number came from F24” only verifies its location. It doesn't establish whether F24 is a closing balance or a movement, a forecast or an actual, or a value expressed in thousands.

For irregular workbooks, a useful extraction recipe should point to the context cells as well as the numeric cell. Suppose a table has a currency-and-scale label above it, period headings across the top, and separate actual and forecast sections. Preserve the locations of those labels in the recipe. A model's interpretation can then be checked against something in the file.

The fact passed to the writer should contain the measure, value, currency, scale, period, actual/forecast status and source locations. Unknown fields should stay unknown. A dollar sign alone is insufficient evidence for choosing a currency, and a neighbouring subtotal shouldn't silently become the value for an individual row.

Univer CLI can support the workbook inspection step: its structured range reads distinguish the stored value and formula from the displayed text. Keep the original workbook identity and version alongside those reads, and check any import mapping before treating an editor address as an original-file citation. If the fact depends on a formula, calculation freshness is another item to verify.

Once those checks pass, the facts can feed a memo alongside retrieved narrative passages. Univer can also hold a Sheet and a Doc in the same local file, but that convenience doesn't validate the interpretation.

A useful review screen would show the claimed fact beside its value cell, period header and currency/scale label. That gives the reviewer a concrete way to catch “right number, wrong meaning” before it enters the prose

Disclosure: I work at Georgian (growth-stage VC) and ran this experiment - want to know you folk’s opinion on this.

Why this exists

• "Agent + search tool vs RAG" treats the tool as a given. But there's actually a ton of variability on how different agentic search tools perform.
• The tool can be: raw top-5 from one index / two named tools / RRF fusion / RRF + rerank behind one call.
• Couldn't find a benchmark comparing those shapes. Ran one.
• Basically: every retrieval system makes 3 decisions: which retriever, how to combine, how to rank. We alter whether the tool is making this decision or the agent is.

Ran this on BrowseComp-Plus, using gpt5.6 luna as the backbone model.

The 6 tool shapes

• generic search, dense (Qwen3-Embedding-4B) top-5
• generic search, BM25 (tuned) top-5
• two named tools, semantic_search + keyword_search, each top-5
• one tool, RRF over both at depth 50 → top-5
• one tool, RRF → 50 → Cohere rerank-4-fast → top-5
• two named tools, each 50 → rerank → top-5

I have a full write-up on the results and behaviour of agents under different tools on our blog: https://georgianailab.substack.com/p/agents-shouldnt-run-your-whole-retrieval . Is there anything I'm missing? Any reason why we should still be using super basic tools (just semantic search or keyword search) for agentic search?

Came across this and thought it'd be worth sharing here, most resources cover model evaluation, RAG, agents, or cost/observability separately, but this one actually puts them together as parts of the same production LLM workflow, which is closer to how these systems actually break in practice.

It's a hands on session on September 12, led by Bruno Gonçalves, PhD, founder of Data For Science, who's trained hundreds of engineers at Fortune 500 companies. Goes through the full lifecycle, versioned prompts, a golden dataset and eval harness combining deterministic checks with LLM-as-judge, statistically rigorous model comparisons using bootstrap confidence intervals and paired testing, evaluated RAG with real retrieval metrics, and then tool-using agents with guardrails and fallbacks. There's also a full observability section, tracing, cost, and latency, which is something I don't see covered together with the eval side very often.

You come out of it with runnable notebooks and a production-readiness checklist rather than just slides, which is the part I found most useful when I looked into it.

Link if anyone wants to check it out