Платформа для внедрения языковых моделей - это не обертка над GigaChat. Как устроена наша Svaya, от маскирования персональных данных до работы в закрытом контуре банка

БизнесМатика - это ИТ-компания, которая работает с 2012 года. Мы занимаемся заказной разработкой ПО и внедряем проекты на базе языковых моделей (LLM) для компаний среднего и крупного бизнеса. В этой статье рассказываем о самой большой нашей собственной разработке (15 базовых сервисов в контейнерах Docker, 37 технических заданий на модули). Это LLM-платформа Svaya, на которой мы строим LLM-проекты для клиентов. Строили мы ее с применением LLM как инструмента разработки, под контролем и с приемкой наших инженеров. По этой статье видно, какие системы мы проектируем и строим на заказ.

Почему платформу для внедрения LLM обычно строят годами

Когда компания внедряет LLM в операционный процесс, сама LLM оказывается меньшей частью трудозатрат. Чат-бот вроде GigaChat или YandexGPT сам по себе отвечает на вопросы общего характера, но не проведет обращение покупателя или заявителя по этапам обработки до готового проекта решения (подготовленного системой вердикта, который в ответственных операциях утверждает сотрудник), не запишет результат в учетную систему компании и не будет соблюдать правила конкретной компании внутри процесса (например, то, какие операции обязан подтверждать человек). Чтобы LLM работала в операционном процессе банка или розничной сети, вокруг нее, как правило, нужны следующие подсистемы:

• Разграничение доступа, при котором сотрудник видит только свои заявки и только те документы, которые открыты его роли.
• Маскирование персональных данных перед тем, как текст запроса уйдет в LLM за пределы контура клиента (той сети и тех серверов, которые клиент контролирует).
• Журнал действий, по которому служба безопасности и аудитор проследят, на чем основан любой ответ системы.
• Поиск по документам компании (RAG, когда LLM отвечает по найденным документам), при котором база документов и поисковый индекс остаются в контуре клиента.
• Развертывание в контуре клиента, включая закрытый контур без доступа в интернет.
• Обновления, которые при нескольких копиях сервисов ставятся без остановки работы, и резервные копии данных с проверкой восстановления.
• Экраны для сотрудников, которые утверждают проекты решений по заявкам и разбирают очереди задач на проверку.
• Замер качества ответов перед выпуском изменений, чтобы обновление промптов (инструкций для LLM) или смена LLM не ухудшили ответы незаметно.

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

Два уровня платформы. Конвейер обработки запроса и готовые прикладные задачи

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

• Проверка прав того, кто обратился (сотрудника компании или покупателя на витрине интернет-магазина), на эту задачу и на документы, которые она затрагивает.
• Поиск по документам компании.
• Обращение к системам клиента через коннекторы, то есть модули подключения (например, узнать остатки на складе или записать результат в учетную систему).
• Маскирование персональных данных перед отправкой текста за пределы контура клиента.
• Вызов модели (LLM, а где задача этого требует, ML-модели или модели распознавания изображений).
• Проверка ответа на опору в найденных документах и на содержимое, которое запрещают правила из пакета задачи, то есть из набора файлов с маршрутом, промптами и правилами, который мы поставляем (например, запрет на обещания покупателю, которых компания не давала).
• Подстановка настоящих значений вместо условных обозначений (токенов), которыми были заменены персональные данные, последним шагом, перед выдачей ответа человеку или записью в учетную систему.

Если задаче какой-то шаг не нужен, в ее маршруте его нет. Описания товаров платформа пишет без поиска по документам, а в маршруте, который отдает покупателю выдачу умного поиска, нет вызова LLM (подсказку к этой выдаче готовит отдельный маршрут). Обойти шаг, который задаче положен, нельзя, потому что маршрут лежит в том же пакете задачи, и настройками, которые задает клиент, его не изменить.

Второй уровень - это готовые прикладные задачи, собранные на этом конвейере. 2 задачи кросс-отраслевые. Это извлечение полей из входящих документов и проверка документа на соответствие своду требований (отраслевым нормам или внутреннему регламенту). Еще 5 задач отраслевые, о них рассказываем ниже. Задачу, которой в этом наборе нет (например, ассистента по договорам и регламентам компании), мы собираем на том же конвейере под клиента.

Под клиента к платформе добавляются его данные, регламенты и подключение внешних систем. Документы и выгрузки из учетных систем клиент загружает через пошаговый мастер в интерфейсе платформы. Мастер показывает, чего в данных не хватает для запуска задачи. Свои настройки прикладной задачи клиент задает через такой же мастер, без программирования. Это пороги, при которых проект решения уходит на подтверждение человеку (в границах, заданных пакетом задачи), справочники тем обращений и свод требований, по которому идет проверка документов. При внедрении загрузку данных и настройку берет на себя наш специалист, если клиент открывает ему доступ на время работ. Настройки клиента лежат отдельным слоем и переживают обновление задачи. К 1С платформа подключается готовым коннектором, где под схему данных клиента настраивается сопоставление полей учетной системы с полями прикладной задачи. К другим системам коннекторы пишет наша команда при внедрении или разработчики клиента, по открытому протоколу MCP (стандарту подключения ИИ-систем к внешним источникам данных).

Сама LLM в платформе сменная. Прикладная задача работает на GigaChat, YandexGPT или на открытой LLM, которую можно скачать и запустить у себя, то есть развернуть on-premise, на серверах клиента. Например, на Qwen от Alibaba. Смена одной LLM на другую не требует переделки прикладной задачи, а после смены платформа перепроверяет качество ответов замером на эталонном наборе (примерах запросов с ожидаемыми ответами). Куда можно отправлять каждый класс данных, задано в пакете задачи, который поставляем мы. Классов данных шесть, среди них внутренние данные компании, персональные данные, банковская тайна и коммерческая тайна. Эти правила мастером настроек не меняются ни в одну сторону, и если политика безопасности клиента строже этих правил, мы выпускаем версию пакета с более жесткими правилами. Если поставщик LLM недоступен или отвечает ошибкой, платформа сама отправляет запрос на резервную LLM и по этому же правилу выбирает только ту, куда классу данных запроса выходить разрешено. Запрос с персональными данными уходит за пределы контура только через шаг маскирования.

Как проходит запрос. Маскирование персональных данных и журнал с проверкой целостности

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

Если в запросе или в найденных документах есть персональные данные, платформа перед отправкой текста за пределы контура заменяет их на условные обозначения. Она распознает 21 категорию таких данных, среди них ФИО, телефоны, паспорта, СНИЛС, номера счетов и карт, а когда распознаватель не уверен, действует правило «сомнение означает маскирование». Полноту маскирования мы замеряем на контрольном наборе документов как долю найденных упоминаний от всех, что в нем размечены. В наших требованиях приемки эта доля не ниже 98% на выходе за пределы контура, а по категориям с проверкой формата (паспорта, СНИЛС, ИНН, номера счетов и карт, телефоны, электронная почта) не ниже 99,5%. По ФИО порог ниже, 95%, по адресам и датам рождения 90%. Мы называем эти пороги отдельно, потому что прятать их в общем числе, которое вытягивают категории с проверкой формата, было бы нечестно.

Каждый шаг обработки оставляет след в трассе (подробной технической записи прохода запроса). События (кто спросил, какие документы взяла система, что ушло в LLM, какой вердикт вынесен по заявке) попадают в журнал действий. Записи журнала сцеплены контрольными суммами, а раз в час цепочка закрепляется якорем в объектном хранилище с запретом перезаписи. Поэтому правка или удаление записи задним числом рвет цепочку, и это видит проверка целостности. Такая защита не закрывает случай, когда администратор с правами на само хранилище снимает запрет перезаписи и согласованно переписывает журнал, якоря и резервные копии. Записи, сделанные после последнего якоря, администратор с доступом к журналу может переписать целиком с пересчетом контрольных сумм, поэтому окно между якорями и держим в один час. От обоих случаев защищает уже разграничение полномочий на стороне клиента, и мы это оговариваем, потому что обещать больше было бы неправдой. Служба безопасности или аудитор в любой момент открывают журнал и видят, на чем основан конкретный ответ и кто к каким данным обращался.

5 отраслевых прикладных задач. 4 для розницы и кредитный конвейер для банка

Описания товаров и ответы на отзывы

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

Умный поиск по каталогу

Покупатель на витрине интернет-магазина ищет своими словами, например «куртка на осень недорого», и смысловой (векторный) поиск находит подходящие товары, даже когда слова запроса не совпадают со словами в карточке. Сам поиск работает внутри контура и обходится без обращения к LLM. В наших требованиях приемки на стенде с каталогом в 100 тысяч товаров первичный проход поиска укладывается в 0,4 секунды у 95% запросов. Если по первому проходу ничего не нашлось, платформа делает второй, более мягкий заход, и тогда весь ответ укладывается в 0,7 секунды в 95% таких случаев. Быстрее секунды поиск отвечает в 99% запросов на том же стенде. Это серверное время, к которому на витрине добавляется дорога до покупателя. Короткую подсказку, как уточнить запрос и почему подобраны эти товары, готовит LLM отдельным запросом, и текст покупателя проходит перед отправкой за пределы контура то же маскирование.

Тексты рассылок и разбор обратной связи

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

Ассистент продавца в зале

Продавец со своего телефона спрашивает о товаре, наличии и регламентах магазина (например, как оформить возврат). Ответ появляется на экране частями, по мере генерации, как в чате. Каждую часть платформа показывает только после проверки фильтром, который держит текст до конца предложения. Поэтому то, что фильтр распознал как запрещенное, он успевает убрать раньше, чем часть попадет на экран. Остатки и розничные цены ассистент берет из учетной системы в момент вопроса, а не из вчерашней копии. Закупочных цен и наценок нет в данных, которые приходят ассистенту из учетной системы, поэтому на прямой вопрос ответить ими он не может. Если такие сведения все же окажутся в тексте служебного регламента, фильтр ответа ищет упоминания закупочных цен и наценок и убирает найденное. Фильтр лексический, перефраз или голое число без пояснения он может пропустить, поэтому при внедрении мы отдельно проверяем состав корпуса, то есть набора документов, по которым ассистент отвечает, и убираем оттуда документы с закупочными ценами. Когда платформа работает на внешней LLM, добавляется еще и правило о классах данных. Документ, который клиент пометил как коммерческую тайну, за пределы контура не уходит ни целиком, ни выдержками. Регламент, который этим классом никто не пометил, правило не остановит, поэтому проверка состава корпуса при внедрении остается обязательной.

Кредитный конвейер для банка

Заявку физлица от приема документов до проекта решения по кредиту ведет маршрут из заранее заданных шагов, а не свободно действующая программа. Внутри маршрута есть участок антифрод-проверки, где ИИ-агент сам решает, какие источники запросить, и делает это в пределах числа попыток, заданного в пакете задачи. Документы разбирает и тексты объяснений пишет LLM, а скоринг заемщика (оценку вероятности, что кредит вернут в срок) считает модель классического машинного обучения (ML). Вклад каждого фактора оценки платформа сохраняет целиком в карточке заявки, а три главных фактора (например, доход, долговая нагрузка и кредитная история) пересказывает словами в проекте решения и записывает в журнал действий. Отказать в кредите платформа сама не может. Отрицательный проект решения всегда уходит сотруднику, обходного пути через API не существует, и это проверяется на приемке отдельным сценарием. Автоматически проходит только одобрение в узком коридоре, который задан в пакете задачи (небольшая сумма, высокая оценка скоринга, отсутствие подозрений антифрода и отдельное согласие заемщика на решение без участия человека), и каждый такой случай помечается в журнале действий. Режим «каждое решение подтверждает человек» банк включает одним параметром. Требования 152-ФЗ о персональных данных, 218-ФЗ о кредитных историях и нормативов ЦБ по защите информации разложены на проверки в файлах пакета задачи, которые поставляем и обновляем мы. Когда регулятор меняет норму, мы выпускаем новую версию пакета этой задачи, и код платформы при этом остается прежним.

Развертывание одной консольной командой, обновление без простоя при нескольких копиях сервисов и работа в закрытом контуре

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

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

Рабочие данные прикладных задач (заявки, карточки товаров, тексты описаний и ответов) и поисковый индекс хранит PostgreSQL, журнал действий и трассы лежат в ClickHouse (базе для аналитики и журналов), файлы, документы и часовые якоря журнала в MinIO (объектном хранилище с запретом перезаписи), а кеш и очереди фоновых заданий в Redis. Вход сотрудников, учетные записи и роли ведет Keycloak (сервер аутентификации), а решение о том, что конкретному сотруднику можно видеть и делать, принимает механизм доступа в ядре платформы. Открытые LLM внутри контура запускает vLLM (движок, который исполняет их на видеокартах сервера). Все это широко распространенные open source компоненты, и служба безопасности может проверить исходный код любого из них. Ядро платформы и сервисы обработки запросов - это собственный код на TypeScript и Python. Его исходники клиент получает по договору поставки, сразу вместе с дистрибутивом или через депонирование у независимого хранителя. Технических замков нет ни в одном из этих вариантов поставки.

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

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

По каким инженерным правилам построена Svaya

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

С чего начать

Если вам нужна заказная разработка сложной системы (с LLM или без), напишите нам. Разберем вашу задачу и покажем на демонстрации, как работает платформа и как мы ведем разработку. На Svaya мы также внедряем готовые прикладные задачи для розницы и банков, о них рассказывает раздел «Искусственный интеллект». Что платформа дает заказчику и как проходит внедрение, разобрано на странице платформы Svaya.