Трудности внедрения ИИ

Недавно MIT опубликовал отчет State Of AI In Business 2025: The GenAI Divide. Один из ключевых выводов: 95% корпоративных проектов по внедрению ИИ не доходят до стадии промышленной эксплуатации. Речь идет прежде всего о решениях класса Embedded or Task-Specific GenAI, когда под конкретную задачу разрабатывается собственное решение и интегрируется в бизнес-процесс. В случае General-Purpose LLMs, то есть при простом использовании моделей (включая доступ через API), процент успешных внедрений выше — 40%. В этой статье мы попытаемся разобраться в том, какие сложности могут быть на пути на примере классического сценария внедрения GenAI — RAG.

RAG (retrieval augmented generation) — это генерация ответа на основе найденных источников информации. Такой подход необходим, если требуется, чтобы LLM давала ответы не только лишь на основе того, чему была обучена тем или иным провайдером, а базируясь на внутренних источниках, например, корпоративных базах знаний. В качестве примера можно привести сервис McKinsey, в котором можно искать ответы на свои вопросы по их базе статей и исследований, а ИИ генерирует саммари на основе найденных источников.

Что происходит внутри таких сервисов?

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

На уровне прототипа всё выглядит просто: потребуется всего несколько строк кода в jupyter notebook или, например, несколько узлов в n8n (no-code решение). Однако за этой простотой скрываются сложности, которые становятся критичными на пути к промышленной эксплуатации.

Чтобы решение было по-настоящему качественным — например, чтобы клиент мог напрямую с ним работать — потребуется значительный объем работы.

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

Если стиль изложения в базе и формулировки вопросов пользователя различаются, качество ответов падает. В базе могут встречаться внутренние жаргонизмы, незнакомые конечному пользователю, или одни и те же термины могут быть записаны по-разному: rag/раг, peer-to-peer/пир-ту-пир/p2p. Если пользователь спрашивает в одном формате, а в базе термин встречается в другом, релевантный ответ может не быть найден, и LLM начнет «галлюцинировать».

Фрагментировать текст (разбивать на чанки) можно разными способами. Самый простой — делить на равные части по, например, 1 000 символов. Но так важная информация может оказаться в разных фрагментах: если нужные ключевые слова есть только в одном из них, система может пропустить часть ответа. Часто применяют разбиение с перекрытием (например, 200 символов): часть текста дублируется между фрагментами. Лучшее качество обычно достигается при полуручной разметке, когда эксперт корректирует фрагментацию и стиль изложения.

На рынке множество эмбеддинг-моделей — и open-source, и от провайдеров с доступом по API. Предсказать заранее, какая модель даст лучший результат, сложно. Можно сузить выбор, ориентируясь на язык базы (например, русский), но всё равно нужны эксперименты.

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

Сколько документов искать в базе и сколько их передавать в LLM — это тоже довольно важный вопрос. Если база документов устроена таким образом, что на каждый вопрос есть на самом деле 1 или максимум 2 документа, а в системе будет стоять задача искать топ-5 документов, то в выдаче, которая будет идти на вход LLM-модели, будет больше мусора, чем полезной информации. Это опять же будет негативно влиять на качество.

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

И это только вопросы, связанные с разработкой решения. На этапе эксплуатации возникают новые вызовы.

Эта часть процесса никуда не уходит. База знаний будет пополняться новой информацией, какая-то часть, наоборот, будет устаревать. Чтобы RAG выдавал по-прежнему высокое качество, потребуется постоянно следить за актуальностью базы документов. Поскольку ее источники могут быть разнородными (например, люди из разных команд и отделов), то кто-то должен это все аккумулировать и «причесывать» под потребности системы — своего рода архивариус.

Необходимо постоянно мониторить качество ответов RAG как с точки зрения точности ответов, так и с точки зрения того, достаточно ли документов в исходной базе знаний, чтобы отвечать на вопросы пользователей. Важно также предусмотреть возможность давать фидбек напрямую: оценка ответу или возможность оставить комментарий. Таким образом, всё взаимодействие с продуктом необходимо логировать и хранить в какой-то базе данных. Это означает, что продукт требует постоянного развития и управления — возникает потребность в продакт-менеджере.

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

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

Этой статьей хотелось продемонстрировать, сколько всего может лежать под капотом зрелого решения, использующего технологии GenAI. Очевидно, что здесь очень много стандартных вопросов, связанных с разработкой и эксплуатацией ПО, а также много вопросов, связанных с R&D-деятельностью, в рамках которой требуется много экспериментов и итераций, чтобы найти наилучшее решение под заданный кейс. В этом нет ничего страшного, возможное разочарование возникает в результате завышенных ожиданий, что ИИ — это волшебная пилюля, которая способна сделать всё сама без участия и усилий человека.

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