Почему умные ассистенты должны уметь учиться после запуска

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

Проблема в том, что большинство таких ассистентов устроены по принципу «только для чтения». Один раз загрузили базу знаний — и всё. Дальше они лишь вытаскивают из неё куски и формулируют ответы. А ведь во время работы система генерирует массу ценного: удачные объяснения, синтез информации из разных документов, готовые решения типовых вопросов. Всё это просто выбрасывается после каждого ответа.

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

Вопрос в том, как сделать базу знаний живой, но при этом не потерять контроль над качеством. Эксперименты с так называемым двунаправленным RAG показывают интересный путь.

Классическая схема RAG (Retrieval-Augmented Generation) работает по одностороннему принципу: запрос → поиск в базе → генерация ответа. Это решает главную проблему — снижает риск выдумок, потому что ответ строится на внешних источниках. Но корпус знаний остаётся статичным.

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

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

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

Первая проверка — опора на источники. Каждое предложение ответа должно следовать из того, что реально было найдено поиском. Если средний балл ниже порога (в эксперименте использовали 0,65), ответ не принимается.

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

Третья проверка — новизна. Новый ответ не должен быть слишком похож на уже существующие записи в базе. Это предотвращает раздувание базы дубликатами. Порог новизны в эксперименте установили на уровне 0,10.

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

Сравнивали три подхода: обычный RAG (статичная база), наивная запись всех ответов и двунаправленный RAG с проверками. Результаты получились показательными.

По покрытию запросов релевантными материалами обычный RAG дал 20%. Наивная запись подняла показатель до 70%, но за счёт колоссального роста корпуса — в базу добавилось 500 новых документов. Двунаправленный RAG обеспечил 40% покрытия, добавив при этом всего 140 документов. То есть почти в два раза лучше обычного, но без неконтролируемого разрастания.

Качество ссылок — ещё более важный параметр. Здесь обычный RAG показал 58 баллов. Наивная запись обрушила показатель до 16 — потому что база наполнилась некачественными материалами, и ссылки перестали быть точной опорой. Двунаправленный RAG удержал качество на уровне 33, что заметно выше, чем при бездумном добавлении.

Цена за это — увеличение времени ответа. Обычный RAG отвечал за 32 секунды, двунаправленный — за 71. Но в экспериментах подчёркивают, что такой режим особенно разумен для офлайн-пополнения базы, где качество важнее скорости.

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

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

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

Но именно эта осторожность и отличает инженерный подход от «магических таблеток». Речь не идёт о том, чтобы сделать систему идеальной. Речь о том, чтобы сделать её управляемой и предсказуемой.

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

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

Если вы внедряли корпоративных ассистентов и сталкивались с проблемой устаревания базы знаний — интересно, как вы её решали? Какие подходы к контролю качества работают, а какие приводят к хаосу?