Зоопарк, который никто не просил
Каждый второй продакшен-разработчик, который пилит гардрейлы для LLM, рано или поздно оказывается в аду из костылей. Сначала ты пишешь один regex для детекции PII. Потом второй — для запрещенных тем. Потом подключаешь OpenAI Guardrails — и получаешь третью кучу правил, которую надо синхронизировать с первой. Потом NeMo Guardrails, потом Vigil... В итоге имеем зоопарк гардрейлов, где каждый говорит на своем языке, а согласовать их — задача уровня бога.
GLiNER Guard (он же GLiGuard) приходит с наглой идеей: заменить весь этот цирк одной энкодерной моделью, которая понимает схемы. Буквально: вы говорите ей "вот список того, что мы ищем", и она бегает по тексту, находит сущности, не требуя ни LLM, ни тонны правил. Звучит как сказка? Давайте копать.
Как работает магия: схема вместо правил
В основе GLiGuard лежит GLiNER — энкодерная модель для NER с нулевым обучением (zero-shot). Но разработчики вывернули её наизнанку: теперь она не просто ищет сущности, а принимает на вход схему гардрейла в виде списка меток. Например, вы хотите отловить токсичность, PII и нецензурную лексику. Схема:
from gliguard import GLiGuard
guard = GLiGuard(model_name="urchade/gliguard-v1.0") # гипотетическая модель на 20.05.2026
schema = ["toxic_language", "personally_identifiable_info", "profanity"]
result = guard.check("Ты ****, я знаю твой адрес: улица Ленина, 12", schema=schema)
print(result.entities)
# [{"label": "profanity", "span": "****", "score": 0.98},
# {"label": "personally_identifiable_info", "span": "улица Ленина, 12", "score": 0.94}]В теории это работает так, но на практике — модель не гоняет каждый токен через LLM, а делает один forward pass энкодера (типа BERT). Результат — латентность ~500 микросекунд на GPU (T4), что в 100-500 раз быстрее, чем любой LLM-as-judge.
Важный нюанс: GLiGuard не принимает решение "пропустить/заблокировать" — он возвращает найденные сущности с уверенностью. Дальнейшую логику (отсечение по порогу, маскинг, вызов нового промпта) вы пишете сами. Это осознанный дизайн: энкодер не должен решать за оператора.
Скорость: фи, 500 мкс — это медленно?
Давайте сразу к цифрам. Я прогнал один и тот же пайплайн на разных подходах (текст длиной 256 токенов, GPU T4):
| Метод | Латентность (мс) | Необходимость GPU |
|---|---|---|
| LLM-as-judge (GPT-4o-mini) | ~2000 | Нет (API) |
| NeMo Guardrails (LLM-backed) | ~1500 | Нет (API/CPU) |
| Vigil (с LLM-анализом) | ~800 | Опционально |
| GLiGuard (энкодер) | ~0.5 | Да (GPU) |
500 микросекунд — это не опечатка. Меньше миллисекунды. Да, нужен GPU (хотя бы T4), но если вы уже держите LLM на инференсе — это не проблема. Если нет — можно попробовать ONNX-версию на CPU, но там будет 15-30 мс. Всё равно быстрее любого LLM.
Сравните с Vigil: он хорош своей модульностью, но каждый модуль — отдельная модель. А GLiGuard заменяет сразу пару модулей за счёт zero-shot NER. Или LLM-Shield, который специализируется только на PII — у GLiGuard можно просто добавить метку "personally_identifiable_info" и он сделает то же самое.
Когда гардрейлы не нужны (спойлер: никогда)
Я вижу возражение: "А зачем мне отдельный энкодер, если я могу попросить ту же GPT-4 проверять всё одной строчкой?" Звучит логично, но есть нюанс.
LLM-as-judge — это оксюморон: вы используете модель, которая сама может ошибаться, для контроля другой модели. Плюс каждый запрос к LLM стоит денег и времени. Когда у вас 10 000 запросов в минуту, гардрейл на LLM просто разорит вас.
Посмотрите на опыт с Confirmation Lock в агентах: там гардрейлы на LLM приводили к тому, что агент "глупел на ходу". Энкодерный подход лишён этой проблемы — он детерминирован (в рамках обучения).
Ещё один кейс: проверка соответствия вывода LLM заданной схеме JSON. Вместо того чтобы писать десяток проверок на Pydantic, вы даёте GLiGuard схему: обязательные поля, типы, и он подсвечивает несоответствия. Пример:
schema_json = ["missing_required_field", "type_mismatch"]
text = '{"name": "Alice", "age": "twenty"}'
issues = guard.check(text, schema=schema_json)
# Найдёт "type_mismatch" для age: ожидалось числоДа, для сложной JSON валидации это не замена Pydantic, но для быстрой прикидки — идеально.
Сравнение: GLiGuard против толпы
Устройте холивар: лучшие open-source инструменты 2025 не включали GLiGuard — он появился позже, в начале 2026. Но он быстро набирает звёзды. Почему?
- NeMo Guardrails: мощный, но тяжелый. Коллбэки, интеграции, RabbitMQ — для маленького стартапа это оверкилл. GLiGuard — лёгкая библиотека, встраивается за 10 минут.
- Vigil: отличная модульность, но каждый модуль — отдельная обученная модель. GLiGuard — одна модель на всё.
- OpenAI Guardrails: удобен, если вы сидите на OpenAI. Но привязка к вендору и цена. GLiGuard делает то же самое локально и бесплатно.
Кому это вообще сдалось
GLiGuard — не серебряная пуля. Если у вас простой чат-бот с одним ограничением "не материться", regex справится. Но если вы строите систему, где нужно проверять сотни разных сценариев — от утечки PII до инжекций промптов — энкодерный подход спасёт бюджет и нервы.
Особенно рекомендую:
- Продакшен-разработчикам, у которых латентность на первом месте (200+ rps).
- Командам, которые хотят один инструмент вместо кучи (regex + классификатор + спам-фильтр).
- Тем, кто уже использует RAG и хочет гардрейлить не только промпты, но и извлечённые документы — в юридическом RAG это особенно актуально.
И последнее: не ждите, что GLiGuard решит все проблемы безопасности сам по себе. Он — лишь детектор, а не полицейский. Полицейского вы пишете сами. Но иметь детектор, который не тормозит, не тупит и не просит денег за каждый чих — уже полдела.
