Обсудить проект

Кейс · под NDA

ИИ-платформа как инфраструктура продукта

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

  • Go · Next.js
  • PostgreSQL · pgvector · Redis
  • multi-LLM · eval · billing
  • под NDA

02Задача

Вызов модели — самая лёгкая часть

Проект объединяет несколько консьюмерских AI-сервисов. Из-за NDA мы не называем продукты и не раскрываем предметную область, но инженерные задачи у таких систем похожи, и именно о них эта страница.

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

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

03Архитектура

Платформа вокруг LLM

Обобщённая схема. Реальная топология сложнее, но роли узлов сохранены.

Схема: Клиент, API на Go, Биллинг, Память, LLM-шлюз, Воркфлоу, Провайдеры, ОценкаКлиентweb · WebSocket/SSEAPI на Goсессии · праваБиллингRedis holdsПамятьpgvector · RedisLLM-шлюзrouting · breakerВоркфлоуcanvas · workersПровайдерыfallback chainОценкаLLM judge
fig. Шлюз выбирает провайдера и модель, биллинг резервирует баланс до вызова, а память и оценка качества работают как отдельные контуры.

04Маршрутизация

Шлюз: маршрутизация и отказоустойчивость

Шлюз — единая точка входа ко всем провайдерам моделей. Код продукта не знает, чья модель ответила.

  • Circuit breaker на провайдера

    Если провайдер начинает ошибаться или тормозить, трафик перестаёт идти к нему, и таймауты не копятся в очереди запросов.

  • Цепочка fallback

    При недоступности провайдера запрос уходит к другой модели сопоставимого класса. Пользователь видит небольшую задержку, а не ошибку.

  • Маршрутизация по уровню и намерению

    Простые запросы идут к дешёвым моделям, сложные к более сильным. Решение принимается по типу задачи и по стоимости.

  • Мягкая деградация

    Если нужная модель недоступна, система предлагает доступную замену, а не падает целиком.

  • Потоковая выдача

    Ответ передаётся клиенту по мере генерации через WebSocket или SSE, поэтому пользователь не ждёт полного текста.

05Память

Память и контекст

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

  • Семантический кэш

    Для близких по смыслу запросов повторно используется найденный ответ из PostgreSQL и pgvector, вместо нового обращения к провайдеру.

  • Трёхслойная память

    Краткосрочный контекст диалога лежит в Redis, структурированные факты в PostgreSQL, а семантический поиск по эмбеддингам идёт в pgvector.

  • Суммаризация сессий

    Длинная история сжимается в краткую сводку, а важное сохраняется в долговременную память.

  • Промпт под бюджет токенов

    Контекст собирается из слоёв по приоритету так, чтобы уложиться в бюджет, а не обрезается произвольно.

  • Поиск вместо дообучения

    Новые знания попадают в ответ через извлечение релевантных фрагментов, и модель при этом остаётся неизменной.

06Оценка

Качество измеряется, а не угадывается

Смена модели или правка промпта без проверки — эксперимент на пользователях. Поэтому оценка встроена в сервер.

  • LLM-as-judge

    Модель-судья оценивает ответы по заданным критериям. Это быстрая проверка, которую лучше дополнять ручной.

  • Сравнение моделей и промптов

    Одни и те же сценарии прогоняются через разные модели и версии промптов, а результаты сравниваются.

  • Регрессионные проверки

    Перед сменой модели набор сценариев показывает, что стало хуже.

  • A/B-эксперименты

    Варианты сравниваются на реальных сценариях использования, а не на синтетических примерах.

07Воркфлоу

Визуальный редактор цепочек

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

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

08Биллинг

Деньги должны сходиться

Предоплаченный баланс требует особой аккуратности: вызов модели стоит денег до того, как станет известен результат.

  • Холды в Redis

    Перед вызовом сумма резервируется, после успешного ответа списывается по факту, а при сбое резерв снимается. Параллельные запросы не уводят баланс в минус.

  • Обрыв посреди потока

    Если провайдер оборвал ответ, состояние баланса остаётся корректным: фактическая стоимость учитывается, лишний резерв возвращается.

  • Воркер сверки платежей

    По расписанию сравнивает платежи у провайдера с внутренними записями и поднимает расхождения.

  • Проверка подписи вебхуков

    Уведомления платёжного провайдера принимаются только после проверки подписи.

09Защита

Проверки до и после генерации

Запрос и ответ проходят через конвейер проверок: попытки обойти ограничения (jailbreak) и отклонение от заданной роли ловятся до вызова модели и после него. Это защита продукта от злоупотреблений и от ответов, которые выбиваются из образа сервиса.

10Наблюдаемость

Видно, что происходит

  • Prometheus и Grafana

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

  • Структурные логи

    Записи в разборном формате, по которым можно проследить конкретный запрос.

  • Версионные миграции

    Схема PostgreSQL меняется через версионированные миграции, поэтому состояние базы воспроизводимо.

  • Поставка в Docker

    Сервисы запускаются одинаково локально и в окружениях.

11Итог

Что получилось

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

Отдельный провайдер можно заменить, не переписывая продукт. Расход считается явно, а смену модели можно проверить заранее. Это и отличает AI-продукт от обёртки над одним API.

12Стек

Технологии

Сервер

  • Go
  • WebSocket
  • SSE

Интерфейс

  • Next.js
  • React

Данные

  • PostgreSQL
  • pgvector
  • Redis

Эксплуатация

  • Prometheus
  • Grafana
  • Docker

Строите AI-продукт?

Расскажите, что он должен делать и где сейчас узкое место. Разберём архитектуру и скажем, что реалистично.

Обсудить AI-продукт

14Контакт

Расскажите, что
должно работать.

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

brief.form4 поля · 2 минуты

Бюджет необязательно