Полностью согласен, у меня у самого было немало негативного опыта с такими ботами. Часто проблема не в том, что используется LLM, а в том, как именно его прикручивают: маскируют под человека, не дают уйти к живому оператору, экономят на сценариях и безопасности
Спасибо за развёрнутый комментарий По поводу внешних чат-ботов. Скептицизм понятен, но кейсы реальны: Klarna публично сообщала, что их LLM-ассистент закрывает порядка 2/3 обращений в поддержку; Revolut, Tinkoff, крупные телекомы (МТС, Билайн) используют LLM-ботов для первой линии. Риски там действительно высокие — именно поэтому guardrails становятся не опцией, а необходимостью. По поводу разделения system/user и тегов. Полностью согласен: правильное разделение через API + оборачивание ввода в теги — хорошая первая линия. Но здесь есть один нюанс, который вы сами точно подметили: «если пользователь знает теги». В опенсорсных интеграциях (LangChain, Spring AI, публичные шаблоны промптов) имена тегов давно не секрет. Security through obscurity — слабая защита: достаточно одного паблика на GitHub с вашим промптом или одного любопытного пользователя, который методично перебирает </user_request> и похожие конструкции. Второй момент — поведение модели со временем меняется: файн-тюнинг, смена провайдера, обновление версии — и граница между system/user может поплыть. Детерминированный код-левел enforcement этим не страдает. JGuardrails как раз закрывает этот слой: блокировка/маскирование происходят до того, как текст вообще попадает в промпт, и после того, как LLM вернул ответ — независимо от того, какая модель стоит за API и как она интерпретирует теги. Если у вас есть наработки по защите, которые хорошо себя показали на практике — буду рад обсудить, возможно, имеет смысл оформить как отдельный InputRail / OutputRail в библиотеке
Спасибо вам большое! Насчёт проверки, очень интересный подход :)
Полностью согласен, у меня у самого было немало негативного опыта с такими ботами. Часто проблема не в том, что используется LLM, а в том, как именно его прикручивают: маскируют под человека, не дают уйти к живому оператору, экономят на сценариях и безопасности
Спасибо за развёрнутый комментарий
По поводу внешних чат-ботов. Скептицизм понятен, но кейсы реальны: Klarna публично сообщала, что их LLM-ассистент закрывает порядка 2/3 обращений в поддержку; Revolut, Tinkoff, крупные телекомы (МТС, Билайн) используют LLM-ботов для первой линии. Риски там действительно высокие — именно поэтому guardrails становятся не опцией, а необходимостью.
По поводу разделения system/user и тегов. Полностью согласен: правильное разделение через API + оборачивание ввода в теги — хорошая первая линия. Но здесь есть один нюанс, который вы сами точно подметили: «если пользователь знает теги». В опенсорсных интеграциях (LangChain, Spring AI, публичные шаблоны промптов) имена тегов давно не секрет. Security through obscurity — слабая защита: достаточно одного паблика на GitHub с вашим промптом или одного любопытного пользователя, который методично перебирает
</user_request>и похожие конструкции.Второй момент — поведение модели со временем меняется: файн-тюнинг, смена провайдера, обновление версии — и граница между system/user может поплыть. Детерминированный код-левел enforcement этим не страдает.
JGuardrails как раз закрывает этот слой: блокировка/маскирование происходят до того, как текст вообще попадает в промпт, и после того, как LLM вернул ответ — независимо от того, какая модель стоит за API и как она интерпретирует теги.
Если у вас есть наработки по защите, которые хорошо себя показали на практике — буду рад обсудить, возможно, имеет смысл оформить как отдельный
InputRail/OutputRailв библиотеке