<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Vector Store on AI-Uchi — Всё об искусственном интеллекте</title><link>/tags/vector-store/</link><description>Recent content in Vector Store on AI-Uchi — Всё об искусственном интеллекте</description><generator>Hugo</generator><language>ru</language><lastBuildDate>Mon, 18 May 2026 08:00:00 +0300</lastBuildDate><atom:link href="/tags/vector-store/index.xml" rel="self" type="application/rss+xml"/><item><title>Agentic CRAG на n8n: умный RAG с самокоррекцией</title><link>/articles/agentic-crag-pipeline-n8n/</link><pubDate>Mon, 18 May 2026 08:00:00 +0300</pubDate><guid>/articles/agentic-crag-pipeline-n8n/</guid><description>&lt;h2 id="почему-обычный-rag-больше-не-справляется"&gt;Почему обычный RAG больше не справляется&lt;/h2&gt;
&lt;p&gt;Вы строите чат-бота поверх корпоративной базы знаний. Загружаете PDF, нарезаете чанки, кладёте в векторную базу, подключаете LLM — и радуетесь первым ответам. А потом приходит первый сложный вопрос: «Какова наша политика возвратов для клиентов Enterprise, оформивших заказ до Q3 2024?» — и система уверенно галлюцинирует.&lt;/p&gt;
&lt;p&gt;Проблема не в LLM и не в качестве данных. Проблема — в архитектуре.&lt;/p&gt;
&lt;p&gt;Классический RAG извлекает информацию один раз и генерирует ответ на основе единственного результата. Для простых, чётко сформулированных вопросов это работает. Но система начинает разрушаться, когда задача требует данных из нескольких источников, рассуждений поверх документов или уточнения неполных результатов.&lt;/p&gt;</description></item></channel></rss>