Почему проекты RAG проваливаются на втором месяце после удачной демонстрации

Почему демонстрация перестаёт работать для людей

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

В реальной работе всё грубее. Люди задают расплывчатые вопросы, используют старые названия проектов, смешивают сленг с внутренними терминами и опускают контекст, который, как им кажется, бот уже знает. Демонстрация переживает аккуратные подсказки. Ежедневная работа — нет.

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

Актуальность — следующая проблема. Внутренние документы меняются всё время. Каждую неделю появляются новые политики, заметки с митингов, рука‑буки, правила ценообразования и обновления продуктов. Если индекс отстаёт, бот отвечает по прошлому месяцу. Пользователи редко прощают это дважды.

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

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

Типичный пример на втором месяце выглядит так: компания запускает ассистента поддержки, обученного на документации продукта и старых тикетах. В демо он решает типичные вопросы за секунды. Через шесть недель команда продукта выпустила обновления, поддержка переименовала рабочий процесс, а новое правило биллинга осталось в PDF, который никто не проиндексировал. Бот по‑прежнему отвечает быстро, но теперь смешивает старые и новые правила. Агентам удобнее спросить коллегу.

Система не стала вдруг глупее. Компания изменилась, вопросы стали более неопрятными, а извлечение не успело за изменениями. Как только пользователи теряют доверие, даже приличные ответы перестают иметь значение.

Как проявляется слабое извлечение

Слабое извлечение часто выглядит нормально в тестировании и неправильно в повседневной работе. Люди задают обычные вопросы, получают отшлифованные ответы и всё равно уходят с неправильным действием.

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

Чанкинг создаёт ещё одну тихую проблему. Один чанк заканчивается правилом, следующий начинается исключением, а извлечение берёт только половину картины. Модель заполняет пробел гладкой догадкой. Пользователи не видят недостающий контекст — они видят только уверенный ответ.

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

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

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

Самый быстрый способ заметить слабое извлечение — читать исходные сниппеты, а не финальный ответ. Если сниппеты кажутся смежными с вопросом, а не непосредственно полезными, инструмент уже начинает дрейфовать.

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

Как вкрадывается устаревший контент

Если хотите понять, почему инструмент RAG сходит на нет после запуска, посмотрите, что происходит с документами. Модель остаётся прежней, а компания меняется. Политики, заметки, правила ценообразования и шаги поддержки двигаются каждую неделю.

Так формируется устаревшая база знаний. Это никто не планирует. Она растёт из мелких разрывов между тем, где лежит последний документ, и тем, что видит ретривер.

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

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

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

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

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

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

Это часто первая находка внутреннего AI‑аудита. Слабое извлечение привлекает внимание, потому что звучит технически. Устаревший контент проходит мимо, потому что демо всё ещё звучит умно — до того момента, пока кто‑то не последует неверному правилу.

Настройте простую рутину оценки

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

Соберите небольшой тест‑набор из реальных вопросов и прогоняйте его каждую неделю. Начните с 20–50 вопросов из чатов поддержки, Slack‑тредов, тикетов или логов поиска. Делайте их простыми и реалистичными. Для каждого вопроса отметьте документ или раздел, который должен быть источником ответа. Если приемлемо несколько источников — запишите и их. Это превращает расплывчатую обратную связь вроде «бот стал хуже» в измеримую величину.

Оценивайте извлечение и ответы отдельно

Рассматривайте извлечение и генерацию ответа как два разных шага. Если объединим их, настоящая проблема скроется.

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

Это разделение экономит время. Если извлечение провалилось, настройка подсказок мало поможет. Если извлечение в порядке, а ответ всё равно неправильный, возможно, модель плохо суммирует, пропускает условие или смешивает два документа.

Держите тест‑набор актуальным

Разбирайте промахи каждую неделю. Часто 20 минут хватает. Ищите паттерны, а не отдельный плохой ответ. Может быть, вопросы по финансам падают из‑за мелкого разбиения таблиц на чанки. Может быть, ответы HR дрейфуют, потому что бот всё ещё тянет политику прошлого квартала.

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

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

Реалистичный пример поддержки на втором месяце

Внутренний HR‑бот часто хорошо смотрится на демо, потому что тестовые вопросы чистые, а исходные файлы свежие. Через месяц обычная работа выведет трещины на свет.

Представьте компанию, которая запустила бота для простых HR‑вопросов. Сотрудники спрашивают про оплачиваемый отпуск, перенос дней и правила утверждения. В первую неделю бот кажется надёжным: он берёт ответы из сотруднического справочника и даёт короткие понятные ответы.

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

Бот продолжает находить старую страницу справочника, потому что она ранжируется выше. Может быть, она использует точные слова, которые вводят люди. Может быть, она разбита на более аккуратные чанки. Может быть, новый документ лежит в папке, которую индекс пропустил. Результат прост: ответ звучит уверенно, но неверен.

Несколько сотрудников планируют отпуск, опираясь на старое правило. Один менеджер замечает рассогласование только после того, как кто‑то процитировал бота в сообщении. К тому моменту часть персонала уже столкнулась с ошибкой до того, как команда, отвечающая за инструмент, узнала о проблеме.

Этот момент ранит сильнее, чем сам неверный ответ. Люди перестают рассматривать бота как полезный инструмент и начинают считать его риском. Даже после того как HR исправит источник и реиндексирует файлы, многие сотрудники будут перепроверять ответы у человека. Некоторые перестанут пользоваться ботом вовсе.

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

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

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

Ошибки команд после запуска

Большинство команд расслабляются сразу после удачного демо. Они тестировали бота на небольшом наборе чистых вопросов и документах, которые легко извлечь, и все ушли со встречи впечатлёнными. Реальные сотрудники так не спрашивают.

Первая ошибка — оценивать ответы по тону, а не по правде. Гладкий уверенный ответ кажется правильным, поэтому команды ставят «галочку». Но речная проверка проще: вытянул ли бот нужный источник и ответил ли он из него, не выходя за пределы?

Вежливый неверный ответ всё ещё тратит время. Иногда он создаёт больше работы, чем отсутствие ответа.

Другая ошибка — позволять контенту становиться грязным. Кто‑то добавляет черновики, старые заметки митингов, копии страниц политик и недоделанные руководства в тот же индекс, что и утверждённые материалы. Тогда бот берёт неверный чанк и даёт правдоподобный ответ, ссылаясь на правило, которое никогда не было утверждено.

Устаревшая база знаний не всегда выглядит устаревшей на поверхности. Иногда лишь малая часть контента стареет, но именно она попадает на самые частые запросы.

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

Одно правило помогает: у каждой коллекции документов должен быть владелец, и у каждого типа ответов — проверенный источник. Если никто не владеет, бот будет гадать между смешанными материалами.

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

Для многих внутренних инструментов базового еженедельного обзора хватает. Прогоните те же 15–20 реальных вопросов. Посмотрите на извлечённые источники, а не только на формулировку финального ответа. Удалите черновики и дубликаты из индекса. Обновите документы, которые изменились за неделю. Логируйте промахи и смотрите на повторения.

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

Быстрые проверки на этой неделе

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

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

Для каждого вопроса откройте точные чанки, которые модель подтягивает. Читайте их, не давая модели кредит за уверенный тон. Если чанки расплывчатые, смежные или лишены нужной детали политики, ответ уже на шаткой почве.

Потом проверьте исходные документы за этими чанками. Два показателя многое скажут: когда документ последний раз менялся и кто сейчас его владелец. Если никто не может ответить на оба — вероятно, у вас уже устаревшая база знаний.

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

Сначала уберите явный мусор. Удалите дубликаты, которые говорят одно и то же чуть иначе. Заархивируйте устаревший контент, чтобы он не конкурировал с актуальным. Если документ активен, но запутан — перепишите источник, прежде чем вы будете подстраивать подсказки или менять модель.

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

После десяти–пятнадцати записанных промахов паттерны станут очевидны. Вы увидите, связано ли это с плохим извлечением, устаревшим контентом, неверным чанкингом или отсутствием владельцев.

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