Языковые модели и данные компании: где проходит граница
Когда компания решает встроить языковую модель в продукт или процесс, первый вопрос — не «какая модель лучше», а «какие данные она увидит». От ответа зависят архитектура, стоимость и то, что можно обещать клиентам и юристам. Мы решаем это до оценки проекта, а не после запуска.
Три способа подключить модель
Внешний провайдер. Запросы уходят к модели через API — напрямую или через шлюз, который распределяет их между несколькими провайдерами. Это самый быстрый путь и доступ к сильнейшим моделям, но данные из запроса передаются третьей стороне. Поэтому заранее фиксируем, какие классы данных разрешено отправлять, как провайдер хранит запросы и использует ли их для обучения, в каком регионе идёт обработка и что нужно убрать или обезличить перед отправкой. Если используется внешний API, обещать «данные не покидают компанию» нельзя.
Региональный провайдер. Когда важны юрисдикция, договор с провайдером или инфраструктурная граница, выбираем модель, доступную в нужной стране. Происхождение провайдера не заменяет проверки: условия хранения и обработки читаем так же внимательно, как у любого другого.
Модель на ваших серверах. Модель с открытыми весами разворачивается на GPU компании, и запросы не выходят за её инфраструктуру. Это требует своего оборудования и эксплуатации, а выбор ограничен моделями, которые можно развернуть самостоятельно. Для прототипа модель можно запустить и на рабочей машине, но это не замена промышленного развёртывания.
Шесть вопросов до оценки проекта
- Какие данные можно отправлять внешнему провайдеру, а какие — нет.
- Что нужно обезличить, агрегировать или удалить из запроса.
- Нужен ли режим, при котором модель работает в вашей инфраструктуре.
- Кто хранит запросы и ответы модели и сколько времени.
- Какие метрики можно собирать, не сохраняя содержимое запросов.
- Как удаляются данные после завершения проекта.
Ответы определяют архитектуру. Если, например, договоры нельзя отправлять внешним сервисам, база знаний по ним строится с векторным поиском и моделью внутри вашего контура — даже когда внешний API был бы дешевле.
Качество измеряют, а не обещают
Качество языковой модели зависит от данных и от того, как поставлена задача, поэтому мы не гарантируем метрики заранее. Вместо этого собираем набор примеров из вашего процесса — вопросы с правильными ответами, типичные документы, сложные случаи — и измеряем по нему каждое изменение: другую модель, новый промпт, иной способ поиска по документам. Итерации входят в проект, а о рисках говорим до начала работ.
Отдельно проверяем поведение на границах: что модель отвечает, когда в документах нет ответа, как реагирует на вопросы не по теме и не показывает ли то, что пользователю видеть нельзя.
Агенту — минимум прав
Если модель не только отвечает, но и действует — создаёт задачи, пишет в CRM, отправляет письма, — к границе данных добавляется граница полномочий. Агент получает только те права, которые нужны сценарию, важные действия подтверждает человек, а каждый шаг записывается в журнал. Так ошибку можно найти и исправить, а не обнаружить по последствиям.
С чего начать
С одного процесса, где понятны правила и легко проверить результат. На нём согласуем режим работы с данными, соберём набор примеров и измерим, есть ли эффект. Только после этого имеет смысл расширять внедрение.