LLM. Безопасность, управляемость, наблюдаемость.

Есть такая соцсетка, «Сетка». И там завязалось по моей предыдущей статье небольшое обсуждение на на тему разработки с использованием LLM. И, вот, собеседник мой выкатил список из 12 принципов, которые стоит соблюдать при разработке с использованием LLM. Я их приведу как есть (то есть как указал автор) и прокомментирую.

1. Цели допустимы, ответственность закреплена. Определены порядок проверки допустимости целей, ответственные за допуск, эксплуатацию, приёмку и риск, а также порядок разрешения противоречий.

2. Ограничения обеспечиваются независимо от LLM на всех путях исполнения. Для каждого обязательного ограничения определены механизм и границы обеспечения. Соблюдение ограничений исполнения не зависит от правильности ответов или послушания LLM. Отсутствие необходимой защиты блокирует соответствующий режим.

3. Эффективные полномочия ограничены. Прямые действия, делегирование и цепочки взаимодействий не предоставляют исполнителю возможностей сверх утверждённой области.

4. Авторизация проверяется независимо. Ни содержимое данных, ни его преобразование моделью не создают полномочий без проверки доверенного основания разрешения.

5. Изменение имеет контракт. Определены цель, объекты изменения, исходные условия, сохраняемые свойства, допустимые эффекты, бюджеты, сроки, критерии успеха, условия остановки и обработка частичного исполнения.

6. Допуск конкретен и действителен в момент исполнения. Он связан с определённым действием, объектами и версией изменения. Проверяются разрешение, значимые предусловия и допустимое число применений. Существенное изменение условий исключает использование прежнего допуска.

7. Совокупные последствия ограничены. Защита учитывает предусмотренные моделью угроз ошибки, нарушения, общие зависимости и совместное потребление ресурсов.

8. Приёмка опирается на достаточные свидетельства. Проверяются результат, существенные побочные эффекты и необходимые свойства хода исполнения. Свидетельства относятся к проверяемому изменению; достоверность самих средств контроля также подтверждается.

9. Неопределённость имеет процедуру разрешения. Неизвестный исход не считается успехом. Установлены способы выяснения состояния, пределы ожидания и эскалация. Повтор допускается при подтверждённой безопасности повтора.

10. Управление сохраняется при предусмотренных отказах. Остановка, изоляция и восстановление доступны при отказе LLM и штатного пути исполнения; аварийные полномочия определены заранее.

11. Свидетельства защищены и прослеживаемы. Устанавливаются происхождение, целостность, связь с операцией и применёнными правилами. Пробелы наблюдаемости фиксируются; доступ и хранение ограничиваются.

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

Все тезисы можно разделить на три большие группы:

1. Безопасность.

2. Управляемость.

3. Проверяемость (наблюдаемость).

Многие из этих вопросов, будем честны, встают только когда дело касается интаграции или внедрения нейросети в корпоративный контур и ни коим образом не касается фрилансеров, ребят, которые пилят с нейронкой pet-проекты, да и просто разрабов-работяг, которые подключили личный или корпоративный api в kilo или openCode и просто пилят код.

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

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

В первую очередь нужно всегда понимать границы доступов нейросети. То-есть что она может сделать, а чего сделать не может. Разговор не о том захочет или не захочет она ломать ваш ldap и удалять базу клиентов, а может ли она это сделать физически; если каким-то чудом она решит попробовать, что и на каких этапах взлома будет её останавливать и кто несёт ответственность за разные векторы рисков (ограничения контейнера нейросети, механизмы защиты систем, механизмы проверки результатов нейросети).

Лично я рекомендую вообще не запускать мощные нейросети в режиме полного доступа к системе, а нейросети средней и малой мощности в режиме полного доступа к системе вне ограничивающего полномочия контейнера.

Ну и, конечно, иметь понимание, а лучше фиксированное описание векторов рисков при использовании нейросети, ответственных за каждый из векторов и мер, принимаемых для нейтрализации каждого из векторов рисков.

Кто-то может возразить «Но OpenAi и Antropic запускают целые рои полностью автономных агентов и ничего!»

Во-первых, вы не OpenAi, не Antropic и даже не Сбер (скорее всего). У вас нет тех же ресурсов и тех же специалистов.

Во-вторых, даже у OpenAi и Antropic нейронки убегают и взламывают системы третьих лиц. И им тоже приходится разбираться с последствиями. Оно вам надо?

Я понимаю, что оно выглядит круто, эффективно, даже магически. И что хочется "нам так же". Но в большинстве случаев не стоит. По крайней мере пока не посчитали все риски от такого решения.

Нейросеть — инструмент недетерменированный и одна из важных задач при её использовании эту недетерменированность уменьшить. То-есть увеличить вероятность того, что результат генерации окажется именно тем, что нам нужно в как можно большем количестве случаев.

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

Большая часть задач реализуется грамотно составленной документацией. Но при составлении документации нужно помнить об одной особенности нейросетей: чем больше заполненность контекста, тем выше становится недетерменированность ответа нейросети. А это значит, что документация должна быть организованна так, чтобы нейросеть брала в контекст только ту часть документации, которая ей нужна для выполнения конкретного задания.

Это решается грамотно организованной модульной документацией.

Контроль контекста, структуры и качества документации крайне важны для предсказуемости результата генерации.

Помимо этого документация просто незаменима для независимого аудита результатов работы нейросети.

Но не документацией единой.

Помимо неё можно добавить скрипты, которые будут ограничивать права нейросети или полностью останавливать её работу при наступлении определённых условий (например выход за бюджет токенов или зацикливание агента). В ряде harness систем такие механизмы уже есть.

Когда что-то идёт не так (а не так пойти может многое), нам хотелось бы иметь возможность вовремя это заметить и предотвратить либо сам инцидент, либо увеличение потерь от него.

Если предотвратить не удалось, хотелось бы иметь возможность разобрать проблему и выработать меры предотвращения повторения инцидента.

Со вторым проще: логи. Логи команд, рассуждений и ответов, вызовов инструментов. В идеале логи должны находиться так далеко от самой нейросети, как это только возможно. Да, по-умолчанию считаем нейросеть потенциальной угрозой контуру безопасности.

С первым несколько сложнее: это уже нужно вешать на логи мониторинг в реальном времени, обмазывать его триггерами и скриптами, которые по этим триггерам будут обрубать доступы или вообще выключать агента.

На этом, пожалуй, всё. Всех, кто осилил этот текст до конца, приглашаю в комментарии :)