Почему одного prompt недостаточно

System prompt полезен для поведения, но остаётся текстом внутри вероятностной системы. Доступ к данным, денежные лимиты и опасные actions должны ограничиваться кодом и инфраструктурой.

Guardrails по слоям

На входе проверяются размер, формат, тип данных и допустимый use case. Перед retrieval применяются ACL. Перед model call собирается доверенный context. На выходе валидируются schema и policy. Перед action повторно проверяются identity, scope и approval.

Детерминированные и модельные проверки

JSON Schema, allowlist, regex и permission check воспроизводимы. Модельная moderation ловит смысл и вариативный язык, но может ошибаться. Критическое решение не должно зависеть от одного недетерминированного classifier.

Защита retrieval

Документы являются недоверенным content и могут содержать инструкции. Сохраняйте provenance, отделяйте evidence от instructions, фильтруйте по ACL до поиска и не позволяйте найденному тексту повышать права.

Безопасность tools

Каждый tool получает узкий schema и минимальный scope. Валидируйте параметры сервером, используйте idempotency и dry-run, разделяйте read и write. Для необратимых действий требуется явное подтверждение с конкретным diff.

Output validation

Структурированный ответ проверяйте schema и бизнес-инвариантами. Для текста проверяйте ссылки, PII и запрещённые утверждения по риску. Не превращайте невалидный результат в валидный молча, если меняется смысл.

Fail closed или fail open

Для платежа и доступа сбой guardrail должен блокировать действие. Для низкорискового черновика можно показать результат с предупреждением. Решение фиксируется в risk matrix заранее, а не принимается во время outage.

Evals и мониторинг

Создайте normal, edge, adversarial и regression cases. Измеряйте bypass rate, harmful acceptance, false positive, latency и fallback. Логируйте версию policy и причину решения; инциденты пополняют набор.

С чего начать внедрение?
С узкого сценария, измеримого baseline и набора реальных запросов. Сначала зафиксируйте качество и ограничения, затем меняйте один параметр за эксперимент.
Какие метрики считать обязательными?
Качество результата, p95 latency, ошибки, стоимость и отдельные метрики ключевого этапа. Среднее значение без сегментов и percentiles скрывает провалы.
Можно ли выбрать параметры по документации?
Документация задаёт безопасный baseline, но финальные параметры выбирают по собственному корпусу, нагрузке и eval-набору.
Как обновлять систему без риска?
Версионировать конфигурацию, запускать shadow-сравнение, затем canary и иметь заранее проверенный rollback target.
Почему нужен набор отрицательных примеров?
Он показывает, умеет ли система отказываться и не поднимать нерелевантные результаты только потому, что они ближайшие среди доступных.
Что сохранять для расследования?
Версии компонентов, trace ID, параметры запроса, IDs доказательств, решения фильтров и агрегированные метрики с соблюдением правил доступа и retention.
← Все статьи блога