Оценка результатов LLM в продакшене требует большего, чем простые операционные проверки, такие как коды состояния HTTP. Инцидент с чат-ботом Air Canada подчеркивает, как код состояния 200 может скрывать вредоносные галлюцинации, например, выдуманную политику скидок. Для решения этой проблемы необходим отдельный уровень оценки для независимой оценки качества выходных данных от операционного состояния. Этот уровень использует LLM-как-судью с оцененными рубриками для оценки таких аспектов, как правильность и релевантность. Системные подсказки для этих судей должны четко определять их роль, формат вывода и встраивать подробные, последовательные рубрики оценки. Эти рубрики, написанные простым языком, предоставляют критерии и шкалы рейтинга для оценки ответов LLM. Такие методы, как G-Eval, могут повысить надежность, разбивая оценку на последовательные шаги. Защитные ограждения во время выполнения действуют как страховочная сетка, перехватывая и помечая или блокируя небезопасные или нерелевантные выходные данные во время вывода. Эти защитные ограждения часто используют LLM-как-судью с конкретными рубриками, разработанными для немедленного обеспечения соблюдения политики. Внедрение рабочего процесса оценки в продакшене включает версионирование системных подсказок и рубрик, проведение офлайн-оценок и использование защитных ограждений в качестве страховочной сетки во время выполнения. Это создает непрерывный цикл обратной связи для настройки подсказок и поддержания качества. Интегрируя системные подсказки, оцененные рубрики и защитные ограждения во время выполнения, LLM можно эффективно управлять в продакшене, обеспечивая как качество, так и безопасность.