Ловушка RAG без состояния: почему архитектура ИИ на этапе запроса не справляется с задачей

By Mirko Peters · 2026-08-13

Automatically translated with AI from the original post. Read the English original

Cover: Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It

Добро пожаловать обратно в блог! Если вы следите за нашими подкастами об корпоративном искусственном интеллекте, вы знаете, что мы много времени уделяем тому, чтобы заглянуть за первоначальный ажиотаж вокруг современных инструментов повышения производительности. В типовой демонстрации такие инструменты, как Microsoft Copilot, могут выглядеть удивительно умными. Они находят документ проекта, резюмируют политику, извлекают информацию из SharePoint и связывают фрагменты корпоративного контента в убедительный ответ. Но за этим впечатляющим пользовательским опытом скрывается фундаментальное архитектурное ограничение: поиск — это не память. Copilot может искать по всей вашей организации, но это не значит, что он выстроил устойчивое понимание вашей организации. В этом посте мы подробно разберём механику Retrieval-Augmented Generation, чтобы понять, как разбиение на фрагменты и циклы запросов без сохранения состояния не позволяют ИИ удерживать накопленный контекст между взаимодействиями в организации. Обязательно послушайте связанный эпизод подкаста Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It, где эти концепции разобраны подробнее.

Copilot не запоминает — он извлекает

Опыт работы с Copilot создаёт важную иллюзию. Когда он успешно связывает информацию из Microsoft 365, может показаться, что система что-то узнала об организации. Однако если задать похожий вопрос позже, система может выдать другой результат, потому что она выполняет новую операцию извлечения, а не просто воспроизводит понимание, сформированное ранее. Это различие становится критичным, когда организации выходят за рамки базового суммирования и начинают ожидать от ИИ поддержки реальных решений.

Если по сути одинаковые вопросы дают противоречивые ответы в зависимости от того, какая информация была извлечена, пользователи быстро начинают неохотно полагаться на ИИ в задачах, важных для бизнеса. В результате возникает проблема внедрения, а не только техническая проблема. Пользователям нужна предсказуемость, и когда ассистент дает один ответ в понедельник и противоречащий ему ответ в четверг на тот же самый запрос, доверие начинает быстро разрушаться.

Что на самом деле делает Retrieval-Augmented Generation

RAG расшифровывается как Retrieval-Augmented Generation. Если упростить, корпоративные документы делятся на фрагменты, эти фрагменты представляются в виде эмбеддингов, вопрос пользователя преобразуется в сопоставимое представление, и система ищет семантически релевантные фрагменты. Наиболее релевантные части информации затем передаются языковой модели как контекст для генерации ответа.

Эта архитектура чрезвычайно полезна. Она позволяет большой языковой модели отвечать на вопросы, используя информацию, которой не было в её исходных обучающих данных, и даёт практичный способ опирать ответы ИИ на корпоративный контент. Но она также создаёт важное архитектурное ограничение: модель получает фрагменты, отобранные для текущего запроса, а не поддерживает полное постоянное представление знаний организации.

Проблема разбиения на фрагменты

Корпоративные знания редко существуют в виде изолированных абзацев. План проекта может содержать зависимости, разбросанные по десяткам страниц. Одна политика может ссылаться на другую. Техническая архитектура может зависеть от решений, задокументированных месяцами ранее в заметках собраний, разговорах в Teams, страницах SharePoint и проектных документах.

Традиционный RAG разбивает эти источники на более мелкие единицы и определяет, какие фрагменты кажутся релевантными текущему вопросу. Поэтому модель видит отобранные части, а не обязательно понимает весь документ и все его связи. Для простого поиска информации это может работать очень хорошо. Но для вопросов, требующих учёта связей, исторического контекста, зависимостей, накопленных решений или рассуждений по множеству источников, ограничения становятся гораздо заметнее.

Ловушка RAG без состояния

Обычный workflow извлечения информации по своей природе не предполагает, что что-то уже «понято». Поступает вопрос, извлекается информация, генерируется ответ, и процесс фактически начинается заново для следующей операции извлечения. Именно в этом месте статeless-природа RAG становится серьёзным препятствием.

Знания, обнаруженные в ходе одного взаимодействия, автоматически не становятся устойчивым организационным знанием, доступным каждому последующему взаимодействию. Для корпоративного ИИ это принципиальное различие. Организациям нужно не просто более качественный поиск. Им всё чаще требуются системы, способные поддерживать структурированное понимание проектов, процессов, политик, технологий, людей, решений, зависимостей и связей между ними.

Поиск знаний против компиляции знаний

Это подводит нас к центральной архитектурной идее, которую мы разбираем в нашем последнем аудиосериале: что, если вместо многократного восстановления организационных знаний на этапе запроса ИИ будет заранее компилировать эти знания? LLM Wiki как раз и представляет этот сдвиг в мышлении.

Вместо того чтобы рассматривать каждый корпоративный документ как очередной набор фрагментов, ожидающих извлечения, искусственный интеллект может синтезировать информацию в структурированные артефакты знаний, которые отражают то, что организация понимает на данный момент. Важное изменение здесь не просто в другом пользовательском интерфейсе. Речь о переходе от восстановления знаний в момент запроса к постоянному синтезу знаний.

Почему LLM Wiki меняет модель

Представьте тысячи документов, описывающих один и тот же продукт, клиента, проект, политику или архитектуру. Традиционный RAG ждёт вопроса, а затем пытается найти фрагменты, которые с наибольшей вероятностью на него ответят. Подход LLM Wiki вместо этого стремится непрерывно преобразовывать эти разрозненные источники в связные страницы знаний.

Связи, решения, определения, зависимости, исторический контекст и подтверждающие источники могут стать частью поддерживаемого представления знаний. Copilot или другой ИИ-агент затем может извлекать информацию из слоя, содержащего синтезированное понимание организации, вместо того чтобы снова и снова пытаться восстанавливать это понимание из исходных документов.

От репозитория документов к слою знаний

Это меняет роль таких систем, как SharePoint. SharePoint может и дальше служить авторитетным репозиторием документов, страниц, политик, презентаций, материалов собраний и контента для совместной работы. Но необработанный корпоративный контент автоматически не становится пригодным организационным знанием.

Слой знаний, созданный ИИ, может располагаться над исходными системами и превращать разрозненную информацию в нечто большее похожее на карту организации: проекты, связанные с решениями, политики, связанные с процессами, системы, связанные с владельцами, и понятия, связанные с подтверждающими их данными. Цель не в том, чтобы устранить исходные документы. Цель в том, чтобы сделать явными связи, скрытые внутри них.

Почему лучшие промпты не решают проблему архитектуры

Prompt engineering может улучшить то, как LLM интерпретирует извлечённый контекст, но не может гарантировать, что правильный контекст вообще был извлечён. Если слой извлечения возвращает неполные фрагменты, пропускает важную зависимость или выдаёт устаревший документ, даже отличная модель рассуждает на основе неполного набора информации.

Поэтому одного лишь совершенствования модели недостаточно для решения всех проблем корпоративного ИИ. Качество и структура знаний, передаваемых модели, остаются фундаментальными. Никакое мастерство составления промптов не исправит архитектуру, которая опирается на мимолётные результаты поиска вместо структурированной, постоянной памяти.

Проблема управления становится серьёзнее

С этой архитектурой связано и важное предупреждение. Если в среде SharePoint организации есть устаревшие политики, дублирующая документация, брошенные процессы, противоречивые инструкции или документы без чёткого владельца, LLM Wiki с такой же эффективностью синтезирует плохую информацию, как и хорошую.

Опасность в том, что синтезированные знания могут выглядеть заметно чище и авторитетнее, чем заслуживает исходное содержимое. Поэтому ИИ делает традиционное управление информацией не менее, а более важным. Владение контентом, управление жизненным циклом, версионирование, хранение, процессы архивирования, авторитетные источники, метаданные и чётко определённые системы записи становятся фундаментальными компонентами архитектуры ИИ.

Готовность к ИИ начинается с качества контента

Организации часто рассматривают готовность к Copilot как проект по лицензированию, безопасности, развёртыванию или обучению. Эти элементы важны, но не менее важна среда знаний, на которой всё держится. Если никто не знает, какой документ описывает актуальный процесс, ИИ не сможет волшебным образом разрешить организационную неоднозначность.

Если три отдела ведут противоречивые версии одной политики, ИИ унаследовал три «версии истины». Если устаревшая документация остаётся доступной для поиска бесконечно долго, она по-прежнему остаётся потенциальным материалом для ответов. Корпоративный ИИ, таким образом, вскрывает долги в управлении знаниями, которые организации раньше могли игнорировать.

Почему доверие определяет принятие Copilot

Технические последствия быстро становятся бизнес-последствиями. Пользователи могут мириться с отдельными несоответствиями, когда ИИ используется для составления письма или краткого изложения собрания. Терпимость резко снижается, когда от ИИ ожидают разъяснения политики, поддержки решений по работе с клиентами, интерпретации статуса проекта, предоставления сведений о соответствии требованиям или сопровождения операционных процессов.

Столкнувшись с противоречивыми ответами на важные вопросы, пользователи часто возвращаются к проверенным экспертам и привычным ручным процессам. Это одна из главных причин, почему после внешне успешного внедрения Copilot интерес к нему может угаснуть. Поэтому доверие становится архитектурным требованием, а не просто метрикой внедрения.

Заключение

Подводя итог, можно сказать: Retrieval-Augmented Generation дал корпоративному ИИ мощный способ обращаться к внешним документам, однако его «безсостоянийные» циклы запросов и ограничения фрагментации (chunking) означают, что он часто не способен стать настоящей организационной памятью. Без постоянной компиляции знаний такие системы, как Copilot, будут по-прежнему испытывать трудности с согласованностью, глубокими смысловыми связями и доверием со стороны предприятия. Переход от необработанных хранилищ документов к структурированному, скомпилированному слою знаний, например к новому подходу LLM Wiki, — ключ к тому, чтобы перекинуть мост между эффектными демонстрациями и надёжными бизнес-инструментами. Чтобы глубже разобраться в теме и послушать наш полный разбор того, как исправить память корпоративного ИИ, обязательно послушайте весь эпизод на сайте Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It.