Agentic, corrective & graph RAG patterns
Moving beyond naive RAG with routing, query decomposition, corrective/self-RAG loops, GraphRAG, MCP-based sources and multi-agent orchestration.
24%
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
- 39
- Updated
Original Xholic analysis
What 50 top RAG posts reveal
Across 50 posts from 39 creators, the RAG conversation is mostly supportive (56%) and centers on moving past naive retrieve-then-generate pipelines toward agentic, hybrid, and structure-aware retrieval. Evaluation threads warn that small-corpus accuracy misleads at scale, and grounding critiques argue retrieval gains don't guarantee correct answers. Media posts (70% of the set) outscore text posts by median, and tutorials carry the highest format median. A vocal minority pitches memory systems, LLM wikis, or grep as alternatives to RAG.
- Dominant tone
- Positive
- Median score
- 9.65
- Leading format
- Announcement
- Recent posts
- 20%
54% of posts
All-time engagement
32% of posts
Published in 90 days
Conversation map
The themes creators return to
Hybrid search, reranking & embeddings
Combining BM25 with vector search, rerankers, query rewriting, embedding fine-tuning and choosing embedding models for better retrieval quality.
20%
Production pitfalls, cost & latency
Common production mistakes, observability, reliability, token economics, caching (CAG) and lean tooling that affect RAG cost and latency.
20%
Chunking, parsing & ingestion
Document parsing quality, structure-aware chunking, TOC-based retrieval, deduplication, idempotent ingestion, metadata and sync pipelines.
18%
Grounding, citations & failure modes
Hallucinations despite retrieval, citation and provenance enforcement, no-answer behavior, context rot, lost-in-the-middle and what grounding really means.
18%
RAG evaluation & benchmarks
Measuring retrieval and answer quality: eval metrics, enterprise-scale benchmarks, recall degradation with corpus size, and testing on customer data.
18%
Agent memory & alternatives to RAG
Persistent memory, LLM wikis, grep-based exploration and file-based knowledge systems pitched as successors or alternatives to retrieve-then-forget RAG.
14%
Visual & multimodal document retrieval
Retrieving directly from page screenshots or rendered images (PixelRAG, ColVec1) instead of OCR/HTML parsing, preserving tables, charts and layout.
12%
Tone and stance
SentimentPositive leads
Author postureSupportive leads
Performance benchmark
- Median likes
- 26
- Median reposts
- 5
- Median replies
- 4
- Median views
- 2.4K
Posts with media make up 70% of this collection. Their median all-time score is 12.2, compared with 3.07 for text-only posts.
Format mix
- Announcement32% · score 16.1
- Other22% · score 2.34
- Opinion14% · score 8.47
- Tutorial14% · score 58.0
Consensus and debate
Where creators agree, and where they do not
Shared view
Naive RAG is a starting point, not production
Many posts frame one-shot retrieve-then-generate as insufficient and recommend layering query rewriting, routing, corrective validation loops and hybrid search. Posts by Avi Chawla, Jaydeep, smrati tiwari and Alex Xu (on Microsoft Foundry) each describe retrieval wrapped in evaluation or correction steps.
Shared view
Hybrid BM25 + vector with reranking as baseline
Combining lexical and semantic search, then reranking, recurs as a default recommendation. Examples range from pg_textsearch pairing BM25 with pgvector in Postgres to production-mistake lists that flag cosine-only search and default top-k without a reranker.
Shared view
Ingestion and parsing quietly decide quality
Posts converge on parsing, chunking and ingestion hygiene as hidden failure points: lost tables, structure-blind chunks and duplicate embeddings. STAIR's TOC-based retrieval and visual retrieval efforts like PixelRAG and ColVec1 are pitched as ways around these losses.
Shared view
Evaluate at realistic scale and on real data
Akshay cites EnterpriseRAG-Bench results where vector search fell from 90.7% to 50.6% as the corpus grew from 5K to 500K docs, while BM25 fell from 85.8% to 68.4%. Paul Iusztin relays an interviewee's view that evaluating on customer data matters more than MTEB rankings.
Open debate
Is RAG obsolete or still foundational?
Some posts argue RAG is a distraction or is being replaced by LLM wikis, file-based INDEX.md systems or agent grep exploration. Others hold that RAG solves most problems at lower complexity than agentic stacks and should be the first layer.
Open debate
Does better retrieval yield better answers?
Sandhya highlights a paper where improved Recall@k and MRR barely moved answer quality and made hallucinations more confident. A DEV Community post instead says most RAG failures are retrieval failures, relaying a developer who measured Recall@10 and shared two retrieval fixes.
Open debate
What 'grounding' actually means
Britney Muller argues that calling RAG 'grounding' misuses the term, since retrieved web text isn't ground truth. Other posts treat grounding as enforceable through citations, doc hashes or source-ID anchoring.
What performs
Patterns behind standout posts
Media posts outscore text by median
70% of posts include media. Media posts have a median all-time score of 12.222, versus 3.074 for text-only posts.
Tutorials lead format medians
Tutorials post the highest median all-time score (57.997) despite being 14% of posts. Announcements are the largest format at 32%, with a median of 16.09.
Agentic architectures theme scores highest
The agentic, corrective and graph RAG theme has the highest theme median score at 49.31. That is far above chunking (2.847), grounding (2.741) and evaluation (2.646).
PixelRAG post is the top outlier
Kshitij Mishra's PixelRAG post scored 1675.9, 173.67x the 9.65 median. Other outliers are pg_textsearch (85.97x), STAIR (56.05x) and Jaydeep's project list (45.01x). A separate PixelRAG post by Nainsi Dwivedi scored 19.341.
Statistical standouts
- View standout post 1Score 1675.9 · 173.67× median
- View standout post 2Score 829.6 · 85.97× median
- View standout post 3Score 540.9 · 56.05× median
- View standout post 4Score 434.4 · 45.01× median
- View standout post 5Score 319.0 · 33.06× median
Creator landscape
Who shapes this conversation
The five most represented creators account for 20% of the selected posts.
1. Avi Chawla
@_avichawla
2 posts
2. Abhishek Singh
@0xlelouch_
2 posts
3. Akshay 🚀
@akshay_pachaar
2 posts
4. Aurimas Griciūnas
@Aurimas_Gr
2 posts
5. DAIR.AI
@dair_ai
2 posts
6. Jeremy Morgan
@JeremyCMorgan
2 posts
Highest-scoring top voices
Among top voices, Akshay (median 505.84), Avi Chawla (218.09) and Aurimas Griciūnas (96.17) lead, each with two explanatory posts. Their topics span hybrid search, scale-dependent retrieval, agentic RAG, CAG and MCP.
Fragmented creator base
39 creators produced 50 posts, and no top voice posted more than twice. The top-five placement share is 20%.
Practitioner checklists earn modest scores
Abhishek Singh's production-mistake lists (median 13.89) and Paul Iusztin's eval-focused posts (median 3.3) offer concrete operational guidance. Both trail the 16.09 announcement format median.
Since the previous snapshot
What changed since Aug 26, 2026
- 58% of the selected posts remained.
- The creator count changed by -5.
- 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 39 creators
Ranked 01–50
- 01
@DAIEvolutionHub ·
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/B7whbNg60s
Watch video- 18Replies
- 298Reposts
- 2.1KLikes
- 115.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 02
@akshay_pachaar ·
Big moment for Postgres! Search has always been Postgres' weak spot, and everyone just accepted it. If you needed a real relevance-ranked keyword search, the default answer was to spin up Elasticsearch or add Algolia and deal with the data sync headaches forever. The problem isn't that Postgres can't do text search. It can. But the built-in `ts_rank` function uses a basic term frequency algorithm that doesn't come close to what modern search engines deliver. So teams end up: - Running a separate Elasticsearch cluster just for search - Building sync pipelines that inevitably drift out of consistency - Paying for managed search services that charge per query - Accepting mediocre search relevance because "good enough" ships faster But this is actually a solvable problem. You can realistically bring industry-standard search ranking directly into Postgres, which eliminates the need for external infra entirely. This exact solution is now available with the newly open-sourced pg_textsearch by @TigerDatabase, a Postgres extension that brings true BM25 relevance ranking into the database. BM25 is the algorithm behind Elasticsearch, Lucene, and most modern search engines. Now it runs natively in Postgres. Here's what pg_textsearch enables: - True BM25 ranking with configurable parameters (the same algorithm powering production search systems) - Simple SQL syntax: `ORDER BY content <@> 'search terms'` - Works with Postgres text search configurations for multiple languages - Pairs naturally with pgvector for hybrid keyword + semantic search That last point matters a lot for RAG apps. The video below shows this in action, and I worked with the team to put this together. You can now do hybrid retrieval (combining keyword matching with vector similarity) in a single database, without stitching together multiple systems. The syntax is clean enough that you can add relevance-ranked search to existing queries in minutes. pg_textsearch is fully open-source under the PostgreSQL license. You can find a link to their GitHub repo in the next tweet.
Watch video- 67Replies
- 278Reposts
- 2.4KLikes
- 186.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 03
@HowToPrompt__ ·
IBM built a retriever that hallucinates 65x less than fine-tuned RAG systems. no vector database. no embeddings. no re-ranker. Right now, if you want an AI to read a massive document, you use Retrieval-Augmented Generation (RAG). But standard RAG does something brutal. It takes a beautifully structured 500-page manual and throws it into a blender. It chops the text into arbitrary, fixed-size chunks. It strips away the chapters, the sections, the hierarchy. It throws away the map and asks the AI to find the treasure. A new paper just introduced STAIR, a method that fixes this massive blind spot. Instead of shredding documents into random chunks, STAIR uses the document's actual structure, its Table of Contents, as an addressing scheme. The generative retriever pulls information against the real hierarchy of the text. It remembers where things actually live. The benchmark results are staggering. STAIR hit an 82.6% Recall@1, completely destroying traditional methods like BM25 and standard Dense Passage Retrieval (DPR). But here is the most important metric for any business running AI in production: Hallucinations plummeted to under 0.05%. Almost zero. By giving the AI back the structural context, the system stopped guessing and started retrieving with lethal precision.
- 37Replies
- 83Reposts
- 503Likes
- 24.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 04
@_jaydeepkarale ·
If you're learning RAG, don't build another basic "PDF chatbot." Build these 10 projects instead. They'll take you from basic retrieval to production-grade AI systems: 1. Hybrid Search RAG What you'll build: Combine BM25 keyword search with dense vector retrieval to find both exact matches and semantically relevant documents. Stack: Python · BM25 · Elasticsearch/FAISS · Sentence Transformers 2. Metadata-Filtered RAG What you'll build: Combine semantic search with filters such as date, category, author, or location to narrow down relevant context. Stack: Python · PostgreSQL · pgvector · Pydantic · OpenAI 3. Reranking RAG What you'll build: Retrieve many candidates, rerank them using a cross-encoder, and send only the most relevant chunks to the LLM. Stack: Python · FAISS/pgvector · CrossEncoder/Cohere Rerank · OpenAI 4. Contextual Chunking RAG What you'll build: Preserve document-level context when creating chunks so retrieved passages remain meaningful on their own. Stack: Python · Docling · OpenAI/Claude · pgvector 5. SQL + Vector RAG What you'll build: Combine SQL for structured data with vector search for unstructured knowledge. Stack: Python · PostgreSQL · pgvector · SQLAlchemy · LangGraph 6. Knowledge Graph + Vector RAG What you'll build: Combine semantic search with explicit relationships between entities to answer questions where connections between facts matter. Stack: Python · Neo4j · pgvector · OpenAI · LangGraph 7. Corrective RAG What you'll build: Evaluate retrieved context before answering. If retrieval is weak, rewrite the query, retrieve again, or use another source. Stack: Python · LangGraph · OpenAI · pgvector · Tavily 8. Self-RAG What you'll build: Let the system decide when retrieval is needed, evaluate the evidence, and check whether the answer is sufficiently supported. Stack: Python · LangGraph · OpenAI · pgvector 9. Multimodal RAG What you'll build: Retrieve and reason over text, tables, images, and document pages instead of treating everything as plain text. Stack: Python · Docling · Multimodal LLM · Vector DB · OpenAI 10. Agentic RAG What you'll build: Build an agent that decides which knowledge source or tool to use, performs multiple retrieval steps when necessary, and combines the results. Stack: Python · LangGraph · OpenAI · Vector DB · Search APIs The interesting part? These aren't 10 completely separate architectures. You can combine them. Hybrid search + reranking + metadata filtering + corrective retrieval can eventually become one production RAG pipeline. If you're learning RAG seriously, don't stop at: "I can retrieve documents and send them to an LLM." Learn how to make retrieval accurate, contextual, verifiable, and adaptive.
- 13Replies
- 73Reposts
- 356Likes
- 19.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 05
@_avichawla ·
Naive RAG vs. Agentic RAG, explained visually: Naive RAG has well-known failure modes: - It retrieves once and generates once. If the context isn't relevant, it can't search again. - It treats every query the same. A simple lookup and a complex multi-hop reasoning task go through the identical retrieve-then-generate path. - There's no verification. The system blindly trusts whatever the retriever returns. Agentic RAG introduces decision-making loops at each stage to fix this. Steps 1-2) A query rewriting agent reformulates the raw query. This goes beyond fixing typos, like optimizing it for retrieval by making vague terms precise, decomposing complex queries into sub-queries, and expanding abbreviations. Steps 3-5) A routing agent decides if the query even needs external context. If not, retrieval is skipped. If yes, a source selector picks the best backend for this specific query type. Steps 6-7) The source selector routes to the most appropriate source: vector DB for semantic search, web search for real-time info, or structured APIs for tabular data. The retrieved context and rewritten query are combined into the prompt. Steps 8-9) The LLM generates an initial response. Steps 10-12) A validation agent (known as Corrective RAG) checks whether the response is relevant, grounded, and complete. If it passes, it's returned. If not, the system loops back to Step 1 with a reformulated query. This continues for some iterations until we get a satisfactory response or the system admits it cannot answer. The reason this works is that each agent acts as a quality gate. The rewriter ensures retrieval precision. The router ensures the right source is queried. The validator ensures the output is grounded. Individual failures get caught and corrected rather than silently propagated. That said, the diagram below shows one of many blueprints of an Agentic RAG system. Production systems increasingly combine Corrective RAG, Adaptive RAG, Self-RAG, and hybrid search (vector + lexical with reranking) based on latency budgets and accuracy requirements. 👉 Over to you: What does your Agentic RAG setup look like? ____ Find me → @_avichawla Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.
Watch video- 29Replies
- 128Reposts
- 705Likes
- 36.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 06
@mdancho84 ·
This AI System Design guide teaches RAG and production AI architectures better than most courses. And it's completely free and open-source. Inside: • Production RAG & Chunking: Hybrid retrieval, ColBERT, and GraphRAG • Agentic Loops & Scaling: MCP 2.0, A2A protocols, and loop engineering • Real-Time Voice & Audio Agents: Latency budgets and cascade vs. speech-to-speech stacks • Evaluation & Observability: LLM-as-a-judge, Phoenix, Langfuse, and LangWatch frameworks • FinOps & Token Economics: Model gateways, prompt caching, and cost control • 116-Question Staff-Level Interview Bank with complete architectural case studies No DMs, no hoops to jump through. Read the living reference guide directly here: Github: https://t.co/mVrfJlY9bA 🚨 Want to learn how to build + ship AI and Data Science projects (that businesses actually want in 2026)? On July 14th, I am hosting a free workshop to help you get started with AI + DS projects in Python. Register here (500 seats): https://t.co/onpLpRwkzH
- 4Replies
- 52Reposts
- 244Likes
- 15.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 07
@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.
- 31Replies
- 52Reposts
- 437Likes
- 61.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 08
@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?
- 15Replies
- 64Reposts
- 285Likes
- 12.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 09
@bibryam ·
RAG vs Agentic RAG vs Agent Memory A useful simplified model: RAG retrieves in one shot. Agentic RAG chooses sources. Agent memory adds read/write state. The shift: retrieval control and persistent context. Visual by @helloiamleonie https://t.co/WiY2gePgUx
- 19Replies
- 44Reposts
- 206Likes
- 7.9KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 10
@_avichawla ·
RAG is a distraction! Here's how Google and Microsoft actually give context to their production agents: To understand this, think about what "give an agent context" actually means in production. In production, data lives across Slack, Gmail, Jira, Drive, Salesforce, GitHub, and SQL databases. Each source has different auth, different data formats, different update cycles. A query like "summarize all activity on the auth migration this week" needs to pull from five sources simultaneously, filter by time, check permissions, and rank results by relevance. No single embedding lookup handles this. That's why the real engineering is in the layers underneath, which includes source-specific indexing, intelligent query routing, query decomposition across SQL/vector/keyword, parallel multi-source retrieval with reranking, and continuous sync that detects actual content changes. The visual below describes this in detail. If you want to see this in practice, this approach is actually implemented in Airweave, a 100% open-source context retrieval layer that makes all your tools searchable for Agents using semantic, keyword, and agentic search. Key features: - 50+ connectors (Slack, Drive, GitHub, Salesforce, Stripe, Notion, etc.) - Content-hash based incremental sync (skips metadata-only changes, only re-embeds when content actually changed) - Hybrid search with semantic + keyword + time-aware with query expansion and reranking - One unified endpoint via REST API or MCP - Self-host via Docker The key takeaway is that context retrieval for agents is not about better embeddings, but rather auth, sync, indexing, routing, search, and permissions. You need to treat retrieval as an infrastructure from day to ship agents that actually work. I have shared the Airweave repo link in the replies!
Watch video- 21Replies
- 49Reposts
- 245Likes
- 16.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post.
- 11
@heygurisingh ·
🚨RAG engineers are going to lose their minds. @webAI just open sourced a document retrieval model that's sitting at #1 AND #3 on ViDoRe V3 -- with Nvidia's best open-source embedding model trapped at #2 between them. No OCR. No text extraction. No broken pipelines on messy PDFs. It's called webAI-ColVec1. Here's what this thing actually does: → Skips OCR entirely and retrieves directly from the rendered page image -- sees layout, tables, charts, and structure the same way you do → Ships in two variants (4B and 9B) with embedding sizes of 128, 640, and 2560 -- pick speed or max retrieval quality → Trained on ~2M question-image pairs across scientific papers, financial filings, healthcare records, government reports, and technical manuals → Uses 511 in-batch negatives per query for a brutal contrastive signal that forces clean separation between correct and competing pages → Built with a proprietary loss function designed specifically for retrieval -- not borrowed from generic embedding training → LoRA rank 32 + retrieval projection layer means efficient specialization without full fine-tuning Here's the wildest part: Built on Qwen 3.5 vision-language backbones and trained on just 8 A100s. No giant model. No massive infra budget. No scale-maxing. Just a deliberate, retrieval-specific training recipe applied to the right problem. And it beat the largest GPU company in the world on their own benchmark. You literally point this at a financial filing or a scanned healthcare doc -- the stuff that destroys every OCR pipeline in production -- and it retrieves the right page based on what the page actually looks like. That sentence shouldn't be real for an open-source model trained on 8 GPUs in 2026. But here we are. 100% Open Source. Live on Hugging Face. Two of the top three spots on ViDoRe V3. (Link in the comments)
- 44Replies
- 101Reposts
- 369Likes
- 81.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 12
@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 👇
- 6Replies
- 22Reposts
- 109Likes
- 5.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 13
@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
- 9Replies
- 20Reposts
- 109Likes
- 6.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 14
@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
- 8Replies
- 34Reposts
- 132Likes
- 15.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 15
@techNmak ·
Size matters. So does speed. (505KB Wheel vs 12MB+ Alternatives) Most RAG libraries are bloated. They bundle everything from PDF parsers to web scrapers when all you want to do is split text. Chonkie is optimized specifically for the "Ingestion" bottleneck. The Metrics: ➡️ Disk Footprint: ~50MB installed (vs 170MB+ for standard frameworks). ➡️ Token Chunking: 33x faster than the closest competitor. ➡️ Semantic Chunking: 2.5x faster (optimized for model2vec and sentence-transformers). It includes a FastChunker that uses SIMD acceleration to process text at 100+ GB/s. If you are processing millions of documents, the overhead of your chunking library actually impacts your cloud bill. Chonkie kills that overhead. Check the next tweet for the GitHub repo.
- 7Replies
- 13Reposts
- 76Likes
- 3.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 16
@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.
- 6Replies
- 20Reposts
- 62Likes
- 2.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 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- 7Replies
- 13Reposts
- 26Likes
- 2.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 18
@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
- 6Replies
- 14Reposts
- 75Likes
- 8.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 19
@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
- 2Replies
- 4Reposts
- 26Likes
- 1.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 20
@Suryanshti777 ·
RAG might already be becoming obsolete. A month ago, Andrej Karpathy dropped a simple GitHub gist called “LLM Wiki.” Now the comments section looks like the birth of an entirely new AI category. 5000+ stars later, developers are rapidly building: • persistent AI memory systems • self-maintaining knowledge bases • multi-agent research environments • contradiction detection engines • AI-native company operating systems • local-first memory architectures • graph-based reasoning layers • evolving second brains And the craziest part? Most of them were built in DAYS. Because the core idea is insanely powerful: Instead of AI repeatedly retrieving raw chunks like traditional RAG… …the model continuously maintains a living knowledge system. Not temporary context. Persistent synthesis. The shift sounds subtle until you realize what it changes: RAG: retrieve → answer → forget LLM Wiki: ingest → synthesize → evolve That one architectural difference is causing an explosion of experimentation right now. People are already building: • agent memory operating systems • AI-maintained engineering documentation • self-healing knowledge graphs • persistent research environments • conversational memory architectures • contradiction-aware wikis • context compression engines • machine-readable company systems The comments section alone feels like watching an ecosystem form in real time. One developer built deterministic contradiction detection using sheaf cohomology Another built “sleep consolidation” for AI memory systems inspired by human memory formation Another created persistent multi-agent vault conversations Another turned entire repositories into continuously maintained AI wikis Another built local-first memory systems with audit trails, provenance, graph exports, and MCP integration This is the important part: Karpathy didn’t launch a product. He introduced a pattern. And patterns are what create ecosystems. The same way: • transformers created modern AI • RAG created AI retrieval startups • agents created orchestration frameworks LLM Wikis may create persistent AI memory infrastructure. That’s why this moment feels different. For years, AI systems have been stateless. Now developers are trying to build systems that actually accumulate understanding over time. And once knowledge compounds instead of resetting… …the entire interface layer of AI changes. (Link in comments)
Watch video- 6Replies
- 7Reposts
- 35Likes
- 2.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 21
@freshlimesofa ·
New blog !!! Strategies in Advanced RAG. it consists of broad techniques that I've come across while working on RAG pipelines as well as studying them. Includes strategies like HyDE, RAG-Fusion, Query decomposition & more. suggestions appreciated :) https://t.co/oTMVd2rf0c
- 5Replies
- 7Reposts
- 28Likes
- 1.1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 22
@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
- 10Replies
- 4Reposts
- 46Likes
- 7.8KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 23
@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 🎓
- 4Replies
- 8Reposts
- 31Likes
- 2.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 24
@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
- 1Replies
- 2Reposts
- 20Likes
- 1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 25
@JustAnotherPM ·
RAG is one of the most important AI concepts a PM can understand. Here’s the simple version: Instead of relying on what the model was trained on, RAG lets your AI search your data first — then answer. It’s how AI gets access to your docs, your knowledge base, your product data. No fine-tuning required.
- 1Replies
- 4Reposts
- 20Likes
- 2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 26
@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.
- 3Replies
- 6Reposts
- 36Likes
- 2.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 27
@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.
- 8Replies
- 4Reposts
- 33Likes
- 3.9KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 28
@gakonst ·
RE: memory layer conversations. I still unfortunately don't buy RAG as a solution. Agent `rg`'ing across all folders w/ some -A / -B to gather surroundings of the keywords, and progressively exploring the grep seems right 80/20 to me still.
- 17Replies
- 1Reposts
- 52Likes
- 6.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 29
@dejanseo ·
Normalization of RAG gave Google a permission to go where they couldn't go before. You can now open a tab with your bank transactions, amazon shopping history, medical records, mortgage interest details, personal diary, private photos... and you can, if you choose, send that tab to Google to work with. While it provides utility for the user, no doubt about that, it gave Google access to the black box it could never legally open. Will they serve ads on such generative responses? Will they use it anonymized to train models? Will any of it stay in chat memory for future reference? Can sensitive details otherwise unobtained be extracted from these systems by 3rd parties? Fun times!
- 3Replies
- 6Reposts
- 25Likes
- 3.4KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 30
@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.
- 3Replies
- 2Reposts
- 6Likes
- 1KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 31
@dair_ai ·
Static orchestration is the silent killer of multi-agent RAG systems. The query changes, but the agent topology stays the same. The work introduces HERA, a framework that jointly evolves multi-agent orchestration and role-specific agent prompts. At the global level, it optimizes query-specific agent topologies through reward-guided sampling. At the local level, it refines individual agent behaviors via credit assignment and dual-axes prompt adaptation. On six knowledge-intensive benchmarks, HERA achieves an average improvement of 38.69% over recent baselines. Why does it matter? As multi-agent RAG systems scale, the gap between fixed pipelines and adaptive orchestration will only grow. HERA shows that letting the system learn its own coordination structure produces compact, high-utility agent networks. Paper: https://t.co/hxoYDfsHBn Learn to build effective AI agents in our academy: https://t.co/LRnpZN7L4c
- 1Replies
- 0Reposts
- 5Likes
- 980Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 32
@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
- 1Replies
- 0Reposts
- 4Likes
- 120Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 33
@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- 4Replies
- 1Reposts
- 16Likes
- 796Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 34
@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
- 3Replies
- 1Reposts
- 11Likes
- 449Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 35
@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.
- 2Replies
- 5Reposts
- 11Likes
- 1.5KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 36
@sabir_huss50540 ·
🚨 @thewebAI just open-sourced ColVec1 and it’s a serious shift in document retrieval. #1 and #3 on ViDoRe V3, with Nvidia’s best open-source embedding model sitting in between. But the real story isn’t the leaderboard. Most RAG systems still depend on OCR → PDF to text → search. That breaks on real-world documents: tables, scans, charts, financial reports, medical files. ColVec1 skips OCR entirely. It retrieves directly from rendered document images understanding layout, structure, and visuals the way humans do. Built with a retrieval-first training recipe on ~2M query-image pairs, optimized for real-world performance instead of brute scale. This is what the next phase of AI looks like: less scale-first… more task-first.
- 14Replies
- 7Reposts
- 24Likes
- 7.7KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 37
@ArleenWhar1595 ·
I don't trust chatbots that cite vibes... wired our RAG so only retrieval and grounding get receipts; doc hashes prove the claims, the prose can flow. targeted proofs via @inference_labs DSperse kept latency sane and made citations mean something #AI #RAG #zkML
- 3Replies
- 0Reposts
- 6Likes
- 78Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 38
@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
- 0Replies
- 2Reposts
- 8Likes
- 384Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 39
@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. 🚀
- 2Replies
- 2Reposts
- 7Likes
- 531Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 40
@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
- 2Replies
- 0Reposts
- 6Likes
- 280Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 41
@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.
- 1Replies
- 4Reposts
- 6Likes
- 295Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 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
- 0Replies
- 0Reposts
- 5Likes
- 159Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 43
@hackernoon ·
Why bigger context windows often make AI agents less accurate. Learn about lost-in-the-middle, context rot, reranking, and smarter context engineering. #rag #lostinthemiddlellm...Show more
- 2Replies
- 4Reposts
- 7Likes
- 831Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 44
@TDataScience ·
What determines the quality of a RAG system's outputs? Kezhan Shi zooms in on PDFs and examines document signals (metadata, native TOC, source software) and page-level content (text vs scans, tables, images, columns, page profile). https://t.co/OJib54gTtq
- 0Replies
- 2Reposts
- 5Likes
- 1.2KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 45
@TDataScience ·
Have we been thinking about the retrieval step in RAG in the wrong terms all along? For Angela Shi, "retrieval is a filtering problem on two structured tables (line_df and toc_df), not a search problem." https://t.co/tIJxeM9OsK
- 0Replies
- 1Reposts
- 7Likes
- 2.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 46
@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
- 0Replies
- 3Reposts
- 2Likes
- 372Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 47
@JeremyCMorgan ·
Hugging Face and NVIDIA published an end-to-end embedding fine-tuning pipeline for RAG. Synthetic QA generation, hard negative mining, ONNX/TensorRT export, deployed behind an OpenAI-compatible API. Recall@60 went from 0.751 to 0.951 in one case. Requires 80GB VRAM for fine-tuning. https://t.co/MVNi4175JB
- 0Replies
- 1Reposts
- 0Likes
- 120Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 48
@ThePracticalDev ·
Most RAG failures aren't LLM failures, they're retrieval failures. This dev measured Recall@10, found 40% of answers were wrong, and shares the two fixes that consistently move the needle. { author: @s_panchyshyn } https://t.co/btttHGINaT
- 0Replies
- 1Reposts
- 3Likes
- 1.3KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 49
@UnstructuredIO ·
Take a simple table showing quarterly revenue. One parser extracts it row by row. Another extracts it column by column. Both captured the data correctly. Traditional metrics would score one of them as wrong. That’s the problem SCORE-Bench was built to solve. Character Error Rate and Tree Edit Distance are the metrics most benchmarks still rely on. They assume there’s one correct output for every document. That made sense for deterministic OCR systems. It doesn’t make sense for generative parsers that produce semantically equivalent content in different forms. These metrics work differently. Adjusted CCT measures whether the meaning was preserved, not whether the format matched. Tokens Added tracks content the parser invented that wasn’t in the original document. Cell Content Accuracy and Cell Spatial Accuracy evaluate tables on whether you got the data right, regardless of how it was formatted. These aren’t arbitrary choices. They’re what actually predict whether your downstream GenAI pipeline will behave the way you expect. Check it out 👉 https://t.co/GVxA2NEoz4 #RAG #GenAI #Evals #Unstructured #EnterpriseAI #DocumentAI
- 0Replies
- 1Reposts
- 1Likes
- 174Views
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post. - 50
@ThePracticalDev ·
RAG pipelines have no causal tracking, so an LLM will link a cleanup cron job to an unrelated disk failure just because both logs landed nearby. This dev's fix anchors every claim to a source doc ID. { author: @tanaikech + @GoogleDevExpert } https://t.co/C9WN9j3BDy
- 1Replies
- 0Reposts
- 1Likes
- 3.6KViews
Rewrite this post in your own voice and angle.See the hook, structure, and reusable template behind this post.
Best RAG tweets
Write posts like these, in your own voice
Xholic studies what works in your niche, drafts posts in your voice and schedules them for the hours your audience is online.
Start 3-day trial for $0Try the live demoTake a 2-minute tour of a sample account in the real app. No sign-up or login needed.
$0 today · Card required · Cancel anytime
Browse all tweet collectionsLive demo: no sign-up or login needed · takes about 2 minutes
Keep exploring
From the blog
- Best AI Tweet Generators for X in 2026The 10 best AI tweet generators for X compared by use case, how they work and the prompts that get results, plus a free tool to try now.
- Xholic AI Chrome Extension: Grow on X Without Leaving Your Feed (2026)The Xholic AI Chrome extension writes replies in your voice, remixes posts, shows analytics for any profile and keeps your mentions in one place, all inside X. Here's what it does.
- 10 Top AI Tools for Creators in 2026Compare the top AI tools for creators in 2026 and learn how to build a focused creator stack around ideation, visuals, video, audio, repurposing, and X growth.
Guides
- How to Write a Tweet With an AI Tweet GeneratorTurn a rough idea into a tweet worth posting: write a specific prompt, pick a tone and length, compare three drafts and make the best one sound like you.
- How to Write a Twitter Thread With an AI Thread GeneratorTurn a topic into a hook-first X thread: choose 4 to 10 posts and a tone, check the hook, edit each post and publish the thread in X's composer.
More topics like this
- Best tweets about AIA curated collection of the sharpest, most-shared X posts about AI—saved so you do not have to dig through the timeline yourself. Updated every two weeks.
- Best tweets about AI WorkflowsDiscover the best tweets about AI workflows, featuring practical automations, tool chains, agents, integrations, reliability, and measurable outcomes.
- Best tweets about Claude CodeRead the best tweets about Claude Code, covering terminal workflows, agents, hooks, skills, debugging, and real software projects. Updated every two weeks.
- Best tweets about GrokRead the best tweets about Grok and xAI, including model updates, features, benchmarks, developer access, and user experiments. Updated every two weeks.