Как выпускать AI-функции в production: eval, privacy и failure modes

Начните с задачи, а не с модели

Production AI-функция начинается с пользовательского решения, а не со сравнения providers. «Добавить LLM» — implementation preference. «Помочь revenue-оператору понять, какой prospect заслуживает внимания, и показать проверяемые evidence» — product job. Вторую формулировку можно оценивать даже после замены модели.

Опишите задачу наблюдаемым языком:

• кто принимает решение;
• какие inputs пользователь передаёт или разрешает;
• какой output меняет следующее действие;
• насколько быстро нужен результат;
• что содержит приемлемый ответ;
• какие ошибки harmless, costly или unacceptable;
• является действие advisory, reversible или automatic.

Такой framing не позволяет model capability незаметно расширить product scope. Модель может draft, classify, search, вызывать tools и действовать во внешних системах. Продукт должен открыть только capabilities, необходимые для задачи. Каждое дополнительное permission создаёт работу по evaluation, security, privacy, support и incident response.

Публичное позиционирование Eryx показывает узкую задачу: объединить prospect search, enrichment, scoring и qualification в поддерживаемый workflow для revenue teams. VStok измеряет, как AI-системы представляют и цитируют бренды, связывает evidence с приоритетными улучшениями и сопоставимыми re-audits. Это описания ответственности продукта, а не claims о безошибочности модели.

На этом же этапе полезно записать non-goals. Если функция помогает подготовить recommendation, она не обязана самостоятельно публиковать изменение. Если она классифицирует входящий запрос, ей не нужен доступ ко всей customer history. Если она суммирует evidence, она не должна создавать отсутствующие факты. Non-goals уменьшают число tool calls, объём sensitive context, количество failure states и стоимость evaluation. Они также делают разговор с пользователем честнее: человек понимает, где продукт помогает, где требуется подтверждение и какое действие остаётся под его контролем. Расширять границу следует только после evidence, что новая capability нужна для core outcome, а команда умеет измерить её качество и безопасно восстановиться после ошибки.

Production-контракт

До разрастания prompt work составьте короткий production-контракт между функцией, пользователем и operating team. Это не юридическое соглашение, а общая формулировка того, что система имеет право делать и как ведёт себя за пределами happy path.

Контракт должен отличать assistive output от automated action. Assistive-система предлагает, объясняет и оставляет решение человеку. Automated-система меняет state: отправляет сообщение, редактирует record, публикует content, одобряет заявку или двигает деньги. Automation требует более высокого evidence threshold, узких permissions, idempotency и надёжной остановки или компенсации действия.

Определяйте acceptance и refusal вместе. Функция, обязанная отвечать на каждый запрос, будет придумывать уверенность на границе данных. Разрешите ей отказать, вернуть partial result, запросить информацию или передать задачу deterministic flow.

Система оценки

Evaluation — quality specification продукта, превращённая в исполняемый процесс. Без неё prompt changes, model upgrades, retrieval changes и новые tools оцениваются по запоминающимся примерам. Команда оптимизирует последний demo, а не distribution пользователей.

Начните с versioned dataset из предполагаемого workflow:

1. Normal cases: репрезентативные inputs, которые должны успешно обрабатываться.
2. Ambiguous cases: неполные, конфликтующие и недоопределённые запросы.
3. Edge cases: необычные formats, languages, long inputs, empty results и stale sources.
4. Adversarial cases: prompt injection, malicious documents, попытки раскрыть sensitive context и запросы вне authority.
5. High-impact failures: примеры, где уверенная ошибка причиняет существенный вред.
6. Known regressions: каждый важный production incident, который не должен вернуться незаметно.

Не начинайте с произвольной цели вроде «1 000 eval cases». Coverage важнее volume. Двадцать тщательно выбранных примеров по реальным failure classes полезнее тысяч synthetic variations одинаковой структуры. Расширяйте набор по мере появления новых user behaviors и incidents.

Оценивайте компоненты и весь workflow

AI-функция может включать interpretation, retrieval, ranking, prompt assembly, generation, tool selection, output validation и UI. Хороший final answer способен скрыть слабый retrieval; отличный retrieved source может быть испорчен generation.

Используйте три уровня:

• Component evaluation: нашёл ли retrieval авторитетный source, правильно ли classifier выбрал category, отклонил ли validator malformed output.
• End-to-end evaluation: получил ли пользователь нужный outcome с правильными evidence и приемлемой latency.
• Operational evaluation: соблюдены ли permissions, retention, cost, logging, fallback и rollback rules.

Automated scoring подходит для стабильных properties: JSON validity, citation presence, classification labels, forbidden phrases, latency, token usage и tool permissions. Human review нужен для nuanced correctness, usefulness, tone, risk и проверки, действительно ли evidence подтверждает conclusion. Model-based graders помогают scale, но их требуется калибровать на human judgments и версионировать вместе с prompts.

Используйте scorecard, а не одно среднее

Один quality score скрывает trade-offs. Более быстрая модель может уменьшить cost и снизить citation precision. Новый retrieval source способен улучшить recall и одновременно повысить prompt-injection exposure. Release decision должен видеть измерения отдельно.

Качество данных и retrieval

Многие кажущиеся model failures на самом деле являются data failures. Система достала устаревшую страницу, объединила две сущности, не нашла обязательный документ или выдала marketing text за independent proof. Prompt не исправит evidence, не попавшее в context.

Определите source policy:

• какие repositories, APIs, documents, websites и user fields разрешены;
• какой source authoritative при конфликте;
• freshness requirements и update signals;
• ownership classification — first party, competitor, independent, user-provided;
• access-control checks до retrieval;
• данные для redaction или полного исключения;
• связь citations с точным местом в source.

Retrieval должен сохранять provenance: source identifier, retrieval timestamp, relevant excerpt или span, ownership class и transformations до передачи модели. Когда пользователь оспаривает ответ, команда обязана выяснить, где возникла ошибка: source, retrieval, generation или display.

Ссылка не становится proof только потому, что её retrieved модель. Проверяйте, поддерживает ли cited passage утверждение. Citation quality требует минимум трёх проверок: source релевантен и authoritative для факта, содержимое entails statement, а owned source не изображается независимым.

Freshness зависит от domain. Company registration меняется редко; pricing, store availability, software docs и model behaviour — быстро. Назначайте review или expiry rules по impact решения, а не один глобальный cache duration.

Privacy, security и границы tools

AI-функции расширяют trust boundary приложения. User text, retrieved documents, web pages, model output и tool results могут содержать untrusted instructions или sensitive data. Модель не должна становиться trusted orchestrator, обходящим controls, которые обычное приложение никогда не делегировало бы сгенерированному тексту.

OWASP Top 10 for LLM and generative AI applications описывает prompt injection, sensitive information disclosure, supply-chain weaknesses, data and model poisoning, improper output handling и excessive agency. Это application risks; их нельзя полностью закрыть «более сильным system prompt».

Стройте обычную security architecture вокруг модели:

• authentication и authorization выполняются вне prompt;
• tools получают minimum functionality и permissions;
• structured output валидируется до interpreter, database, browser или API;
• read и write capabilities разделены;
• consequential writes требуют explicit confirmation;
• write operations по возможности idempotent;
• secrets изолированы, модель не отвечает за их redaction;
• действуют rate, cost и concurrency limits;
• tool calls и permission decisions попадают в audit trail;
• рискованные capabilities отключаются независимо от остального продукта.

OWASP Application Security Verification Standard остаётся применимым: AI-component не заменяет web application security. Session management, access control, input handling, logging, secrets и data protection требуют обычной verification.

Минимизируйте данные до выбора модели

Составьте data-flow map: collection, transport, provider processing, storage, logs, evaluation datasets, support access и deletion. Для каждого поля спросите:

• Нужно ли оно для user outcome?
• Можно ли transform или minimize его до выхода из trusted system?
• Имеет ли пользователь authority передавать его?
• Хранит ли его приложение или provider?
• Может ли оно попасть в analytics, traces или human review queues?
• Как deletion распространяется по системе?
• Есть ли regional или contractual restrictions?

Не обещайте «private AI» без определения. Это может означать no training on customer data, retention setting, regional processing, isolated infrastructure, client-side processing или contractual controls. Публично указывайте реальный mechanism и limitations.

Спроектируйте опыт отказа

AI-системы отказывают иначе, чем deterministic interfaces. Они могут вернуть fluent, но unsupported answer, частично завершить задачу, выбрать неправильный tool, завершиться timeout после дорогой работы или дать разные результаты для похожих inputs. Интерфейс должен помогать распознать и исправить состояние.

Спроектируйте минимум:

• No evidence: сообщить, что required source не найден, не заполнять пробел plausible claim.
• Conflicting evidence: показать конфликт и даты sources вместо молчаливого выбора.
• Low confidence: объяснить uncertainty и способ проверки.
• Partial completion: сохранить готовую работу и пометить пропуски.
• Policy refusal: объяснить boundary без утечки internal instructions.
• Provider failure или timeout: дать safe retry и не дублировать actions.
• Invalid output: включить deterministic state, а не показывать broken generated content.
• Write failure: явно показать, произошло ли действие, и предоставить idempotent recovery.

Uncertainty должна быть actionable. Цветной badge без объяснения не помогает. Покажите причину: missing sources, entity ambiguity, stale evidence или conflict — и дайте пользователю устранить её.

User correction — product data, но её нужно обрабатывать ответственно. Отделите correction текущего результата от consent на сохранение для evaluation или product improvement. Записывайте, что изменено, каким evidence это обосновано и создаёт ли случай новый eval.

Observability, объясняющая качество

Traditional uptime необходим, но недостаточен. AI endpoint может возвращать HTTP 200 и бесполезные ответы. Observability должна связывать system behaviour с product quality, не собирая больше sensitive content, чем команда умеет контролировать.

Для каждого run полезны:

• feature и workflow version;
• model и provider configuration;
• prompt-template и retrieval-policy version;
• source identifiers, freshness и ownership classes;
• latency по components;
• input/output size и cost;
• validation и safety outcomes;
• tool calls, permissions и side effects;
• fallback, retry, correction и abandonment events;
• ссылки на eval cases или incident classifications.

Не логируйте raw prompts и outputs по умолчанию. Используйте redaction, structured metadata, sampling, короткий retention и access controls. Если raw content нужен для debugging или evaluation, документируйте purpose и permission.

Dashboards должны отвечать на решения: ухудшается ли grounded task success, улучшила ли новая модель normal cases ценой regression другого языка, растёт ли missing-source rate из-за остановившегося source, повышается ли cost per completed task из-за повторных попыток.

Alert должен иметь owner и действие. Полезны validation failure spike, tool-call denial spike, missing-source rate, latency/cost threshold, provider errors, output distribution change и high-impact eval regression.

Контроль человека и обратимость

Human in the loop — не универсальная safety-мера. Reviewer, ежедневно получающий сотни убедительных suggestions, начинает подтверждать автоматически. Human control работает, когда у человека есть context, time, authority и evidence.

Выбирайте control по impact:

Reversibility должна быть конкретной. Kill switch отключает рискованную feature без deploy и падения других функций. Fallback сохраняет user data и core journey. Rollback определяет, нужны ли compensation или cleanup для generated writes.

AI Risk Management Framework NIST организует непрерывную risk work вокруг govern, map, measure и manage. Generative AI Profile расширяет actions для специфичных generative risks. Малому продукту не нужна enterprise-церемония, но нужны owners, documented risk tolerance, testing, incident handling и evidence работы controls.

Release gates

Не выпускайте функцию потому, что demo убедителен. Выпускайте, когда определённая job проходит явные gates.

Расширяйте rollout постепенно, если exposure сегментируется. Начните с internal users или design partners, затем открывайте account, region, workflow или feature flag. Сравнивайте canary quality и operational signals с control. Production users не должны становиться первым eval set.

Model и provider updates являются релизами даже без code change. Pin versions, где это возможно, перезапускайте evals, проверяйте safety/cost и сохраняйте rollback.

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

Практическая последовательность

1. Frame

Определите job, user, risk tier, decision owner, sources, forbidden behaviour, latency и success measure. Удалите capabilities вне задачи.

2. Соберите полный thin slice

Один end-to-end path: authorized input, retrieval, model call, validation, visible evidence, correction и deterministic fallback. Не оптимизируйте prompt отдельно от workflow.

3. Зафиксируйте evals и threat cases

Версионируйте representative и adversarial examples. Добавьте component, end-to-end и operational checks. Калибруйте automated graders через human review.

4. Harden data и tools

Обеспечьте source policy, provenance, authorization, output schemas, permission boundaries, idempotency, rate limits и audit events.

5. Закройте failure UX и operations

Реализуйте uncertainty, no evidence, conflict, partial completion, timeout, provider failure и write recovery. Добавьте dashboards, alerts, runbook, kill switch и rollback.

6. Canary и обучение

Выпустите функцию контролируемой группе. Изучите task success, corrections, missing evidence, safety events, latency, cost и support load. Важные failures превратите в постоянные eval cases.

Надёжный AI-продукт — не система, которая никогда не ошибается. Это система с измеримым полезным поведением, ограниченной authority, видимыми и recoverable failures и операторами, способными объяснить результат. Такая дисциплина переживает смену моделей и превращает впечатляющий prototype в поддерживаемое software.