Саму языковую модель сегодня получить несложно. Можно подключить готовый API, выбрать подходящую модель и уже через несколько часов собрать прототип. Проблемы начинаются позже — когда консультанту нужно отвечать не на демонстрационные вопросы, а на реальные запросы пользователей, учитывать внутренние документы компании, работать с актуальными данными и при этом не придумывать ответы.
Поэтому разработку ИИ-консультанта правильнее рассматривать не как задачу «подключить ChatGPT», а как создание полноценной системы вокруг языковой модели.
Сначала нужно понять, что именно должен делать консультант
Одна из самых распространённых ошибок — начинать проект с выбора модели. На мой взгляд, начинать нужно с обратного вопроса: какие задачи мы хотим передать системе? Например, консультант может:
- отвечать на вопросы по продуктам и услугам;
- искать информацию во внутренних документах;
- помогать сотрудникам находить нужные инструкции;
- подбирать подходящий продукт по заданным условиям;
- объяснять пользователю результаты расчётов;
- принимать обращения и передавать сложные случаи оператору;
- работать с голосовыми запросами.
Это разные задачи, и для них не обязательно нужна одна и та же архитектура. Если консультант должен только отвечать на вопросы по базе знаний, нет большого смысла обучать собственную языковую модель. В большинстве случаев разумнее использовать готовую модель и правильно организовать доступ к корпоративным данным.
Если же система должна принимать решения на основании большого количества структурированных данных, архитектура будет уже другой: языковая модель станет только одним из компонентов.
Главная проблема — не модель, а данные
Языковая модель не знает внутренние правила конкретной компании просто потому, что её подключили к приложению.
Допустим, у банка есть несколько тысяч документов: тарифы, инструкции, условия продуктов, ответы службы поддержки, внутренние регламенты. Передать всё это модели в каждом запросе невозможно и экономически бессмысленно.
Поэтому обычно строят отдельный контур работы с базой знаний. Документы сначала приводятся к единому виду, разбиваются на смысловые фрагменты, после чего для них создаются векторные представления — embeddings. Эти представления позволяют искать документы не только по совпадению слов, но и по смыслу.
Упрощённо процесс выглядит так:
документы → подготовка → фрагменты → embeddings → векторное хранилище → поиск → контекст для модели → ответ.
Именно этот подход часто называют RAG — Retrieval-Augmented Generation. Но здесь есть важный нюанс. Сам факт использования RAG ещё не означает, что консультант будет хорошо отвечать. Если документы плохо разбиты, в них много дублей или устаревшей информации, поиск будет возвращать неподходящий контекст. В результате даже хорошая модель получит плохие исходные данные.
Как устроен поиск по базе знаний
Представим, что пользователь спрашивает:
«Можно ли досрочно закрыть вклад и что будет с процентами?»
Система не должна отправлять в языковую модель всю базу документов. Сначала запрос пользователя превращается в вектор. Затем этот вектор сравнивается с векторами фрагментов документов. Система выбирает наиболее близкие результаты и передаёт их модели в качестве контекста.
После этого модель формирует ответ уже на основании найденной информации.
Для хранения и поиска векторов могут использоваться разные решения: FAISS, Milvus, Pinecone и другие. Выбор зависит от инфраструктуры проекта, требований к масштабированию, стоимости и вопросов хранения данных.
И здесь снова нет универсального варианта. Для небольшого внутреннего сервиса может оказаться достаточно относительно простой схемы. Для крупной системы с большим количеством пользователей понадобятся более серьёзные механизмы индексации, фильтрации, кеширования и мониторинга.
Почему нельзя просто дать модели доступ ко всем документам
Потому что количество контекста ограничено, а его обработка стоит денег и времени. Кроме того, большой объём нерелевантной информации иногда только ухудшает ответ. Модели приходится выбирать нужные сведения среди большого количества похожих фрагментов.
Поэтому качество консультанта во многом определяется не только самой LLM, но и качеством retrieval-части. На практике приходится проверять как минимум несколько вещей:
- насколько часто нужный документ вообще находится;
- насколько высоко в результатах поиска он оказывается;
- не попадают ли в контекст устаревшие версии документов;
- достаточно ли информации в найденном фрагменте;
- умеет ли система отказываться от ответа, если данных недостаточно.
Последний пункт особенно важен. Хороший консультант — это не тот, который отвечает на любой вопрос. Хороший консультант умеет сказать: «В доступных данных я не нашёл информации, поэтому лучше передать вопрос специалисту».
Готовая модель или собственная
Для большинства проектов не требуется обучать собственную большую языковую модель с нуля. Готовая модель позволяет намного быстрее запустить первую версию продукта. В этом случае команда занимается не созданием LLM, а архитектурой вокруг неё: поиском, базой знаний, интеграциями, безопасностью и контролем качества.
Есть и другой вариант — локальное развёртывание модели. Он может быть оправдан, когда данные нельзя передавать во внешние сервисы или когда требуется полный контроль над инфраструктурой. Но у такого подхода есть своя цена: нужны GPU, обслуживание инфраструктуры, обновление моделей и специалисты, которые смогут всё это поддерживать.
Поэтому вопрос обычно стоит не так:
«Что лучше — GPT или локальная модель?»
Правильнее спросить:
«Какие ограничения есть у конкретного проекта и какая архитектура лучше соответствует этим ограничениям?»
Для одного продукта критичной окажется стоимость запросов. Для другого — требования к безопасности. Для третьего — скорость ответа или возможность работать полностью внутри собственной инфраструктуры.
А где здесь обычный backend?
Он никуда не исчезает. ИИ-консультант — это не только языковая модель. В реальном приложении вокруг неё всё равно нужен обычный backend. Например, запрос пользователя может пройти примерно такой путь:
- приложение получает сообщение;
- backend определяет пользователя и его права;
- запрос очищается и классифицируется;
- система обращается к базе знаний или другим сервисам;
- найденный контекст передаётся модели;
- модель формирует ответ;
- backend проверяет результат;
- ответ возвращается пользователю.
При необходимости сюда добавляются CRM, платёжные системы, каталоги товаров, внутренние API и другие источники данных. Итоговая архитектура будет выглядеть примерно так:
flowchart TD
U1["Пользователь"]
FE["Frontend / API"]
BE["Backend
права / логика"]
KB["База знаний
/ RAG"]
CRM["CRM / API /
бизнес-данные"]
LLM["LLM"]
CHECK["Проверка ответа
+ ограничения"]
U2["Пользователь"]
U1 --> FE
FE --> BE
BE --> KB
BE --> CRM
KB --> LLM
CRM --> LLM
LLM --> CHECK
CHECK --> U2
Поэтому разработка ИИ-консультанта — это скорее интеграционный проект, чем отдельная задача по машинному обучению.
Что выбрать в качестве технологического стека
Конкретный стек зависит от проекта, но часто backend для таких систем строят на Python. Он удобен благодаря большому количеству инструментов для работы с ML и LLM.
Для хранения обычных данных может использоваться PostgreSQL. Для векторного поиска — специализированная БД или отдельный векторный индекс.
На уровне API подойдут стандартные REST или другие подходы, которые уже используются в инфраструктуре компании. При этом не стоит собирать проект только из самых модных технологий.
Если обычная реляционная база решает задачу, необязательно добавлять ещё три новых сервиса. Если готовая модель подходит по качеству, нет смысла обучать собственную только ради того, чтобы она была собственной.
Хорошая архитектура обычно получается не из максимального количества технологий, а из достаточного количества технологий.
Самая недооценённая часть проекта — тестирование
Демо можно собрать практически из чего угодно. Пользователь задаёт пять заранее подготовленных вопросов, система отвечает — всё выглядит отлично. Но этого совершенно недостаточно, чтобы запускать консультанта в продакшен.
Нужен набор реальных сценариев: простые вопросы, сложные вопросы, опечатки, неполные формулировки, несколько вопросов в одном сообщении, вопросы вне области компетенции системы.
Полезно отдельно проверять и случаи, когда в базе есть похожая, но неправильная информация. Например, старый тариф может практически совпадать с новым. Если система найдёт старый документ, пользователь получит убедительный, но неверный ответ.
Поэтому документы должны иметь версии, даты и метаданные, а механизм поиска — учитывать эту информацию.
ИИ нужно измерять не только по «красоте» ответов
Фраза «ответ выглядит хорошо» практически ничего не говорит о качестве системы. Намного полезнее измерять конкретные показатели:
- долю вопросов, на которые система отвечает корректно;
- долю случаев, когда находится нужный документ;
- количество ответов без достаточного основания;
- среднее время ответа;
- стоимость одного обращения;
- процент обращений, переданных оператору;
- удовлетворённость пользователей.
Набор метрик зависит от задачи. Для внутреннего помощника важнее может быть точность поиска по документации. Для клиентского сервиса — доля обращений, которые удалось решить без оператора. Для голосового интерфейса добавятся показатели распознавания речи и задержки ответа.
Что происходит после запуска
Запуск — это не конец разработки. Первые реальные пользователи почти всегда находят сценарии, о которых команда не подумала во время тестирования.
Поэтому после запуска нужно смотреть логи, анализировать неудачные диалоги, обновлять базу знаний и следить за изменениями в бизнес-логике.
Отдельно стоит контролировать стоимость запросов. Иногда система отвечает правильно, но отправляет в модель слишком большой объём контекста. На небольшом количестве пользователей это незаметно, а при росте нагрузки расходы начинают быстро увеличиваться.
Полезно также разделять проблемы. Если пользователь получил неправильный ответ, нужно понять, где именно произошла ошибка:
- не нашли нужный документ;
- нашли не тот документ;
- передали слишком мало контекста;
- модель неправильно интерпретировала контекст;
- бизнес-логика была реализована неверно.
Без такой диагностики команда рискует бесконечно менять модель, хотя проблема на самом деле находится в поиске или данных.
Безопасность — отдельная задача
Для финансовых и других чувствительных сценариев этот вопрос особенно важен. История обращений, транзакции, персональные данные и внутренняя документация не должны автоматически попадать в модель без продуманной политики обработки данных. Нужно заранее определить:
- какие данные можно передавать модели;
- что необходимо обезличивать;
- какие документы доступны конкретному пользователю;
- где хранятся запросы и ответы;
- сколько времени они сохраняются;
- кто имеет доступ к логам.
Техническая архитектура здесь должна учитывать не только производительность, но и требования законодательства и внутренние политики компании.
Отдельный риск — prompt injection. Если консультант получает информацию из внешних документов, сайтов или загруженных пользователем файлов, нельзя считать весь полученный текст доверенным. Документ может содержать инструкции, которые попытаются повлиять на поведение модели. Поэтому критические действия должны контролироваться бэкэндом, а права модели — ограничиваться минимально необходимыми.
ИИ-консультант — это не просто чат с моделью
Если убрать маркетинговую оболочку, хороший ИИ-консультант представляет собой довольно понятную систему.
Есть пользовательский интерфейс. Есть backend. Есть база данных. Есть поиск по знаниям. Есть языковая модель. Есть бизнес-логика и интеграции. И поверх всего этого — мониторинг и постоянное улучшение.
Модель в этой схеме действительно важна, но она не является единственным или даже всегда главным компонентом.
На качество конечного продукта гораздо сильнее влияют исходные данные, качество поиска, архитектура, ограничения модели и то, насколько хорошо команда умеет проверять результаты.
Поэтому я бы начинал такой проект не с вопроса «какую нейросеть будем использовать?», а с гораздо более приземлённых вопросов:
Что должен уметь консультант? Откуда он будет брать информацию? Что ему запрещено делать? Как мы поймём, что он ошибся? И что произойдёт, если он не сможет ответить?
Когда на эти вопросы есть ответы, выбор технологий становится значительно проще.
Именно тогда ИИ-консультант перестаёт быть красивой демонстрацией и превращается в нормальный программный продукт, которым действительно можно пользоваться.
