Шпаргалки¶
Эта страница нужна для быстрых рабочих проверок. Если тебе не хочется перечитывать целую часть книги перед ревью дизайна, запуском агента или обсуждением с командой, начни отсюда.
Канонические сценарии для проверочных списков
Используй эти блоки проверок как быстрый маршрут для трех канонических сценариев. Триаж обращений поддержки начинается с безопасности, шлюза инструментов, подтверждения, идемпотентности и проверки поэтапного выпуска. Внутренний ассистент знаний начинается с памяти, извлечения, привязки к источникам, границ арендатора и проверок наблюдаемости. Координация инцидентов начинается с поэтапного выпуска, наблюдаемости, разбора инцидента, ответственности за реагирование и обучения после инцидента.
Проверка безопасности¶
- Есть ли у агента явные границы доверия между вводом пользователя, памятью, инструментами и внешними системами?
- Различаете ли вы инъекцию в запрос, обход ограничений и галлюцинацию действия, а не сводите все к одной категории риска языковой модели?
- Есть ли политический шлюз перед каждым чувствительным действием, а не только перед вызовом модели?
- Разделены ли инструменты низкого и высокого риска?
- Есть ли шлюз подтверждения для действий с необратимым побочным эффектом?
- Зафиксированы ли разрешенные направления исходящих соединений и профиль сетевого доступа?
- Пишется ли аудиторский след для решений политики, подтверждений и выполнения инструментов?
- Есть ли понятное условие остановки цикла выполнения?
Читать дальше:
- Глава 3. Контур безопасности и границы доверия
- Глава 4. Инструментальный шлюз, подтверждения и журнал аудита
Проверка памяти¶
- Разделены ли краткосрочная, долгосрочная и профильная память?
- Учитывает ли извлечение семантический разрыв между пользовательским языком и языком документов?
- Если вы используете переписывание запроса или HyDE, ясно ли, что это помощь извлечению, а не новый источник фактов?
- Есть ли разные правила для чтения из памяти и записи в память?
- Хранится ли происхождение у постоянных записей?
- Есть ли политика для того, что разрешено записывать в память?
- Есть ли уплотнение или фоновое обслуживание памяти?
- Ограничено ли извлечение по объему и релевантности?
- Пытаетесь ли вы сначала улучшить RAG и свежесть корпуса, прежде чем идти в обучение?
- Есть ли понятная стратегия удаления или пересмотра записи?
Читать дальше:
- Глава 5. Зачем агенту память и почему она опасна
- Глава 7. Извлечение контекста, уплотнение и фоновые обновления
Проверка поэтапного выпуска¶
- Есть ли владелец агента, а не только команда “вообще”?
- Есть ли минимальная базовая линия оценок до запуска?
- Есть ли шлюз поэтапного выпуска с требованиями к безопасности, наблюдаемости и подтверждениям?
- Понятно ли, какие сценарии считаются блокирующими отказами?
- Зафиксирован ли бюджет задержки с точки зрения пользователя, а не только p95 модели?
- Есть ли рабочая инструкция на отказ, запрет действия и очередь подтверждений?
- Есть ли канал для разбора инцидента и постмортема?
- Можно ли быстро отключить возможность высокого риска без полной остановки системы?
Читать дальше:
Проверка наблюдаемости¶
- Есть ли
trace_idу каждого запуска? - Есть ли базовые спаны для извлечения, шага модели, выполнения инструмента, подтверждения и записи в память?
- Есть ли структурированные события, а не только сырые логи?
- Видно ли, какое решение политики принял шлюз?
- Видно ли, какой инструментальный принципал исполнил побочный эффект?
- Можно ли отличить успех, запрет, ожидание подтверждения и отказ?
- Есть ли способ агрегировать запуски в сводки уровня сессии или уровня оценивания?
- Если используется языковая модель как судья, откалиброван ли судья против человеческой проверки и проверки исхода?
- Не меняете ли вы одновременно модель и запрос там, где нужен причинный вывод по результатам оценивания?
Читать дальше:
- Глава 11. Трассы, спаны и структурированные события
- Глава 13. Офлайн-оценки, онлайн-оценки и регрессионные шлюзы
Проверка шлюза инструментов¶
- У каждой возможности есть владелец, уровень риска и утвержденный статус в инвентаре?
- Ясно ли, читает инструмент данные или выполняет запись?
- Не показываете ли вы модели слишком большой каталог инструментов вместо узкого релевантного поднабора?
- Есть ли профиль выполнения: песочница, сетевой доступ и разрешенные исходящие соединения?
- Проверяет ли шлюз личность действующего лица и политику до выполнения?
- Есть ли семантика идемпотентности и политика повторов?
- Понятно ли, когда нужно подтверждение, а когда инструмент может исполниться автоматически?
- Есть ли аудиторский след на каждое внешнее действие?
- Понимает ли команда роли MCP: хост, клиент и сервер, а не смешивает их в одну интеграцию?
Читать дальше:
- Глава 8. Модель выполнения и каталог инструментов
- Глава 9. Песочница выполнения и MCP как интеграционный контракт
- Глава 10. Идемпотентность, повторы, лимиты запросов и границы отката
Что делать дальше¶
- Перед ревью дизайна: быстро пройти блоки безопасности, памяти и шлюза инструментов.
- Перед запуском: пройти блоки поэтапного выпуска и наблюдаемости.
-
Во время разбора инцидента: использовать блоки наблюдаемости и безопасности как каркас разбора.
- Глоссарий терминов
- Шаблоны политик и проверочные списки по кейсам