People keep writing obituaries for RAG. You have probably seen the headlines by now. Long context windows killed it. Agents replaced it. The whole pattern is obsolete. The truth is narrower and far more useful. RAG did not die. What actually collapsed was the comfortable illusion that you could split a pile of documents into chunks, feed them into a vector database, and suddenly own a reliable, truthful AI.

A few years ago, the pitch was seductive in its simplicity. Embed your knowledge base. Connect it to an LLM. Ask a question, and watch the model answer using only your retrieved data. For controlled demos and small FAQ bots, this honestly worked. A twenty-page help desk manual. A tidy internal wiki. The bot would more or less cite the right paragraph, and leadership would sign off on the pilot. But pilots are not production. Prototypes do not contain the scars of real business operations.

Production data is messy. It contains the same troubleshooting note copied across a dozen files, each with slightly different timestamps and conflicting status labels. It holds complex tables that bleed across pages, rendering nonsense when a splitter cuts them down the middle. It preserves contradictions without apology. The 2023 policy manual says one thing. The March 2024 amendment says another. The old PDF was never archived. The naive pattern of chunk, store, and retrieve treats every paragraph as an isolated island. It has no feel for hierarchy, version history, or conflict resolution. The model hallucinates not because the LLM is broken, but because the context it received was fragmented, orphaned, or outright wrong.

Some observers claim that million-token context windows make retrieval irrelevant. Their argument is straightforward. Just dump the entire corpus into the prompt and let the model read it all. This sounds elegant. It is also dangerously optimistic. A model may technically be able to ingest a volume of text equivalent to a short novel, yet locating one specific clause in the middle of that expanse remains an entirely different capability. Needles stay lost in haystacks. Long context windows expand the available canvas, but they do not solve the hard work of deciding what deserves a spot on that canvas. The problem was never simply retrieval. It is, and always has been, context assembly.

From Naive Retrieval to Context Engineering

In 2026, the field is maturing. We are moving past the phase where RAG was treated as a single linear pipeline and toward an architecture that treats context as a deliberately engineered product.

Hybrid search over pure semantics. Semantic similarity is excellent for understanding intent, but it is sloppy with precise identifiers. If an engineer queries a specific error code like ERR_CONNECTION_REFUSED or a software version like v3.2.1, pure vector search can dilute the exact match in a sea of conceptually similar but practically irrelevant results. The evolution here is straightforward. Modern systems combine dense vector retrieval with keyword search, using methods like BM25 or inverted indexes alongside embeddings. Exact names, error codes, version strings, and product IDs get caught by the keyword layer while conceptual nuance is handled by the vector layer.

Reranking before generation. Retrieval is naturally biased toward recall. You pull in forty or fifty chunks because you are terrified of missing the one golden paragraph. But feeding all of that noise into a large model wastes tokens and buries signal. Reranking solves this with a second, usually smaller model that scores each candidate for relevance against the specific query. The top five passages advance. The rest are discarded. It acts as a precision filter between retrieval and generation, ensuring the expensive reasoning model only reads what actually matters.

Contextual retrieval that preserves meaning. Chunking is a violent act. A splitter can sever a paragraph from its section header, its table caption, its surrounding legal disclaimer, or the footnote that modifies its meaning. Contextual retrieval mitigates this by enriching fragments before they ever reach the model. You prepend metadata indicating provenance: This excerpt belongs to the Q3 2024 incident report, Database Outage section, Severity Critical. The model sees not just a floating sentence but a situated piece of information. The fragment regains its bearings.

مسیریابی ماژولار بر اساس قصد. هر سوالی لزوماً متعلق به یک ذخیره‌ساز برداری (vector store) پر از مستندات نیست. کاربری که می‌پرسد چگونه رمز عبور خود را بازیابی کند، احتمالاً به یک مقاله راهنما نیاز دارد. کاربری که می‌پرسد چرا درآمد در شمال شرق در فصل گذشته کاهش یافته است، به اجرای SQL روی یک انبار داده (data warehouse) نیاز دارد، نه یک پاراگراف با شباهت معنایی درباره استراتژی فروش منطقه‌ای. سیستم‌های بالغ اکنون پرس‌وجوها را بر اساس قصد مسیریابی کرده و ابزار مناسب را انتخاب می‌کنند. مستندات برای دستورالعمل‌ها. پایگاه‌های داده رابطه‌ای برای تحلیل‌های ساختاریافته. تجمیع‌کننده‌های لاگ (Log aggregators) برای عیب‌یابی ردپاها (trace debugging). APIها برای وضعیت لحظه‌ای. لایه بازیابی (retrieval layer) به یک توزیع‌کننده (dispatcher) تبدیل می‌شود، نه یک رویکرد تک‌بعدی.

حلقه‌های استدلال عامل‌محور (Agentic). برخی سوالات را نمی‌توان تنها با یک مرحله جستجو پاسخ داد؛ آن‌ها نیاز به بازنگری و بازنویسی دارند. یک پرس‌وجوی اولیه مبهم، شفاف‌سازی می‌شود. ادعاهای بازیابی‌شده با منبع دوم تطبیق داده می‌شوند. اگر مستندات با مشخصات API در تضاد باشند، سیستم به جای ساختن یک راه حل میانه و ساختگی، تضاد را علامت‌گذاری می‌کند. مدل تصمیم می‌گیرد که چه زمانی دوباره جستجو کند، چه زمانی پرس‌وجوی خود را اصلاح کند و چه زمانی شواهد کافی برای پاسخگویی جمع‌آوری کرده است. این یک بازیابی تک‌مرحله‌ای (one-shot) نیست؛ بلکه یک استدلال ساختاریافته است که از جستجو به عنوان یک زیربرنامه (subroutine) استفاده می‌کند.

GraphRAG برای سوالات رابطه‌ای. برخی سوالات تجاری درباره ارتباطات هستند، نه جملات. نقص کدام قطعه باعث فعال شدن کدام هشدارهای پایین‌دستی شده است؟ کدام تأمین‌کننده مواد را به کدام کارخانه می‌رساند و مسیر جایگزین چیست؟ چه کسی در سازمان حق تصمیم‌گیری در مورد این ردیف بودجه خاص را دارد؟ تکه‌های متن تخت (Flat text chunks)، این روابط را از بین می‌برند زیرا هرگز برای حفظ توپولوژی طراحی نشده‌اند. گراف‌های دانش (Knowledge graphs) این کار را انجام می‌دهند. وقتی سوال درباره تأثیرگذاری، تبارشناسی (lineage)، الگوها یا ساختار شبکه باشد، پیمایش در یک گراف، بافتاری (context) را فراهم می‌کند که هیچ میزان از بازیابی پاراگراف نمی‌تواند آن را بازسازی کند.

سوالاتی که واقعاً اهمیت دارند

گفتگو پیرامون RAG باید تغییر کند. از پرسیدن اینکه چگونه یک خط لوله (pipeline) RAG عمومی بسازیم دست بردارید. شروع کنید به پرسیدن اینکه مدل باید چه وظیفه خاصی را حل کند، برای دقیق بودن به چه داده‌های دقیقی نیاز دارد و چگونه تأیید می‌کنید که بافتار (context) گردآوری‌شده کافی است. این سوالات شما را به سمت مسائل بنیادی‌تر مانند کیفیت داده، طراحی طرحواره (schema)، حلقه‌های تأیید و منشأ منابع سوق می‌دهند. آن‌ها مشخص می‌کنند که آیا پایگاه دانش شما اصلاً برای مصرف خودکار مناسب است یا خیر.

RAG دیگر یک فرآیند خطیِ واحد نیست که یک بار نصب کنید و فراموش کنید؛ بلکه دانشی است برای گردآوری بافتار مناسب تا مدل بتواند به شکلی مؤثر استدلال کند. این یعنی برخورد با بازیابی به عنوان یک مسئله طراحی سیستم، و نه صرفاً وارد کردن (import) یک کتابخانه.

ابزارها در حال دقیق‌تر شدن هستند. جستجو هیبریدی شده است. مسیریابی هوشمند است. بازیابی، رتبه‌بندی‌شده، غنی‌شده و تأییدشده است. توهمات ساده سال ۲۰۲۲ باید فرو می‌ریختند تا چیزی واقعاً مفید بتواند جای آن‌ها را بگیرد. وظیفه شما اکنون صرفاً بازیابی متن از یک پایگاه داده نیست؛ بلکه ساخت سیستم‌هایی است که قبل از اینکه مدل شروع به فکر کردن کند، بدانند مدل به چه چیزی نیاز دارد.

اگر در این حوزه فعالیت می‌کنید، انجمن یادگیری GyaanSetu مکانی برای تبادل نکات کاربردی با افرادی است که در حال حل مشکلات مشابه هستند: https://t.me/GyaanSetuAi