Свой AI-харнесс: прод-движок для десятков моделей — единое окно, роутер и управляемые прогоны

В прошлый раз я рассказывал, как в одиночку с AI-агентами собрал ERP-платформу на Kubernetes из 30+ сервисов. Эта статья — про её мозг: не «ещё один агентский фреймворк», а продакшн-движок, который год несёт живых клиентов (рекрутинг с AI-интервью, CRM, парсинг-конвейеры, копилот).

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

Сервис работает на Node, на CPU.

Задача: моделей много, и все разные

«Модель» — это не одна сущность. У меня их три класса, и они несовместимы почти во всём:

• Локальные модели в своём кластере (GPU‑под и CPU‑Ollama) — для чувствительных данных и для того, что гоняется постоянно.

• Платные облачные API (OpenRouter, DeepSeek, Anthropic) – когда нужно много и быстро.

• Бесплатные провайдеры – чтобы гонять парсинг, классификацию и обогащение в промышленных объёмах, не платя за токены.

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

Значит, нужна одна дверь.

Из чего собран AI платформы

Весь AI – несколько слоёв:

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

• Харнесс – превращает разовый вызов в управляемый процесс: контекст, инструменты, журнал, проверка результата.

• Агентская система – поверх харнесса: агенты с задачами, бюджетами и подтверждениями от человека.

• Движок нетекстовых моделей — отдельный сервис для речи/зрения/синтеза на видеокарте (вторая статья).

Идея харнесса — свести две операции: вызов (шлюз моделей, stateless) и прогон (управляемый процесс с состоянием). AI-функция — это прогон без инструментов в один шаг; «агент» — тот же прогон, но с инструментами и субъектом. Благодаря этому «модель как функция» и «агент» — не два разных механизма, а один.

Единая дверь

Один сервис, который снаружи выглядит как «дай ответ», а внутри решает: какой модели отдать, как обойти лимиты, сколько это стоило и что можно показывать наружу. Принимает разные типы задач и маршрутизирует к исполнителю: речь и документы ходят через ту же дверь, что и текст, с тем же учётом и политиками.

Важно про железо: сам сервис-дверь — на CPU, он ничего не считает, он раздаёт. Лёгкое и текстовое уходит в локальные модели и внешние провайдеры, тяжёлое речевое/зрительное — в GPU-под.

Честная оговорка: единая дверь — контракт, а не догма. Для latency-критичного (живые субтитры, живое интервью) есть прямой путь мимо общей двери — ради задержки. Но точка входа по умолчанию, учёт и приватность — общие.

Роутер моделей

У каждой модели есть подключение — ключ, адрес, имя модели. Таких подключений уже больше сотни: локальные, платные, бесплатные вперемешку, причём один и тот же провайдер часто подключён несколькими ключами. Роутер выбирает, к какому пойти, и что делать при отказе. Подключения собраны в цепочки (я называю их combo), у каждой цепочки свой порядок и свои бюджеты — их на проде около десяти.

Свою карусель провайдеров я написал ещё в первой версии, и она работала. Потом переосмыслил её в полноценный роутер — идеи подсмотрел в OmniRoute (MIT): взял оттуда только данные (каталоги моделей и правила разбора ошибок), движок написал свой. В OmniRoute заявлено 352 провайдера — это маркетинг: большинство триалы и браузерные хаки. По-настоящему щедрые бесплатные лимиты дают единицы.

Цикл выбора

Бюджеты задаются на цепочку. В коде дефолт — до 4 попыток, общий таймаут 90 с, попытка 45 с, но реальные цепочки настроены под задачу: быстрый текстовый ответ — 6 попыток по 60 с, перевод — 4 попытки по 90 с, диалог с кандидатом — 5 попыток по 40 с, а обогащение вакансий через локальную модель — до 12 попыток по 45 с, потому что там не спешим. Общий потолок цепочки — от двух до трёх минут. Сам цикл (упрощённо, omniroute.service.ts):

for (const c of ordered) {              // ordered — кандидаты, отсортированные стратегией
  if (tried >= maxAttempts) break;
  const left = budget - (Date.now() - started);
  if (left < 2000) break;               // общий бюджет времени кончился

  if (await this.gate(c, s)) continue;  // пауза / квота / circuit breaker → следующий

  tried++;
  const res = await this.http.post(driver.url(...), driver.body(c, input, s), {
    timeout: Math.min(c.timeoutMs ?? s.attempt_timeout_ms, left),
    validateStatus: () => true,         // сами разбираем коды
  });

  if (res.status >= 200 && res.status < 300) {
    const q = driver.validate(res.data, { needsJson: !!s.force_json });
    if (q.ok) { await this.onSuccess(...); return this.toResponse(...); }   // успех
    lastVerdict = { kind: 'quality', cooldownMs: 120_000, scope: 'model', fallback: true };
  } else {
    lastVerdict = classifyError(c.providerId, res.status, res.headers, res.data, level);
  }
  await this.onFailure(c, lastVerdict, ms);
  if (!lastVerdict.fallback) break;     // ошибка, которую повтор не починит
}

Ключевой момент — validate на успешном ответе: код 200 не значит «всё хорошо» (об этом ниже).

Восемь стратегий

Порядок кандидатов задаётся стратегией — разным задачам нужны разные:

type StrategyName =
  | 'priority' | 'fill-first' | 'weighted' | 'round-robin'
  | 'least-used' | 'random' | 'p2c' | 'quota-share';

priority — по приоритету; fill-first — добить один провайдер до лимита; p2c — взять двух случайных, выбрать лучшего по успешности и скорости; quota-share — пропорционально остатку дневной квоты. Честно: в типе их восемь, а на проде у меня в ходу в основном две — priority и quota-share. Остальные лежат про запас.

Классификация ошибок — сердце устойчивости

Провайдер падает десятком способов, и на каждый нужна своя реакция. Наивный «подожди 15 секунд и повтори» выжигает лимит и долбит мёртвый ключ. Виды и лестница пауз:

type ErrorKind =
  | 'rate' | 'quota' | 'account' | 'auth'
  | 'model' | 'server' | 'quality' | 'request' | 'other';

const CLOUD_LADDER_MS = [2*MIN, 10*MIN, 30*MIN, 60*MIN, 240*MIN, 480*MIN];

function backoffMs(level, providerId) {
  if (isLocalProvider(providerId)) return Math.min(3000 * 2**Math.min(level,5), 2*MIN);
  if (level >= CLOUD_LADDER_MS.length) return msUntilUtcMidnight();   // упёрлись — ждём до полуночи
  return CLOUD_LADDER_MS[level];
}

Ключевая мысль: 429 — это не одно событие, а три. Дневной лимит держится до полуночи, месячный — до начала месяца, обычный throttle — секунды. Лечить одинаково = либо зря ждать полдня, либо долбить провайдера, который скажет «стоп» на месяц.

Пауза ставится не на «провайдера вообще», а на одну из трёх областей: подключение, конкретную модель или аккаунт (ключ вместе с адресом). Закончились деньги на ключе — встаёт аккаунт целиком, а не одна модель. Ступень отступа хранится сутки, потолок — шестая.

Лестница выше — для облака. Но выяснилось, что она слишком суровая для двух случаев, и пришлось завести короткие:

— Обрыв сети (ECONNRESET): 3 секунды, дальше удвоение до 96 секунд, и лишь на верхней ступени 15 минут. Длинная лестница на обрывах однажды запарковала здоровые подключения. — Перегрузка (429/503 с текстом вроде «overload», «concurrency», «temporarily unavailable»): тоже короткая лестница. Один бесплатный провайдер держал всего один запрос за раз, и каждый параллельный вызов получал 429, который парковал подключение на восемь часов. — Локальная модель: потолок две минуты.

И последняя поправка, из-за которой я добавил настройку backoff_cap_ms — потолок любой паузы подключения. Шлюзы, которые «мигают», отдавали единичные 503, и два совершенно здоровых подключения доезжали до пятой–шестой ступени и уходили в парковку на два и на восемь с половиной часов. Теперь у мигающих шлюзов стоит потолок в пять минут.

Что ещё настраивается на подключении

Помимо ключа и адреса, у подключения есть ручки, о которых я не знал, когда начинал:

— max_concurrency — сколько запросов одновременно. Заняли — кандидат пропускается, цепочка идёт дальше, а не ждёт. — budget_tokens и окно (день, неделя, месяц) — собственный потолок токенов. — thinking/reasoning — управление «размышлением». У одной модели размышление съедало весь max_tokens, и ответа не оставалось; лечится выключением режима. — trains_on_prompts и free — обучается ли провайдер на запросах и бесплатный ли он. Цепочки для чувствительных данных собираются только из тех, кто не обучается. — pii_forbidden — подключение, в которое чувствительные данные нельзя отправлять вообще.

Выход к провайдеру: метка в адресе

Лимит бесплатного провайдера часто считается на IP, поэтому один и тот же сервис подключён несколькими ключами с разных исходящих адресов. Выход выбирается не кодом в клиенте, а меткой прямо в адресе подключения: запрос уходит на внутренний шлюз, который сам ставит HTTPS-соединение через выбранный выход. Захотел добавить ещё один выход для ключа — поменял адрес в настройках подключения, а не код.

Проверка «200 и мусор»

Провайдер может вернуть код 200 и труху — и если это не поймать, мусор уедет в базу и к клиенту. Что считаем отказом на «успешном» ответе (quality.ts):

if (!content && !hasTools) {
  if (reasoning && (finish === 'length' || finish === 'max_tokens'))
    return { ok: false, reason: 'только рассуждение, ответ обрезан по max_tokens' };
  return { ok: false, reason: 'пустой content' };
}
if (isDegenerate(content))             return { ok:false, reason:'вырожденный текст' };
if (content.length < 200 && MASKED_ERROR_RE.test(content))
                                       return { ok:false, reason:'заглушка провайдера под видом 200' };
if (needsJson && !isValidJson(content)) return { ok:false, reason:'битый JSON' };

Пустой ответ, «только reasoning» (весь бюджет ушёл в размышления), кракозябры/зацикленный повтор, текст вида «rate limit exceeded» прямо в теле, сломанный JSON там, где просили строгий формат, — всё это трактуется как quality-отказ наравне с HTTP-ошибкой. У такой проверки есть и обратная сторона: детектор «кракозябр» однажды стал давать ложные отказы на нормальных текстах с диакритикой — венгерском, чешском, немецком, французском. Его пришлось поправить, иначе вакансии на этих языках не переводились.

Circuit breaker и состояние в Redis

Паузы, backoff, breaker, счётчики квот нельзя держать в памяти пода: реплик несколько, поды перезапускаются, и после рестарта роутер снова полезет в мёртвый провайдер. Состояние общее, в Redis (префикс omniroute:):

const BREAKER = { threshold: 12, resetMs: 30_000, maxMultiplier: 4, escalateAfter: 2 };
// ключи: cd:{conn|model|account}:{id} — паузы; bo:{connId} — backoff;
//        cb:{provider} — breaker; q:{key} — квоты; rr:{scope} — round-robin

Breaker открывается после 12 отказов подряд, через 30 с пробует один запрос в half-open, снова упал — пауза растёт. Если Redis недоступен — падаем на in-memory, чтобы не встать совсем.

Сколько дают бесплатно

Бесплатные условия меняются постоянно, поэтому цифры ниже — по документации провайдеров на 15 сентября 2026 и перед использованием их надо перепроверять:

С оговорками. Часть провайдеров дают совсем мало: 200 запросов в час на все модели сразу у одного, 200 в сутки на организацию у другого, 15 в неделю у третьего. Есть публичные серверы, через которые я вообще не пропускаю ничего чувствительного: около 250 запросов в сутки на ключ, чужие машины, для персональных данных исключены. И есть провайдеры, у которых лимит считается на IP, а не на ключ: два миллиона токенов в сутки на каждый исходящий адрес. Отсюда и подключение одного сервиса с нескольких выходов.

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

Как описан провайдер

Подключения живут в таблице llm_providers, поведение — в jsonb settings:

@Entity({ name: 'llm_providers' })
export class LlmProviderEntity {
  type: LlmProviderType;        // omniroute | free-rotation | openai | ollama | anthropic | ...
  @Column({ transformer: secretColumnTransformer })
  api_key: string | null;       // шифруется at-rest (AES-256-GCM, префикс enc:v1)
  @Column({ type: 'jsonb' })
  settings: Record<string, unknown> | null;  // combo, strategy, free_only, models_allow/deny,
                                              // pool (слоты карусели), default_model, таймауты
}

Промпт и маршрут модели — тоже в settings/связанных полях, поэтому правятся в БД без выката кода. Это важно дальше: в харнессе промпты определений живут данными.

Учёт: по попытке, а не по запросу

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

@Entity({ name: 'ai_usage' })
@Index('idx_ai_usage_feature_ts', ['feature', 'ts'])
export class AiUsageEntity {
  request_id: string;        // общий у всех попыток одного запроса
  attempt: number;
  feature: string;           // бизнес-фича: скрининг, перевод, обогащение…
  task_type: string;         // text.chat | embedding | asr.transcribe | ocr …
  provider_id: string; model: string;
  status: string;            // ok | error | skipped
  tokens_in: number; tokens_out: number;
  tokens_cached_in: number;  // часть входа из кэша промпта — в разы дешевле
  latency_ms: number;
  cost_usd: string;          // numeric(12,6)
}

Решения, за которые не стыдно:

— Каждый вызов помечен бизнес-фичей, не внутренним именем подключения. Поэтому в отчёте видно «сколько съел скрининг», а не «сколько съело подключение №7». — Запись идёт пачкой и никогда не роняет работу:

const FLUSH_MS = 2000, FLUSH_SIZE = 100, MAX_BUFFER = 5000;
record(entry) {
  if (!this.enabled) return;
  try {
    if (this.buffer.length >= MAX_BUFFER) { this.dropped++; return; }
    this.buffer.push(entry);
    if (this.buffer.length >= FLUSH_SIZE) void this.flush();
    else if (!this.timer) this.timer = setTimeout(() => void this.flush(), FLUSH_MS);
  } catch (e) { this.logger.warn(`[AiLedger] запись не удалась: ${e.message}`); }  // не бросает
}

К началу октября в журнале набралось порядка 700 тысяч попыток, это около 450 мегабайт. Учёт не добавляет задержки к инференсу; если сам учёт упал — запрос всё равно проходит. Поверх сырья — агрегаты, лимиты, бюджеты (включаются постепенно: сначала смотришь цифры, потом режешь). Метрики — в формате OpenMetrics своим маленьким сборщиком, без внешних зависимостей.

PII-guard: приватность встроена в дверь

Про обезличивание перед LLM на Habr писали как про отдельный продукт-прокси. У меня это не продукт, а слой прямо в пути запроса — маскировка применяется автоматически, когда провайдер внешний:

const external = isExternalProvider(provider);   // Ollama / внутренний хост / allow_pii — НЕ внешний
const pii = external ? PiiRedactor.from(request.message_data, request.pii_hints) : null;
if (pii?.active) {
  messages = pii.redactMessages(messages);       // ФИО → «Персона», компании → «Компания»,
                                                  // дата рождения → «[скрыто]»
}
// …вызов модели…
response.content = pii.restore(response.content); // метки разворачиваются обратно в ответе

Смысл: чувствительные данные не покидают периметр не «по памяти разработчика», а по правилу на каждом запросе. Для локальных моделей маскировки нет — данные и так в кластере.

Правило, которое я сформулировал для себя жёстко: во внешние модели, в журналы и в логи уходит только имя. Фамилия, дата рождения и компании из опыта — нет. Поэтому:

— те же функции чистят и журнал прогонов: всё, что пишется в ai_runs и ai_run_events, маскируется всегда, а если сама маскировка упала, в журнал уходит заглушка, а не сырой текст; — у подключения есть флаг pii_forbidden: цепочки для данных кандидатов собираются только из разрешённых подключений, а самая строгая — только из локальной GPU; — неофициальные шлюзы и публичные серверы помечены запрещёнными для чувствительного по определению.

Есть и честные дыры. ФИО, которого нет ни в данных запроса, ни в подсказках, маскировщик не найдёт. И старые записи журнала, созданные до правила, не вычищены.

Харнесс: от разового вызова к управляемому процессу

Всё выше — про вызов: дал запрос, получил ответ. Но половина задач — это не «ответь», а «сделай»: собери контекст, вызови инструменты, проверь результат, запиши, что происходило, и, если надо, спроси человека. Это прогон.

Определение отделено от субъекта

Поведение описывается определением (ai_definitions) — это версионируемая сущность, правка = новая версия. Версия поднимается только при реальном изменении содержимого: сравнивается канонический JSON. Раньше сидер заводил новую версию на каждом старте пода, и накопилось 64 версии без единой правки:

@Entity({ name: 'ai_definitions' })
export class AiDefinitionEntity {
  key: string;             // copilot.default, ats.screening_score
  version: number;         // правка → новая версия, старые прогоны ссылаются на свою
  system_prompt: string | null;
  model_policy: ModelPolicy | null;
  tools: string[] | null;          // имена инструментов из реестра
  context_layers: string[] | null; // какие слои контекста подмешивать
  result_schema: object | null;    // ожидаемая форма результата
  evaluator: EvaluatorSpec | null; // чем проверять
}

А кто это исполняет (личность, принципал, ключи, бюджет) — отдельно, в субъекте (llm2_agents). Одно и то же определение может крутить и копилот от имени пользователя, и автономный агент.

Прогон и журнал только-на-дозапись

Каждый запуск — строка ai_runs (снимок версии определения, принципал, статус, стоимость, связь с Temporal через workflow_id). А всё, что происходило внутри, пишется в append-only журнал ai_run_events:

enum AiRunEventType {
  RUN_STARTED, CONTEXT_BUILT, MODEL_REQUEST, MODEL_RESPONSE,
  TOOL_CALLED, TOOL_RESULT, APPROVAL_REQUESTED, APPROVAL_RESOLVED,
  RESULT_REPAIRED, EVAL_VERDICT, HANDOFF_WRITTEN, RUN_FINISHED, RUN_FAILED,
}

Инвариант: всё, что видела модель, восстанавливается из журнала; таблица только дописывается. Это то, что превращает «магию в чёрном ящике» в отлаживаемый процесс — по прогону видно каждый запрос к модели, каждый вызов инструмента и каждый вердикт. Масштаб на начало октября: 53 определения, 24 инструмента в реестре, около 290 тысяч прогонов и около миллиона событий журнала.

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

Два режима — один код шага

enum AiRunMode {
  INTERACTIVE = 'interactive',  // петля внутри llm2, ответ нужен сейчас, Temporal не нужен
  DURABLE     = 'durable',      // внешнюю петлю крутит Temporal в оркестраторе
}

Код одного шага step() общий. Различие — кто крутит внешнюю петлю. В долгом режиме состояние прогона лежит в Postgres, поды его не держат, поэтому рестарт пода прогон не теряет. Короткий интерактив (копилот, живой диалог) — внутри llm2 с ответом потоком; долгие пайплайны — активности Temporal.

Цикл инструментов

Инструменты берутся из реестра ai_tools по «поверхности» (copilot, скрининг и т.д.) и отдаются модели спеками:

const toolSpecs = descriptors.map(d => ({
  type: 'function',
  function: { name: d.name, description: d.description, parameters: d.inputSchema },
}));

Модель просит вызвать инструмент — исполняем через тот же executor, что и у копилота, с проверкой прав, и возвращаем результат обратно в диалог:

const outcome = await this.executeCall(call, user, toolTimeoutMs, autonomy);
messages.push({ role: 'tool', tool_call_id: call.id, name: call.name, content: capped.text });

Потолок — 5 шагов на прогон по умолчанию, жёсткий — 10, чтобы цикл не ушёл в бесконечность.

Эвалуатор — fail-open

Результат прогона может проверять отдельная, более дешёвая модель-судья по заданным критериям. Принцип — fail-open: недоступный судья не обесценивает работу исполнителя.

} catch (e) {
  this.logger.warn('[Evaluator] оценка не получена — принимаем результат');
  return null;    // null → вызывающий принимает результат
}

Вердикт {accept, score, notes} пишется событием EVAL_VERDICT в журнал.

Агентская система

Агент — субъект платформы, а не «скрипт с доступом ко всему». В llm2_agents: месячный бюджет (budget_monthly_cents / spent_monthly_cents), права (permissions jsonb), capabilities, ключ агента хэшем SHA-256. Расход считается по фактам — ai_usage ⋈ ai_runs, блокировка под флагом. Для внешних агентов есть pull-API (GET /internal/agents/:id/wakeups, POST .../run, POST .../heartbeat) и зеркальный gRPC; молчание кандидата или отложенная работа — это wakeup с scheduled_at и арендой (lease_until).

Человек в петле — через автономию инструмента: часть действий auto, часть требует подтверждения, и тогда прогон встаёт в pending_approval и пишет approval.requested в журнал.

Что выкачено, но за флагом

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

• Единый реестр инструментов. Инструменты лежат в одной таблице ai_tools, и под двумя флагами один и тот же вызов исполняется из реестра — копилотом внутри платформы и, в том числе, внешними агентами через MCP. Права, предусловия и модуль записаны в самом инструменте, а проверка одна для всех.

• Периодика через Temporal. Четыре фоновые задачи (правила входящих, личный помощник, обслуживание пробуждений, сканер графа контекста) раньше тикали внутри пода таймерами. Теперь тик шлёт оркестратор, а сервис при включённом флаге молчит. Флаг ставится в обоих сервисах сразу, а выкат — сначала оркестратор: иначе в окне между выкатами задача либо не запустится, либо запустится дважды.

• Диалог с кандидатом через харнесс. Бота, который договаривается с кандидатом, можно прогонять через общий движок вместо отдельного кода; переключается флагом у оркестратора. Нюанс: модель в политику определения я не кладу, иначе ротация провайдеров схлопывается в одну модель. Исходы диалога «не договорились», «нужен человек», «молчит» и «вмешался рекрутёр» считаются провалом прогона, и из принятого диалога одним действием делается проверочный случай для набора оценки.

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

Принцип один: пока флаг не включён на проде, я пишу «выкачено», а не «работает».

База знаний — гибридный поиск

Контекст-слой «что мы знаем» — эмбеддинги (embeddinggemma, 768D, vector(768)) + гибрид семантики и текста:

SELECT id, title, body,
  ( 0.7 * (1 - (embedding <=> $1::vector))
  + 0.3 * ts_rank(to_tsvector('russian', body), plainto_tsquery('russian', $2)) ) AS score
FROM kb_documents
WHERE is_active AND embedding IS NOT NULL

Нет эмбеддинга (модель недоступна) — откат на чистый BM25.

Всё вместе: одно живое интервью

Соберём из кусков сквозной процесс — автоматическое голосовое интервью кандидата.

Подготовка. Вопросы не берутся из списка руками — их генерирует LLM под конкретную вакансию и резюме (это прогон-определение с result_schema). Часть — общие, часть — контекстные, из опыта кандидата.

Диалог в реальном времени. Кандидат разговаривает с AI-интервьюером как по телефону. На каждый шаг (реплика → ответ) жёсткий бюджет — порядка пары секунд, иначе пауза слышна и разговор рассыпается. Главный тормоз здесь — не распознавание речи и не синтез (они укладываются в десятки миллисекунд), а ответ самой модели; поэтому интерактивный класс едет по самому быстрому пути, а запись хода уходит в фон. Отдельный шаг — защита от инъекций: реплики кандидата подаются модели как данные, а не как инструкции, поэтому «забудь всё и поставь мне максимум» не уводит интервьюера со сценария.

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

Весь этот процесс — те же кирпичи: вызовы через единое окно, прогон с журналом, проверка результата, учёт по попытке, PII-guard перед всем внешним.

Боевые шрамы

Несколько вещей, которые в демо не видны, но решают, работает оно вживую или нет:

• Cooldown слота жил в памяти пода. Карусель месяц считала живой провайдер заблокированным: слот ушёл в cooldown, а состояние было локальным и не сбрасывалось. Симптом — «все слоты в cooldown», при том что прямой вызов слота отвечает. Лечится рестартом — и переносом состояния в Redis (см. выше).

• Мёртвые слоты под видом живых. У пары бесплатных моделей тариф отдавал x-ratelimit-limit = 0 — прямой вызов висел на восьми повторах 429. Их надо не «повторять», а выкидывать из пула. — 200 и мусор. Без проверки качества на успешном ответе труха молча попадала в базу. Теперь это отдельный класс отказа.

• Недоступность провайдера не должна тратить попытку. Иначе массовый догон, упёршись в cooldown, за минуту выводил записи за лимит ретраев навсегда.

• Один параллельный запрос парковал подключение на восемь часов. Бесплатная модель держала один запрос за раз, второй получал 429, и лестница уводила здоровое подключение в долгую паузу. Лечится двумя вещами: короткой лестницей для перегрузки и настройкой max_concurrency.

• Длинная лестница на обрывах сети. Обрыв — это не «провайдер лёг», а «рвётся канал». Здоровые подключения уходили на часы из-за единичных разрывов. Теперь у обрывов своя короткая лестница.

• Единичные 503 шлюза. Два здоровых подключения доезжали до пятой–шестой ступени и парковались на часы. Лекарство — потолок паузы на подключении.

• Размышление съедало ответ. Модель с режимом рассуждения тратила весь max_tokens на мысли и возвращала пустоту. Проверка «200 и мусор» это ловит, а лечится выключением режима.

• Устаревший адрес локальной модели. Обрывы до локальной GPU оказались мёртвым адресом в слайсе сетевого посредника, а не сетью. Лечится перезапуском оператора, и я теперь знаю, куда смотреть первым.

• Тесты зелёные, живой прогон красный. За один день живой стенд нашёл то, что юнит-тесты не видели: журнал под отдельным флагом, рост версий определений, размерность вектора, флаги, которые не доходили до пода. Теперь любое изменение пути трафика сначала прогоняется на живом стенде.

Мораль одна: продакшн-движок для моделей — это на 80% обработка того, как они ломаются, и на 20% собственно вызов.

Итого

• Единая дверь на CPU для текста, эмбеддингов, речи, документов и синтеза — раздаёт локальным моделям, внешним провайдерам и GPU-поду.

• Роутер на цепочках: больше сотни подключений, у каждой цепочки свои бюджеты, он различает три вида 429, короткие и длинные лестницы пауз, проверяет сам ответ на мусор, держит паузы и circuit breaker в общем состоянии и переживает рестарты. Выход к провайдеру выбирается меткой в адресе.

• Учёт по попытке — видно цену ретраев и мёртвых слотов, в разрезе бизнес-фич. — Харнесс: версионируемые определения, прогоны с append-only журналом, цикл инструментов, эвалуатор fail-open, два режима (интерактив / Temporal) на одном коде шага.

• Агенты как субъекты с бюджетом, правами и человеком в петле. — Приватность — слоем в пути запроса, а не сбоку: наружу только имя, журнал маскируется всегда, а подключения помечаются запрещёнными для чувствительного.

• И дисциплина: всё, что меняет живой трафик, едет под флагом, выключенным по умолчанию.

Во второй статье — нетекстовые модели: как тот же подход работает для распознавания речи, синтеза и зрения на одной видеокарте, и почему «ASR-сервис» давно перестал быть про один ASR.

Если зайдёт — расскажу про любой блок подробнее: роутер, журнал прогонов, агентскую систему или сквозной процесс живого интервью.