Retrieval quality and scaling
Hybrid search, query rewriting and decomposition, reranking, dense-neighborhood failures at enterprise scale, top-k competition, and retrieval strategy selection.
42%
Best tweets about RAG
50 Best Tweets About RAG (2026)
Discover the best tweets about retrieval-augmented generation, including RAG architecture, chunking, retrieval, evaluation, grounding, and production systems.
Technical RAG pipelines, retrieval quality, chunking, reranking, grounding, evaluation, failure modes, cost, and production experience.
- Creators
- 41
- Updated
Original Xholic analysis
What 50 top RAG posts reveal
Discussion of RAG concentrates on retrieval quality, architecture choices, ingestion and chunking, evaluation, and production controls. Posts describe alternatives or complements to vector retrieval—including structured wikis, graph traversal, caching, and fine-tuning—and emphasize that suitability depends on the corpus, query type, and operating constraints.
- Dominant tone
- Positive
- Median score
- 11.8
- Leading format
- Other
- Recent posts
- 38%
54% of posts
All-time engagement
100% of posts
Published in 90 days
Conversation map
The themes creators return to
RAG architectures and alternatives
Canonical RAG, agentic and corrective loops, context engineering, CAG, vectorless/document-structure retrieval, and deciding when RAG is appropriate.
36%
Ingestion, parsing, and chunking
PDF/web extraction, structure-aware and late chunking, metadata, deduplication, idempotent indexing, document hygiene, and preserving tables or layouts.
30%
Graph RAG and structured memory
Knowledge graphs, graph traversal, entity relationships, temporal and causal provenance, multi-hop retrieval, and long-term agent memory.
22%
RAG evaluation and benchmarks
Retrieval and answer metrics, customer-data evaluation, realistic enterprise benchmarks, corpus-scale tests, golden sets, and failure attribution.
22%
Grounding, provenance, and uncertainty
Citation-backed answers, evidence-to-claim traceability, no-answer behavior, factual support, and distinctions between retrieved documents and ground truth.
20%
Production operations and failure modes
Observability, stage-by-stage debugging, retries and fallbacks, freshness, tenant isolation, ACLs, PII, reliability, and token economics.
20%
Multimodal and visual RAG
Retrieval over videos, images, PDFs, tables, charts, screenshots, and rendered web pages rather than text alone.
18%
Tone and stance
Sentiment Positive leads
Author posture Supportive leads
Performance benchmark
- Median likes
- 20
- Median reposts
- 4
- Median replies
- 3
- Median views
- 2.3K
Posts with media make up 76% of this collection. Their median all-time score is 12.2, compared with 7.20 for text-only posts.
Format mix
- Other 100% · score 11.8
Consensus and debate
Where creators agree, and where they do not
Shared view
Retrieval quality needs explicit pipeline work
Posts recommend inspecting retrieval stages rather than treating generation as a black box. Techniques discussed include hybrid retrieval, query rewriting, reranking, and stage-by-stage debugging of the evidence pipeline.
Shared view
Ingestion and chunking are retrieval-critical
Posts identify parsing quality, document structure, stable IDs, metadata, deduplication, and chunk boundaries as operational concerns that affect what can be retrieved.
Shared view
Evaluation should include task- and corpus-relevant tests
Posts argue for evaluating on customer data and realistic corpus sizes, and describe separately assessing retrieval/context behavior and answer behavior rather than relying only on broad public leaderboards.
Shared view
Citation and abstention controls are recurring recommendations
Several posts recommend citations or claim-to-source links, along with no-answer behavior, to make answers more traceable when evidence is missing or retrieval is weak.
Open debate
Vector retrieval versus structure-aware retrieval
Posts promoting document-tree or graph traversal argue that vector similarity can miss cross-section or relational questions. Other posts describe hybrid lexical-plus-vector retrieval as an option, rather than relying on vectors alone.
Open debate
RAG is not the only knowledge-access pattern
Some posts describe structured wikis, cached context, or fine-tuning as ways to reduce or replace retrieval for particular use cases. Others describe agentic loops as an extension for queries that need iterative retrieval or tool selection.
Open debate
Grounding terminology is contested
One post defines RAG as grounding generation in external sources, while another argues that retrieved documents should not be equated with ground truth.
What performs
Patterns behind standout posts
Architecture posts had the highest theme-level median score
The “RAG architectures and alternatives” theme had the highest supplied median all-time score, 58.36. Its evidence set includes the two largest supplied outliers: the LLM knowledge-base post and the graph-based code-retrieval post.
One benchmark post reports degradation at larger corpus sizes
A post describing EnterpriseRAG-Bench reports vector-search accuracy falling from 90.7% at 5K documents to 50.6% at 500K, while BM25 fell from 85.8% to 68.4%. The post recommends testing at realistic corpus volumes.
Media was common and had a higher supplied median score
Deterministic analytics reports media on 38 of 50 tweets (76%), with a 12.19 media median all-time score versus 7.2 for text-only tweets.
Statistical standouts
- View standout post 1 Score 19534.1 · 1659.65× median
- View standout post 2 Score 3464.2 · 294.32× median
- View standout post 3 Score 515.6 · 43.81× median
- View standout post 4 Score 449.7 · 38.21× median
- View standout post 5 Score 239.1 · 20.31× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
-
1. Abhishek Singh
@0xlelouch_
2 posts
-
2. Akshay 🚀
@akshay_pachaar
2 posts
-
3. Aurimas Griciūnas
@Aurimas_Gr
2 posts
-
4. Nainsi Dwivedi
@NainsiDwiv50980
2 posts
-
5. Paul Iusztin
@pauliusztin_
2 posts
-
6. smrati tiwari
@smratitiwa86867
2 posts
Selected top voices cover evaluation, architecture, and operations
Akshay Pachaar’s supplied posts cover enterprise-scale retrieval benchmarking and local video RAG. Aurimas Griciūnas’s posts discuss CAG/RAG trade-offs and MCP-based agentic retrieval. 0xlelouch_’s supplied posts are production RAG mistake checklists.
Operationally specific controls appear across creator posts
Creator posts enumerate controls such as labeled evaluation queries, metadata and ACLs, reranking, cache separation, retries, observability, and citations.
Since the previous snapshot
What changed since Aug 12, 2026
- 68% of the selected posts remained.
- The creator count changed by -1.
- The leading sentiment remained stable.
How this analysis was made
Themes, sentiment, stance, and post format are classified per tweet. All counts, shares, medians, creator concentration, freshness, and performance comparisons are then calculated directly from the published snapshot.
Xholic's all-time score compares engagement while accounting for reach, post age, and creator consistency. It is used for relative comparisons within this collection.
This report analyzes the exact 50-post snapshot shown below. AI identifies editorial categories and drafts explanations; all statistics are calculated from the snapshot, and every narrative claim is checked against cited posts before publication.
Best RAG tweets
Top RAG tweets from 41 creators
Ranked 01–50
- 01
@karpathy ·
LLM Knowledge Bases Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So: Data ingest: I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them. IDE: I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides). Q&A: Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale. Output: Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base. Linting: I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into. Extra tools: I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries. Further explorations: As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows. TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.
- 02
@MillieMarconnni ·
🚨 BREAKING: A developer on GitHub just built a tool that turns any GitHub repo into an interactive knowledge graph and open sourced it for free. It's called GitNexus. Think of it as a visual X-ray of your codebase but with an AI agent you can actually talk to. No server. No subscription. No enterprise sales call. Here's what it does inside your browser: → Parses your entire GitHub repo or ZIP file in seconds → Builds a live interactive knowledge graph with D3.js → Maps every function, class, import, and call relationship → Runs a 4-pass AST pipeline: structure → parsing → imports → call graph → Stores everything in an embedded KuzuDB graph database → Lets you query your codebase in plain English with an AI agent Here's the wildest part: It uses Web Workers to parallelize parsing across threads so a massive monorepo doesn't freeze your tab. The Graph RAG agent traverses real graph relationships using Cypher queries not embeddings, not vector search. Actual graph logic. Ask it things like "What functions call this module?" or "Find all classes that inherit from X" and it traces the answer through the graph. This is the kind of code intelligence tool enterprise teams pay thousands per month for. It runs entirely in your browser. Works with TypeScript, JavaScript, and Python. 100% Open Source. MIT License. Repo: https://t.co/RzIoLR2vAe
Watch video
- 03
@AlphaSignalAI ·
Someone removed the vector database from RAG and accuracy jumped to 98.7%. Most RAG systems chunk your documents, embed them as vectors, then retrieve by similarity. The core assumption: similar text means relevant text. That assumption fails on professional documents. Ask "what were the debt trends in Q3?" and vector search returns chunks that look like your question. The real answer sits in an appendix, split across three sections, with zero semantic overlap. Traditional RAG never finds it. PageIndex is an open-source repo that removes the vector database entirely. Inspired by AlphaGo, it builds a tree index from your document. Then it reasons through it like a human expert would. Instead of pattern matching, the model navigates sections logically. "Debt trends live in financial summaries or Appendix G. Let's look there." What changes: 1. No chunking that breaks cross-section context 2. Retrieval traceable to exact pages 3. Multi-step reasoning over document structure It scored 98.7% on FinanceBench. Perplexity scored 45%. GPT-4o hit 31%.
- 04
- 05
@akshay_pachaar ·
A tricky LLM interview question: Your RAG system scores 90% retrieval accuracy on 5k company docs. But scaling to 500k docs drops the accuracy to just 50%, with the same embedding model and retriever. Why did this happen? The simplest answer is that more documents mean more competition for the top-k retrieval slots. That is true, but it doesn't explain why accuracy drops this dramatically. The answer comes down to how enterprise docs are distributed in the embedding space. Today, a single product decision in a company generates meeting transcripts, Slack threads, Confluence docs, Jira tickets, and email threads. They are related to the same event, so they all land in a similar region of the embedding space. As the company operates over months, this pattern repeats for every project/customer/roadmap, and the embedding space fills up with clusters of closely related documents. But all related docs don't contain the same facts. → Slack thread covers the decision made → Jira has the implementation deadline → Confluence has the technical spec → Email thread has the customer request When a query is about a specific fact (like a deadline), the answer lives in one of those docs. At a 5K corpus size, there might be 3-5 docs touching that topic, and the correct one easily lands in the top-k results. But at a 500K corpus size, there could be 40-60 total docs, and the one containing the actual answer can easily get pushed out of the top-k by other topically relevant docs, degrading retrieval. A recent research paper from Onyx documented this. The researchers used their newly open-sourced EnterpriseRAG-Bench dataset. It has 500k+ synthetic enterprise documents spread across Slack, Gmail, Jira, GitHub, Confluence, Google Drive, HubSpot, Fireflies, and Linear, with realistic noise like misfiled documents, near-duplicates, and conflicting versions. They ran the same retrievers at five corpus sizes from 5K to 500K. → Vector search accuracy dropped from 90.7% at 5K documents to 50.6% at 500K docs. → BM25 degraded more gracefully, from 85.8% to 68.4%. → At every scale, higher neighborhood density in the embedding space monotonically correlated with lower recall. The practical implication here is that retrieval accuracy on a 5k test set tells you almost nothing about production-scale performance. Always test at a realistic volume to measure the neighborhood density in your embedding space to estimate how much headroom the retriever actually has. The entire EnterpriseRAG-Bench dataset (500K docs with questions, and the whole evaluation harness) is open-source. Run your retriever against it at 5K, then at 500K, and see where your own accuracy curve breaks. I have shared the GitHub repo in the replies.
- 06
@techNmak ·
What is RAG? What is Agentic RAG? > Retrieval-Augmented Generation (RAG) < ---------------------------------------------- Retrieval-Augmented Generation (RAG) is an architecture that enhances a language model’s outputs by grounding them in external knowledge sources at inference time. Instead of relying solely on parameters learned during training, RAG systems dynamically retrieve relevant information and inject it into the model’s context before generation. => Canonical RAG workflow > A user submits a query. > The query is embedded and matched against a pre-indexed corpus (commonly stored in a vector database). > The top-K most relevant document chunks are retrieved. > Retrieved context is appended to the original query. A language model generates a response conditioned on this augmented input. => Primary objective To reduce hallucinations and improve factual accuracy by grounding generation in verifiable, external context. => Key limitation > Traditional RAG is a single-shot pipeline: > No explicit reasoning or planning > No validation of retrieved evidence No iterative refinement if retrieval or generation is suboptimal The system assumes the first retrieval and generation pass is sufficient, which often breaks down for complex, ambiguous, or multi-hop queries. > Agentic RAG < ------------------ Agentic RAG extends standard RAG by introducing autonomous decision-making agents that can reason, plan, evaluate, and adapt across multiple steps. Rather than a static retrieval → generation flow, Agentic RAG operates as a closed-loop, goal-driven system. => Core idea Retrieval and generation are no longer treated as isolated steps, they become actions taken by agents in pursuit of a higher-level objective: producing a correct, complete, and useful answer. => Typical Agentic RAG Architecture 1./ Planning Agent > Interprets the user’s intent > Decomposes complex queries into sub-tasks > Determines what information is required and from which sources 2./ Retrieval Agent > Dynamically reformulates search queries > Retrieves information from: - Vector databases - Structured databases - APIs - Tools or live data sources > Can perform multi-hop retrieval when needed 3./ Generation Agent > Synthesizes retrieved evidence into a coherent response > Reasons across multiple sources > Maintains traceability between claims and evidence 4./ Evaluation (Judge) Agent > Critically reviews the generated output > Checks for completeness, correctness, and alignment with the original query > Decides whether to: - Accept the answer - Refine retrieval - Re-plan and regenerate This feedback loop can repeat until predefined quality criteria are met.
- 07
@Aurimas_Gr ·
Fusion of 𝗥𝗔𝗚 (Retrieval Augmented Generation) and 𝗖𝗔𝗚 (Cache Augmented Generation). You must understand fundamentals behind this architecture to save costs and reduce your system latency efficiently. So how can you benefit from it as AI Engineer? Let’s see what it looks like and what additional considerations should be taken into account. Here are example steps to implement CAG + RAG architecture: 𝘋𝘢𝘵𝘢 𝘗𝘳𝘦𝘱𝘳𝘰𝘤𝘦𝘴𝘴𝘪𝘯𝘨: 𝟭. We use only rarely changing data sources for Cache Augmented Generation. On top of the requirement of data changing rarely we should also think about which of the sources are often hit by relevant queries. Once we have this information, only then we pre-compute all of this selected data into a KV Cache of the LLM. Cache it in memory. This only needs to be done once, the following steps can be run multiple times without recomputing the initial cache. 𝟮. For RAG, if necessary, precompute and store vector embeddings in a compatible database to be searched later in step 4. Sometimes simpler data types are enough for RAG, a regular database might suffice. 𝘘𝘶𝘦𝘳𝘺 𝘗𝘢𝘵𝘩: We can now utilise the preprocessed data. 𝟯. Compose a prompt including user query and the system prompt with instructions on how cached context and retrieved external context should be used by the LLM. 𝟰. Embed a user query to be used for semantic search via vector DBs and query the context store to retrieve relevant data. If semantic search is not required, query other sources, like real time databases or web. 𝟱. Enrich the final prompt with external context retrieved in step 4. 𝟲. Return the final answer to the user. 𝘚𝘰𝘮𝘦 𝘊𝘰𝘯𝘴𝘪𝘥𝘦𝘳𝘢𝘵𝘪𝘰𝘯𝘴: ➡️ Context window is not infinite and even while some models boast enormous context window sizes, the needle in the haystack problem has not yet been solved so use available context wisely and cache only the data you really need. ✅ For some business cases, specific datasets are extremely valuable to be passed to the model as cache. Think about an assistant that has to always comply with a lengthy set of internal rules stored in multiple documents. ✅ While CAG has been popularised for Open Source just recently, it is already viable for some time via Prompt Caching features in OpenAI and Anthropic APIs. It is really easy to start prototyping there. ✅ You should always separate hot and cold data sources, only use cold (data that changes rarely) in your cache, otherwise the data will go stale and the application will go out of sync. ❌ Be very careful about what you cache as the data will be available for all users to query. ❌ It is very hard to ensure RBAC for cached data unless you have a separate model with its own cache per role. Have you used the combination already?
- 08
- 09
@techNmak ·
Your LLM inference is burning 50% of its compute on work it has already done. If you're running RAG or Multi-Turn Chat, you're recomputing the KV Cache for the same documents over and over again. I found the open-source library that fixes this at the infrastructure level. It's called LMCache. It turns KV cache from a temporary state into reusable AI-native knowledge - persistent, shareable, and storage-agnostic. The "Cheat Code" for AI Infrastructure Instead of the cache dying when a request finishes, LMCache offloads it to a shared layer - CPU, Disk, Redis, Cloud Bigtable, or enterprise storage like VAST and DDN. This unlocks architecture patterns that were previously impossible: 1/ Instant RAG Process a 100-page PDF once. Store the KV cache. Every subsequent query against that doc starts with near-zero TTFT. 2/ Disaggregated Serving Run heavy Prefill on H100s. Stream the cache to cheaper L4s for Decoding. Pay H100 prices only where you must. 3/ Context Sharing 1000 users asking about the same document? Compute it once. Serve everyone from cache. 4/ Multi-Engine Freedom Works with vLLM, SGLang, and more, and you can switch between them without losing your stored caches. Fully vendor-neutral. 🚀 15x throughput gain in multi-round QA workloads ⚡ 3-10x reduction in Time-To-First-Token Who's already betting on this? Netflix. Samsung. Google Cloud. AWS. Tencent. Hugging Face. NVIDIA. Intel. Cohere. Stop letting your GPUs do the same homework twice. Here's the GitHub: https://t.co/6TQgr63O5l
- 10
- 11
@Aurimas_Gr ·
Integrating 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚 Systems via 𝗠𝗖𝗣 👇 If you are building RAG systems and packing many data sources for retrieval, most likely there is some agency present at least at the data source selection for retrieval stage. This is how MCP enriches the evolution of your Agentic RAG systems in such case (𝘱𝘰𝘪𝘯𝘵 2.): 𝟭. Analysis of the user query: we pass the original user query to a LLM based Agent for analysis. This is where: ➡️ The original query can be rewritten, sometimes multiple times to create either a single or multiple queries to be passed down the pipeline. ➡️ The agent decides if additional data sources are required to answer the query. 𝟮. If additional data is required, the Retrieval step is triggered. We could tap into variety of data types, few examples: ➡️ Real time user data. ➡️ Internal documents that a user might be interested in. ➡️ Data available on the web. ➡️ … 𝗧𝗵𝗶𝘀 𝗶𝘀 𝘄𝗵𝗲𝗿𝗲 𝗠𝗖𝗣 𝗰𝗼𝗺𝗲𝘀 𝗶𝗻: ✅ Each data domain can manage their own MCP Servers. Exposing specific rules of how the data should be used. ✅ Security and compliance can be ensured on the Servel level for each domain. ✅ New data domains can be easily added to the MCP server pool in a standardised way with no Agent rewrite needed enabling decoupled evolution of the system in terms of 𝗣𝗿𝗼𝗰𝗲𝗱𝘂𝗿𝗮𝗹, 𝗘𝗽𝗶𝘀𝗼𝗱𝗶𝗰 𝗮𝗻𝗱 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗠𝗲𝗺𝗼𝗿𝘆. ✅ Platform builders can expose their data in a standardised way to external consumers. Enabling easy access to data on the web. ✅ AI Engineers can continue to focus on the topology of the Agent. 𝟯. Retrieved data is consolidated and Reranked by a more powerful model compared to regular embedder. Data points are significantly narrowed down. 𝟰. If there is no need for additional data, we try to compose the answer (or multiple answers or a set of actions) straight via an LLM. 𝟱. The answer gets analyzed, summarized and evaluated for correctness and relevance: ➡️ If the Agent decides that the answer is good enough, it gets returned to the user. ➡️ If the Agent decides that the answer needs improvement, we try to rewrite the user query and repeat the generation loop. Are you using MCP in your Agentic RAG systems? Let me know about your experience in the comment section 👇
- 12
@dair_ai ·
// Graph Augmented Associative Memory for Agents // Long-term memory for agents is still an unsolved problem. Flat RAG loses structural relationships, and knowledge graphs miss conversational associations. New research proposes combining both through a hierarchical approach. GAAMA is a graph-augmented associative memory that constructs a concept-mediated hierarchical knowledge graph through episode preservation, LLM-based fact extraction, and higher-order reflection synthesis. It uses four node types connected by five edge types, with retrieval combining semantic search and graph-traversal ranking. On the LoCoMo-10 benchmark, GAAMA achieves 78.9% mean reward, outperforming HippoRAG and tuned RAG baselines. Multi-session agents need memory that captures both facts and their relationships across conversations. GAAMA demonstrates that graph-augmented retrieval consistently beats semantic-only methods, and that higher-order reflections, not just raw fact storage, are key to reliable recall. Paper: https://t.co/b9mWe4sN8c Learn to build effective AI agents in our academy: https://t.co/LRnpZN7L4c
- 13
@alexxubyte ·
Microsoft Foundry runs AI agents for 80,000+ enterprises. We wanted to understand what it takes to build AI agents at this scale, so we spoke with @amrcn_werewolf , VP of Product for Microsoft Core AI. He explained the two high level engineering ideas behind the platform, summarized in the diagram below. 1. Retrieval as a Subagent Classic RAG is a one-shot lookup. When the first retrieval fails, the whole agent fails. Foundry wraps retrieval in an agentic loop, following these steps: Step 1: The retrieval subagent plans which sources to query. Step 2: Queries the knowledge sources: docs, wikis, and blob storage. Step 3: Evaluates the results. If bad, then triggers another iteration. Step 4 - Returns a grounded answer with citations. When iteration runs out, it returns a structured "I don't know" instead of hallucinating. 2. Eval and Optimizer Loop The second big idea in Foundry is an automated loop that optimizes the agent: Step 1: Rubrics check the agent's specific behaviors. All pass? The agent ships. A rubric fails? The Agent Optimizer kicks in. Step 2: It generates candidate fixes in parallel. Step 3: It scores each candidate against the rubrics. Step 4: The best one becomes the new agent version. The biggest lesson from Microsoft's team is that the harness matters as much as the model. Full breakdown: https://t.co/q01BnrfazG
- 14
@PythonDvz ·
Most people building AI products can’t answer this: “What’s the actual difference between an LLM, RAG, an AI Agent, and Agentic AI?” They’re not the same. Confusing them leads to wrong tools, wasted budgets, and over-engineered solutions. Here’s the breakdown. — Layer 1: LLM — The Brain The foundation of every AI system. Understands language, reasons through problems, generates responses — but only from training data. No live data. No actions. No memory beyond the conversation. Key capabilities: Chain-of-thought reasoning, few-shot learning, prompt engineering, transformer architecture. — Layer 2: RAG — The Library Card Connects your LLM to external knowledge documents, databases, internal wikis before generating a response. Your AI stops guessing and starts referencing. Key capabilities: Vector search, document chunking, retrieval pipelines, hybrid search, grounded answer generation. — Layer 3: AI Agent — The Doer Uses the LLM as its reasoning core but wraps it with tools and memory to take real-world actions. Moves from answering to acting. Key capabilities: Tool use, API calling, code execution, task tracking, ReAct framework, short and long-term memory. — Layer 4: Agentic AI — The Team Multiple specialised agents working in parallel, sharing memory, assigning roles, and adapting in real time. You are not prompting anymore. You are deploying. Key capabilities: Multi-agent orchestration, autonomous goal planning, MCP, hierarchical task execution, role-specific agents. — Which do you actually need? → Q&A or content generation? LLM → Accurate answers from your data? RAG → Automated real-world workflows? AI Agent → Fully autonomous operations? Agentic AI Biggest mistake? Jumping to Agentic AI when RAG solves 80% of the problem at 20% of the complexity. Start with the right layer. Scale from there.
- 15
@om_patel5 ·
THIS GUY TAUGHT HIS 60 YEAR OLD DAD CLAUDE CODE AND GIT WITH ZERO CODING EXPERIENCE his dad teaches geology. has never written a line of code in his life he showed him the basics of claude and how git works back in feb fast forward to today and his dad built a fully functional RAG system on his own for analyzing and querying his mineral documents RAG (retrieval augmented generation) is when you feed your own documents into an AI so it can search through them and answer questions based on YOUR data instead of its general training this is definitely not a simple chatbot wrapper. this is an advanced system (for someone with zero prior experience) that a geology professor built BY HIMSELF his son is a developer and even he was impressed. said it finally made him understand why vibe coding has become such a thing a proper end-to-end solution engineer is still leagues ahead of someone just prompting an AI. but it is surprisingly impressive how claude code can elevate someone to the level of an average developer with no experience the barrier to building software is gone
- 16
@GithubProjects ·
RAGLite is a lightweight Python toolkit for building retrieval-augmented generation applications on DuckDB or PostgreSQL with late chunking. - Choose any LLM provider via LiteLLM or local llama-cpp-python models - Hybrid search using native keyword and vector search in DuckDB or PostgreSQL - Multi-vector chunk embedding with late chunking and contextual chunk headings - Optimal sentence and semantic chunking via binary integer programming Explore it here: https://t.co/TP2iAodk2t
Watch video
- 17
@NainsiDwiv50980 ·
🚨WEB SCRAPING IS DEAD🚨 They've created PixelRAG. An open source system that skips parsing HTML. Instead of converting a website into text... it takes a screenshot. And then a vision-language model reads the response directly from the pixels. Brutal. Because traditional scraping breaks a ton of information: → tables → charts → layouts → columns → buttons → PDFs → poorly structured pages All that gets lost when you convert a website into plain text. PixelRAG does something much simpler: it indexes the page just as a person sees it. The team has created a full visual index of Wikipedia: +30 million screenshots. And it still beats the best text-based RAG by 18.1% on QA. It also has a plugin for Claude Code. Basically, it gives Claude eyes. You pass it a URL, an arXiv paper, or your local website… and Claude doesn't scrape the DOM. It looks at it. How it works: → renders websites, PDFs, and images into tiles → embeds them with Qwen3-VL-Embedding → builds a FAISS index → searches visually over pixels All open source under Apache-2.0. Link to the repo in the comments 👇🏻
Watch video
- 18
@0xlelouch_ ·
Top 10 mistakes devs make with RAG in production: 1) Treating chunking like formatting. Wrong size, no overlap, no structure-aware splits. 2) No stable doc IDs. Re-ingest creates duplicates, old chunks still rank. 3) Skipping metadata. No source, tenant, timestamp, ACLs, language, doc type. 4) No eval set. Shipping prompts without 50 to 500 labeled queries and expected citations. 5) TopK defaults forever. k=5, no reranker, no diversity, no freshness bias. 6) Ignoring token economics. 20 chunks stuffed into context, latency spikes, cost doubles, accuracy drops. 7) Weak retries + timeouts. Vector DB hiccup turns into a retry storm and thundering herd. 8) Bad indexing choices. Wrong distance metric, no filters indexed, hybrid search bolted on after. 9) No observability. Missing per-stage timing (embed, retrieve, rerank, generate) and hit rate by query type. 10) No guardrails on answers. Not requiring citations, not detecting no-answer, returning confident fiction on empty recall
- 19
@vivek_naskar ·
Karpathy dropped a gist called LLM Wiki and it's worth reading if you do any kind of deep research or writing. The problem with RAG is that knowledge never accumulates. Every query starts from scratch, re-deriving the same connections from raw documents. His approach: the LLM incrementally builds a markdown wiki from your sources. When a new source comes in, it reads it, updates relevant pages, notes contradictions, and maintains cross-references across the whole wiki. Three layers: raw sources you never touch, an LLM-owned wiki, and a schema file that keeps the LLM behaving like a disciplined maintainer. The bottleneck for personal knowledge bases was never the reading. It was the boring maintenance work that nobody wanted to do. https://t.co/bk9UhAoo18
- 20
@BritneyMuller ·
"Grounding" Doesn't Mean What You Think It Means 🗺️ Words matter, especially when they're quietly reshaping how an entire industry thinks. "Grounding" comes from "ground truth," rooted in statistics and originally cartography, where it literally meant going outside to verify that your map matched reality. In some AI models, "ground truth" is the objectively correct real-world data, like sensor readings or medical records, used to anchor the model to reality. Not documents. Not web pages. Reality. The core problem with LLMs is that there's no ground truth signal during training or generation. The model isn't checking its answer against the facts; it's only predicting the next most likely word. What Microsoft, a company I deeply respect + admire, calls "grounding" is actually RAG (Retrieval-Augmented Generation): retrieving web documents to supplement a response. Useful! But web text is written by humans, about reality, not reality itself. Those documents can be wrong, biased, SEO-manipulated, or outdated. RAG is better-informed guessing. True "grounding" is fundamentally a different thing. The uncomfortable part: Microsoft's own AI Guide features a quote from me where, after significant pushback on their "grounding" framing during a long interview, I said: "RAG does help the LLM ground its response in information from the web, but it's worth remembering that not everything online is true." The caveat got published. The correction didn't & the term has escaped into GEO AIO E-I-E-I-O gauntlet. I've since watched real people repeat versions of Microsoft's definition & treat it as fact. And I don't blame them. They're trying to keep up with all of these changes. Microsoft's new "Grounding Queries" metric in Bing Webmaster Tools makes this even more confusing. Those aren't user queries. They're background searches AI quietly generates when a user submits a prompt. For example, when you ask "should I bring an umbrella in Seattle?" the AI might internally generate "Seattle weather today" to inform its response. Calling those "grounding queries" buries an already-misused term one layer deeper. I raised this concern with Microsoft & suggested alternatives like "Retrieval Queries" or "AI Queries," which I feel would be more accurate and less confusing but to no avail. The real irony? Microsoft employs SO many world-class AI researchers. They know the difference. By rebranding RAG and synthetic AI queries as "grounding," a precise technical term has now become a marketing buzzword. SEOs are now optimizing for a word we don't have a shared definition of. And when AI researchers hear you use "grounding" this way, it'll erode your credibility. As AI continues to reshape industries, it's more important than ever for us to understand these nuances. By learning the true meaning behind AI terms & tech we can communicate more effectively, make better decisions & drive real results. 19 Days until the next Actionable AI For Marketers Course 🎓
- 21
- 22
@Al_Grigor ·
Basic RAG: you search for a few relevant chunks, pass them to the model, and generate an answer. That is often a good starting point, but in practice it's not enough for more complex tasks. Once your application needs to: - Search multiple times - Decide what to look for next - Choose between tools - Recover from weak intermediate results you need something more structured than a single retrieve-and-answer step. At Data Makers Fest 2026, I'll be running a hands-on tutorial on exactly that. Date: 4 May Place: Alfândega do Porto, Portugal You'll learn how to go from a simple RAG system to an agentic search workflow. If you know Python and have an OpenAI-compatible API key, you'll be able to follow along. By the end, you'll have a working system and a much clearer picture of how these applications are actually built. Data Makers Fest is also a good format for this kind of learning. The hands-on tutorials are half-day sessions with small groups, so there's enough time to build, test properly, and understand what's happening. Use DATATALK10 for 10% off: - You can join just the tutorial: https://t.co/TkWwVmelVy - Or join the full conference for two days of talks, expo, and networking: https://t.co/gwZLGWCiAF Tutorial tickets are available until April 24.
- 23
@0xlelouch_ ·
Top 10 mistakes devs make with RAG systems: 1) Treating chunking like a one-time script. No overlap, no structure, no per-doc tuning. 2) Stuffing everything into one index. No namespaces, no per-tenant filters, no doc-type separation. 3) Using cosine search only. No hybrid (BM25 + vectors), no reranker, no query rewriting. 4) Bad metadata. Missing source, timestamp, ACLs, and stable doc IDs, so dedupe and traceability fail. 5) No ingestion hygiene. PDFs parsed wrong, tables lost, OCR noise, no content validation. 6) Ignoring freshness. No incremental updates, no tombstones, no re-embed on model/version change. 7) Context window abuse. Shoving 20 chunks into the prompt instead of selecting 3-5 good ones. 8) No grounding checks. The model answers without citations or quote spans tied to retrieved text. 9) Weak reliability. No timeouts, retries with jitter, circuit breakers, or fallbacks when vector DB is slow. 10) No observability. Missing per-query logs: query, topK IDs, scores, latency breakdown, token cost, and user-visible hit rate
- 24
@TheTuringPost ·
MathNet - a new interesting global multimodal benchmark from @MIT for mathematical reasoning and retrieval It's a dataset of 30,676 Olympiad-level problems from 47 countries, 17 languages, and 143 competitions over 4 decades, with expert solutions. It defines 3 tasks: - problem solving - math-aware retrieval - RAG Top models achieve 78.4% accuracy, while retrieval Recall@1 is ~5%. RAG improves performance up to 12%, highlighting retrieval quality limitations and shows embedding models struggle.
- 25
@hasantoxr ·
I didn't know you could benchmark your entire RAG stack against ChatGPT, Claude, and Gemini in one run. It's called EnterpriseRAG-Bench. 500k documents. 500 questions. The first benchmark built on data that actually looks like a company's data. Not Wikipedia articles. Not research papers. Slack messages where decisions got made but never documented. Google Docs that stopped being updated six months ago. Email threads. Call transcripts. The messy, inconsistent, real stuff your AI has to search through every day. Every other RAG benchmark tests retrieval on clean, long-form text with obvious answers. EnterpriseRAG-Bench tests it on ambiguous conversations, huge variations in document size, contradictory information, and multi-hop reasoning across hundreds of thousands of files. Plus baseline numbers for BM25, pure vector search, and an agent with bash access. If you're building a RAG system, this is the only benchmark that tells you how it actually performs. 100% Opensource.
- 26
@_vmlops ·
MICROSOFT BUILT A TOOL THAT TURNS ANY FILE INTO CLEAN MARKDOWN FOR LLMS ▫️ converts PDF, Word, Excel, PowerPoint, images, audio, HTML, CSV/JSON/XML, ZIP files, EPubs, even YouTube URLs ▫️ keeps headings, tables, and links intact built for RAG pipelines, not just human reading ▫️ supports Azure Document Intelligence for higher-quality extraction on scanned docs ▫️ simple CLI: markitdown file.pdf -o output.md, or use it as a Python library 172k stars, built by the AutoGen team I just turned a 163-page PDF into markdown with one command and honestly wasn't expecting it to just... work had this "Agentic AI" PDF sitting around, dreading the thought of manually cleaning it up for later use ran this instead: markitdown "Agentic AI.pdf" -o "Agentic AI.md" headings, tables, lists stayed intact no copy-pasting, no reformatting, no cleanup pass just one command and it was done
Watch video
- 27
@ahmadafterhours ·
Spent the week going deep on how AI agents actually learn. Here’s what I found: Most agents run on RAG — you embed your data, they retrieve similar chunks at query time. It works, but it has a ceiling. No relationships between facts. No sense of what changed. No reasoning across chains. Knowledge graphs fix this. Instead of retrieving chunks, agents traverse structure: prospect → company → tech stack → past objections → what converted Every fact is timestamped. When something changes, the old fact is invalidated — not deleted. Agents always reason from current truth. And every interaction writes back into the graph. A deal closes, a prospect responds, an outreach converts — all of it feeds the system. The result: agents that don’t just retrieve information. They understand your business, track how it evolves, and get sharper every day.
- 28
@itsafiz ·
PII in your RAG pipeline isn't just a compliance risk. It's a retrieval quality problem. Once names, emails, or SSNs are embedded in your vector store, you can't easily remove them. And they mess with your semantic search. @tonicfakedata Textual + @Haystack_AI just solved this. Here's how 🧵 👇
Watch video
- 29
@shivam74689 ·
Day 64 — Becoming AI Engineer Today I learned one of the most important lessons in building production RAG systems: When an AI system gives bad answers, the problem is usually not the LLM. The problem is often the evidence pipeline behind it. I spent today debugging and rebuilding the retrieval pipeline of my Enterprise Knowledge Graph Agentic RAG system end-to-end. The first challenge was not retrieval itself. It was getting the entire pipeline stable. Several integration issues between the Citation Manager, Context Compressor, Enterprise Agent, and Bootstrap process were preventing the system from running correctly. After fixing those connections, I moved from debugging the whole system to validating each component independently. I tested every retrieval layer: • Qdrant vector search for semantic retrieval. • BM25 keyword search for exact term matching. • Hybrid Retrieval combining semantic and lexical signals. • Reciprocal Rank Fusion (RRF) for merging multiple ranked results. Each component was returning relevant results individually, which confirmed the retrieval foundation was working. But then I looked deeper. Instead of only checking the final generated answer, I inspected the raw evidence flowing through every stage of the pipeline. That changed everything. The real problems were upstream. The PDF extraction process was producing noisy and poorly structured text. The chunking strategy was also creating problems: • Important definitions were being split across chunk boundaries. • Fixed-size character splitting ignored semantic structure. • Small chunks with low overlap were giving the LLM incomplete context. This reinforced a major principle: Bad ingestion creates bad retrieval. Bad retrieval creates bad generation. No amount of reranking or a stronger LLM can fully recover from poor-quality context. I also discovered a duplicate chunk issue. Old vectors from previous experiments were still stored inside Qdrant, while the chunking process was creating additional low-quality boundaries. To fix this, I completely reset the knowledge stores: • Cleared Qdrant vector storage. • Reset Neo4j graph storage. • Regenerated embeddings from scratch. • Created a new structured sample document designed specifically to stress-test enterprise retrieval. After rebuilding the index, I validated the complete retrieval flow again. The improvements were clear: • Retrieval returned distinct and relevant chunks. • Hybrid search correctly combined semantic and keyword-based matches. • Context compression successfully reduced multiple retrieved chunks into concise, useful context. One of the biggest lessons from today: Production AI engineering is less about continuously adding new components and more about making every existing component measurable, debuggable, and reliable. A RAG system should not be treated as a black box. You need visibility into every stage: Document → Extraction → Cleaning → Chunking → Embeddings → Vector Store → Retrieval → Compression → Generation When something breaks, debugging should happen stage by stage until the real failure point is found. Another important realization: Most production AI work is not writing new algorithms. It is understanding why systems fail, isolating root causes, and improving reliability. With the retrieval pipeline now validated, the next bottleneck is clear. The Neo4j knowledge graph extraction layer is currently returning zero entities. The next step is to debug and improve entity and relationship extraction so the system can combine: • Semantic retrieval. • Keyword retrieval. • Graph-based reasoning. towards true multi-hop enterprise reasoning. Every day, AI engineering feels less like building a chatbot and more like designing a reliable knowledge system. #AIEngineering #AgenticAI #RAG #KnowledgeGraph #Neo4j #VectorSearch #BM25 #EnterpriseAI #LLM #GenerativeAI #SoftwareEngineering #BuildingInPublic
- 30
@free_ai_guides ·
Everyone learns prompting. Almost nobody learns the 6 things that break in production. Prompts are about 5% of AI engineering. Here's the other 95%, the stack that decides whether your app holds up at scale: 1. Serving & inference: KV cache, prefill vs decode, continuous batching, paged attention. 2. Model efficiency: quantization (INT8/INT4/FP8), AWQ, GPTQ, speculative decoding, distillation. 3. Retrieval (RAG): chunking, embeddings, hybrid search, reranking, freshness. 4. Agents & reliability: structured output, function calling, guardrails, routing, and fallback. 5. Evals & observability: golden sets, regression, adversarial tests, traces, drift. 6. Safety, isolation & cost: prompt injection defense, data leakage, multi-tenant isolation, cost attribution. Skip these and you hit the failure modes nobody warns you about: hallucinated tool calls, malformed JSON, stale retrieval, runaway agents, silent eval regressions. Save this.
- 31
@pauliusztin_ ·
I’ve spent the last week interviewing @maximilien, former CTO at IBM and Chairperson of NodeJS Foundation, who has shipped production RAG to multiple customers over the past year. The lesson he kept circling back to is that until you evaluate on your customer’s data, nothing else you do matters. Production RAG is a loop: stitch your embedding model, chunking, retrieval, vector DB, and judge, then evaluate and iterate until you hit your customer’s metrics. Public benchmarks and the MTEB leaderboard are signals, not verdicts. On a real customer dataset of Leica auction listings, an open-source sentence-transformer that ranked around #130 on MTEB still beat OpenAI by 11% in quality. It ran 240x faster, produced 50% smaller vectors, and cost $0.
- 32
@NainsiDwiv50980 ·
WEB SCRAPING JUST GOT A SERIOUS UPGRADE. PixelRAG doesn't read HTML. It reads the page exactly like you do. 100% open-source. Instead of parsing websites into plain text, it captures screenshots and lets a vision model retrieve answers directly from the pixels. Why that's a big deal: • HTML parsers silently lose information. • Tables, charts, formulas, and layouts often disappear. • Even changing the parser can swing RAG accuracy by ~10%. PixelRAG skips that entire bottleneck. It indexes what users actually see. The team built a visual index of 30M+ Wikipedia screenshots, and it outperformed the strongest text-based RAG baseline by 18.1% on text-only QA. Even cooler: It includes a Claude Code plugin that gives Claude visual browsing. Instead of scraping the DOM, Claude can screenshot any webpage, PDF, arXiv paper, or even your local app—and answer based on the rendered page. The pipeline is surprisingly clean: → Render pages into image tiles → Embed with Qwen3-VL-Embedding (LoRA-tuned on screenshots) → Store in a FAISS index → Search visually The best part? Upgrade to a better vision model later, and you don't need to rebuild the index. Because the index stores pixels, not parsed text. Fully open-source under Apache 2.0. GitHub: https://t.co/xiWPrOvadP
Watch video
- 33
@KSimback ·
Can a small open model with $3 of fine-tuning beat a production RAG setup? This is what I tested, and the results were impressive Based on a 100-question eval set, a fine-tuned version of Qwen3.5-9B outperformed Gemini Flash with RAG and Opus4.8/Sonnet 5 without RAG Working on a full write-up of the end-to-end flow
- 34
@JeremyCMorgan ·
Most RAG stops at corpus, retrieval, and injection. This small reference implementation adds output and enforcement layers, treating context as a versioned engineering artifact rather than a prompt pasted into chat. A useful pattern if you're designing an internal coding assistant that needs to respect local architecture decisions. https://t.co/IQqVHNpQCs
- 35
@pauliusztin_ ·
It's been 2 years since I wrote the LLM Engineers Handbook. Since then, I've seen many new RAG eval tools emerge, but there's a problem... Most of them overcomplicate everything with proprietary metric suites. But every RAG system has only 3 variables: Q → Question C → Context A → Answer And if you look at how these interact… There are exactly 6 relationships you can evaluate: 1/ C | Q → Context Relevance Is the retrieved context relevant to the question? 2/ A | C → Faithfulness Does the answer stick to the context? 3/ A | Q → Answer Relevance Does the answer solve the user’s question? 4/ C | A → Context Support Does the context fully support the answer? 5/ Q | C → Question Answerability Can this question even be answered with this context? 6/ Q | A → Self-Containment Can someone understand the question just from the answer? That’s the entire system. 3 variables → 6 relationships → 6 metrics. (Plus retrieval metrics that ensure you have the right context) Nothing more. And when your RAG system fails… It’s always because one of these 6 is broken. So instead of adding more evals, failures should be mapped to: • Retrieval issues • Generation issues • Or end-to-end mismatches I talk more about the 6 failure modes of RAG in lesson 6 of the AI Evals & Observability series in Decoding AI Magazine. Check it out here: https://t.co/jo2B67nDIo
- 36
@smratitiwa86867 ·
🚨 STOP using RAG for everything. You’re not building intelligence — you’re building a complex retrieval layer. More people are starting to realize: You don’t always need RAG. What actually works is much simpler: • INDEX.md as a central map • well-structured directories • an LLM that reads the right context at the right time I’ve been running this with 120+ knowledge files for months. The real advantage isn’t retrieval — it’s continuous improvement. Each interaction: → captures insights → refines hypotheses → updates rules The system doesn’t just read. It evolves. Over time, this compounds into better prompts, stronger frameworks, and validated patterns. At that point, it’s no longer a notes setup. It’s a personal research system. Most people store knowledge. Few build systems that improve with use. That difference compounds. Build systems that learn. 🚀
- 37
@shbhtngpl ·
i'm currently working on a RAG app which i chose to write it in golang mainly. the process is simple, i parse the pdf, create embeddings, upload it to postgres with pgvector and then we can use it for retrieval turns out, golang doesn't have the best support to parse pdfs like python does. so i ended up using python for parsing the pdf into meaningful chunks, write those to a file and then the ingest script, which i'm writing in golang will pick up the chunks from the file and do the next steps i also happened to try out make in the process where my parse commands run the python script and the ingest command will run the go script. will talk about this in another post
- 38
@sebbsssss ·
Got asked today: "Isn't @cludeproject just RAG?" Fair question. The read path retrieves, injects, generates. Same shape. But retrieval over a typed memory graph with temporal indexing, additive compaction, and on-chain provenance stops being RAG somewhere around the third layer. RAG fetches the nearest chunks by vector similarity and dumps them into the prompt. Clude retrieves through a graph where memories have typed edges, causes, contradicts, happens_before, elaborates, and traversal is weighted by edge type. Every memory carries an event date, a decay factor, and a Solana tx hash, None of that is a RAG feature. All of it changes what ends up in the LLM's context. RAG retrieves. Clude remembers.
Watch video
- 39
- 40
@smratitiwa86867 ·
Most RAG systems fail the moment real users touch them. Because real-world retrieval is not: embed → retrieve → generate That works in demos. Production RAG breaks when: → the answer is scattered across 12 documents → embeddings miss industry-specific terminology → bad chunks quietly poison the response → relationships matter more than raw text → PDFs contain tables, charts, and screenshots your pipeline cannot even read This is why serious AI teams are moving beyond “Naive RAG”. The real shift happening in 2026 is not bigger models. It’s smarter retrieval architectures. Here are the 5 RAG patterns quietly becoming the foundation of enterprise AI systems: ━━━━━━━━━━━━━━━━━━━ 1. 𝗛𝘆𝗯𝗿𝗶𝗱 𝗥𝗔𝗚 Dense vectors understand meaning. BM25 understands exact keywords. The magic happens when both rankings merge together. → semantic retrieval + lexical retrieval → Reciprocal Rank Fusion (RRF) combines results → dramatically better recall in production This is becoming the default baseline for serious teams. ━━━━━━━━━━━━━━━━━━━ 2. 𝗚𝗿𝗮𝗽𝗵𝗥𝗔𝗚 Chunks are not enough when knowledge is relational. GraphRAG extracts: → entities → relationships → communities → connected concepts Instead of retrieving isolated chunks… the system retrieves subgraphs. This is how AI systems start answering: “how are these things connected?” rather than: “which paragraph contains the keyword?” Perfect for: research, finance, healthcare, compliance, enterprise knowledge systems. ━━━━━━━━━━━━━━━━━━━ 3. 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗥𝗔𝗚 Retrieval stops being a single step. It becomes a reasoning loop. One agent plans: → vector DB? → SQL? → web search? → internal docs? Another agent verifies: → is the answer complete? → should we retry retrieval? → do we need another source? The important shift: RAG becomes orchestration. Not just search. ━━━━━━━━━━━━━━━━━━━ 4. 𝗖𝗼𝗿𝗿𝗲𝗰𝘁𝗶𝘃𝗲 𝗥𝗔𝗚 (CRAG) Most pipelines trust retrieval blindly. Production systems cannot afford that. CRAG introduces retrieval grading. → good retrieval → answer → weak retrieval → rewrite query → failed retrieval → fallback to web/tool search This is the architecture pattern most demos skip… but real enterprise systems desperately need. Because retrieval quality is the real bottleneck. ━━━━━━━━━━━━━━━━━━━ 5. 𝗠𝘂𝗹𝘁𝗶𝗺𝗼𝗱𝗮𝗹 𝗥𝗔𝗚 The future of enterprise knowledge is not text-only. Real documents contain: → charts → diagrams → scanned PDFs → screenshots → tables → UI images Multimodal RAG indexes all of it together. One embedding space. One retrieval system. One multimodal model. No more broken “OCR + text-only” hacks. ━━━━━━━━━━━━━━━━━━━ The most advanced AI stacks in 2026 will not choose ONE of these. They will combine them. Think about the architecture direction: → Hybrid retrieval for accuracy → Agentic orchestration for reasoning → Corrective grading for reliability → Multimodal indexing for real-world data → Graph retrieval for connected knowledge That combination is where the industry is heading. Naive RAG is not the finish line anymore. It’s the “hello world” tutorial. And honestly… this is why most enterprise GenAI projects stall after the demo phase. The problem was never just the model. The problem was retrieval architecture.
- 41
@Suryanshti777 ·
Berkeley just made HTML parsing obsolete for RAG. PixelRAG doesn't scrape pages into text. it screenshots them — and retrieves the image itself. no parser. no chunking. no lost tables. why this is a big deal: → parsing is where web RAG silently dies — a single HTML-to-text pass can drop 40% of a page → tables, charts, and layout get flattened into noise. pixels keep everything → they indexed all of Wikipedia as screenshots — and beat the strongest text RAG baseline by 18.1% on text-only QA read that again: images beat text at finding text. it also ships a Claude Code plugin that gives Claude eyes — it screenshots any URL and reads the rendered page like a human. no MCP server, no backend. 100% open-source, Apache 2.0. live demo with no API key. repo: https://t.co/XVcp45EDmo we spent years teaching machines to parse the web. turns out they just needed to look at it.
- 42
@agenticgirl ·
Everyone is optimizing RAG the same way: Better retrieval → better answers. This paper : Retrieval Improvements Do Not Guarantee Better Answers: A Study of RAG for AI Policy QA breaks that assumption. Here’s what they did: • Improved retrieval (higher Recall@k, MRR) • Fine-tuned the generator (DPO alignment) • Built a solid, domain-specific RAG pipeline Everything you’re supposed to do. But the outcome? • Retrieval improved • Answer quality barely moved • Hallucinations became more confident Why this happens is the real insight: When the correct document isn’t in the corpus, RAG doesn’t fail. It improvises. The retriever finds the closest match. The model treats it as truth. And the answer sounds perfectly right even when it isn’t. That leads to a dangerous pattern: • Fluent answers • Relevant context • Incorrect conclusions The system looks reliable until you actually verify it. The paper highlights where things break: • Missing data → answers built on partial evidence • Similar language → wrong sources get mixed in • Complex queries → incomplete retrieval • Weak uncertainty → no “I don’t know” behavior Even with: • Better retrievers • Preference-aligned generation the system doesn’t become meaningfully more reliable. Meanwhile, larger models still perform better not because of retrieval, but because they’re better at reasoning + calibration. RAG doesn’t fail because it can’t find answers. It fails because it can’t admit when the answer isn’t there. Until that’s fixed, better retrieval will just make wrong answers sound more convincing. Here's the link to the Paper : https://t.co/a5N3Kk9qUE
- 43
@NaadhLabs ·
today's topics - RAG.2 1. llm follows U-based learning pattern · it is better at things that come first and last · bad at middle things comparatively · this is where Context Engineering comes 2. Context rot · something bad happening with the context, as tokens increase, the performance of LLM goes down Approach to improve this = NIAH (Needle in a Haystack) -needle, the answer we want -haystack, all the context , the model has been given But, it's just a retrieval task. It's not checking about semantics (meaning) and logical (familiar) so, we have to eval semantic retrieval and non-lexical retrieval How is it tested on different models? we have to test models on increasing token length https://t.co/TQX920syl1
- 44
@DanKornas ·
Vector-only RAG can miss relationships that span chunks and documents, especially when a question needs both details and wider context. LightRAG is a graph-based RAG framework for builders who need retrieval across entities, relationships, and source text. It helps you retrieve both specific facts and broader context by combining knowledge-graph indexing with vector embeddings and dual-level retrieval. Key features: • Dual-layer indexing – manages knowledge graphs and vector embeddings together instead of relying only on chunk similarity. • Five query modes – choose local, global, hybrid, naive, or mix retrieval for different question types. • Incremental updates – add new data without rebuilding the global index. • Multimodal parsing – extract text, tables, formulas, and images with MinerU, Docling, or native parsers. • Builder interfaces – work through a REST API, WebUI, or Python SDK. It’s open-source (MIT license). Link in the reply 👇
- 45
- 46
- 47
@Redisinc ·
Your RAG pipeline is probably embedding the same documents more than once. Duplicate embeddings are easy to miss. They don't throw errors. They just quietly degrade retrieval quality, inflate storage costs, and get worse as you scale. Here’s a practical guide to idempotency patterns for LLM apps, covering where duplicate work sneaks in and how to stop it before it becomes a production problem: https://t.co/O60rBX3bZ2
- 48
- 49
- 50
Best Tweets by Topic