LLMOps: guardrails, router, gateway

Путь запроса: пять слоёв вокруг модели

Модель — одна коробка в середине. Вокруг неё в production стоят слои, которые описывает Chip Huyen в разборе «Building A Generative AI Platform»:

1. Input guardrails (входные фильтры): PII, prompt injection, тема вне задачи.
2. Router (маршрутизатор): куда отправить запрос — к дешёвой модели, к сильной, на страницу помощи или человеку.
3. Gateway (шлюз к моделям): единый доступ ко всем моделям, ключи, лимиты, запасной вариант, журнал.
4. Модель — своя или внешний API.
5. Output guardrails (выходные фильтры): пустой или битый ответ, токсичность, выдумка, утечка PII, риск для бренда.

Каждый слой решает одну задачу и стоит latency и денег. Инженер решает, какие из них нужны этому продукту, а не ставит все подряд.

Входные guardrails: что не должно дойти до модели

Два главных риска на входе. Первый — утечка данных во внешний API: сотрудник или клиент вставляет номер карты или секрет, и запрос уходит поставщику модели. Средство — детектор чувствительных данных, который блокирует или маскирует значения. Huyen описывает и обратимую подстановку: номер заменяют меткой, а в ответе возвращают обратно. И прямо пишет: «There's no airtight way to eliminate potential leaks when using third-party APIs».

Второй риск — jailbreak и prompt injection: текст, который пытается переписать правила модели. Средства — классификатор атак, список запрещённых тем и, главное, человеческое подтверждение для опасных действий (например, SQL, который меняет данные). Классификатор ловит часть атак; подтверждение делает так, что пойманные не нужны для безопасности.

Router: дешёвое — дешёвой модели

Router опирается на intent classifier (классификатор намерения): маленькую модель, которая предсказывает, чего хочет пользователь. Дальше запрос идёт к специализированной модели, на страницу помощи или к оператору. Вопрос вне задачи router отклоняет, не тратя вызов большой модели. Next-action predictor может решить, что сначала нужно уточнить вопрос.

Экономика на примере (числа — допущения). 70 % запросов простые, и маленькая модель стоит десятую часть цены большой. Без router все запросы идут в большую: стоимость 1,0. С router: 0,7 × 0,1 + 0,3 × 1,0 = 0,37 — экономия 63 %. Цена router — его собственные ошибки: если 5 % сложных запросов он отправит в маленькую модель, качество на них упадёт. Поэтому router измеряют как классификатор: precision и recall на размеченной выборке, отдельно по классам.

Gateway: одна дверь ко всем моделям

Gateway — единый слой, через который код обращается и к своим моделям, и к внешним API одинаково. Когда поставщик меняет API, правка остаётся в gateway, а не в двадцати сервисах. Huyen формулирует суть одной фразой: «A model gateway is access control and cost management».

Что делает gateway: - держит ключи организации в одном месте, чтобы они не расползались по репозиториям; - считает расход и ставит лимиты по приложению и пользователю; - fallback: при ошибке или rate limit отправляет запрос в запасную модель или повторяет; - балансирует нагрузку, пишет журнал, иногда держит cache ответов и сам применяет guardrails.

Для банка gateway — ещё и место контроля: именно здесь данные покидают периметр, если модель внешняя. Здесь же стоит правило «модели вне разрешённого региона не вызываются» и пишется журнал, который покажут аудитору. Managed-аналог в AWS — связка Bedrock Guardrails, IAM на конкретную модель и CloudTrail (урок a7-5); open-source вариант — proxy вроде LiteLLM в своей сети.

Cache: какой экономит, а какой ошибается

Gateway часто держит cache (хранилище готовых результатов). Huyen в том же разборе (шаг «Reduce Latency with Cache») различает три вида, и ценность у них разная.

• Prompt cache (кэш общего начала prompt) живёт у поставщика модели. Длинный общий префикс — системные инструкции, документ, описания tools — обрабатывается один раз. У Anthropic (документация, 28.10.2026) чтение из cache стоит 0,1 цены обычного input token (у части новых моделей ещё меньше), запись — 1,25 цены при сроке жизни 5 минут. Ответ модель всё равно пишет заново, поэтому ошибок по смыслу этот cache не вносит.
• Exact cache (кэш точного совпадения) — твой: тот же запрос → тот же сохранённый ответ. Безопасен, но на свободном тексте срабатывает редко.
• Semantic cache (кэш по смыслу): запрос превращается в embedding, ищется похожий прошлый запрос, и если расстояние меньше порога, клиент получает старый ответ без вызова модели. Huyen называет его ценность «more dubious»: всё держится на качестве embeddings, поиска и порога, а похожий запрос — не тот же запрос.

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

Экономия считается просто (числа условные). Если semantic cache отвечает на 30 % запросов, расход на модель падает примерно на 30 %, минус embedding и поиск на каждый запрос. «Счёт вдвое меньше» бывает только при доле попаданий около 50 % — в FAQ-трафике, но не в разговоре с контекстом. Поэтому порядок такой: сначала prompt cache (без риска), потом exact cache, и только потом semantic. У него порог, подобранный на размеченных парах «тот же вопрос / другой вопрос»; ключ cache с пользователем и версией документов, чтобы не отдать чужие данные или старый тариф; срок жизни записей; на dashboard рядом с долей попаданий — доля ложных. Ответы, которые зависят от данных клиента (баланс, лимиты), в общий semantic cache не кладут вовсе.

Выходные guardrails и цена всех фильтров

На выходе ловят: пустой или неправильно оформленный ответ (проверка схемы JSON), токсичность, hallucination (ответ не опирается на источник), утечку чувствительных данных, фразы с риском для бренда, просто плохой ответ (оценка judge-моделью). Что делать при провале: повторить запрос (дороже и дольше), сделать параллельные вызовы (быстрее, но больше запросов) или передать человеку — например, когда пользователь явно зол.

Цена guardrails — три вещи: - latency: каждый фильтр — ещё вызов. Если на входе классификатор 50 мс и детектор PII 30 мс, а на выходе judge 300 мс, к ответу модели за 2,5 с добавляется 15 % (допущения для примера); - false positives (ложные срабатывания): фильтр, который блокирует 3 % нормальных вопросов, раздражает клиентов не меньше ошибок модели; - streaming (выдача ответа по кусочкам): частичный ответ трудно проверить, и плохой текст может дойти до пользователя раньше, чем фильтр его поймает. Компромисс — проверять кусками по предложению или буферизовать короткие ответы целиком.

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

Каждый фильтр — сам по себе модель с ошибками, и его измеряют как классификатор. Нужны две выборки: размеченные атаки и утечки (сколько поймано — recall) и обычный трафик (сколько нормальных запросов заблокировано — false positive rate). Считают отдельно по языкам: детектор, который хорош на английском, может пропускать имена на арабском или казахском. Вердикт каждого фильтра пишется в trace (урок a7-7), чтобы срабатывания можно было разобрать.

Что не может быть guardrail

Guardrail — вероятностный детектор, он снижает риск. Гарантия — это код и права. Две вещи нельзя доверять фильтру, это правило OWASP LLM06 «Excessive Agency»: права доступа (tool берёт счёт из проверенной сессии, а не из текста модели) и подтверждение действий, которые двигают деньги или данные (подтверждает пользователь вне модели). Фильтр, который ловит 95 % атак, для безопасности — провал: атакующий пробует, пока не попадёт в оставшиеся 5 %. Поэтому дизайн убирает одну из трёх составляющих «lethal trifecta» Simon Willison — доступ к приватным данным, недоверенный контент, канал наружу, — а guardrails закрывают остаток, и их измеряют.