Платформа

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

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

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

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

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

Мы встраиваем фильтрацию в каждый запрос к модели — на входе и выходе: маскирование данных по ФЗ-152, обнаружение атак, правила под конкретный бизнес. В банке выстроили многослойный комплаенс: запреты в промпте, сценарии отказа, петля перепроверки и аудит каждого ответа.

В проекте для инвестиционного подразделения банка — многослойный комплаенс: запреты в prompt, refusal-сценарии, checker-петля и аудит ответа. Кейс →

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

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

В проекте для транспортной системы — трёхпроходная формула уверенности с 30+ параметрами, калиброванными на боевых обращениях. Кейс →

У каждой компании свои регламенты, база знаний, нормативная документация. Стандартный RAG находит похожий фрагмент по вектору — но enterprise-задача сложнее. На телеком-проекте тарифный вопрос требовал точную цифру из таблицы, а векторный поиск возвращал «примерно похожий абзац».

Мы построили двойной индекс: один для поиска по смыслу, другой для точных данных — таблицы тарифов, цены, технические параметры. Обычный векторный поиск числа и таблицы теряет, потому что они плохо поддаются векторизации.

В проекте для телеком-оператора — двойной индекс: один для поиска по смыслу, другой для точных данных с таблицами и ценами. Кейс →

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

Мы собрали инфраструктуру оркестрации, чата и памяти, чтобы не писать её с нуля на каждом проекте. Отдельный компонент — Content Digital Twin — отвечает за корпоративный тон: 60+ итераций, прежде чем агент стал звучать как сотрудник компании, а не как чат-бот.