Понимаю боль - на больших объёмах «дикого» текста опечатки и отсутствующие пробелы вроде т.к.королевой ломают и простые правила, и стандартный NER.
В AI-Gateway мы подходим к этому с точки зрения двухконтурной защиты:
Регулярки + Алгоритмы: Работают там, где есть строгая математика и формат (ИИН/БИН, карты по Луну, IBAN, API-ключи).
Контекстный NER: Извлекает ФИО и мягкие сущности с учетом синтаксического окружения.
Маршрутизация (Fail-Safe): Если текст "сложный" или содержит нешаблонные чувствительные данные, промпт не рискует отправкой во внешние LLM, а автоматически перенаправляется на локальную модель (Ollama / vLLM).
Спасибо за кейс! Обязательно внесем подобные слипшиеся слова и опечатки в тестовый датасет для проверки точности NER.
Спасибо! С удовольствием спишемся — тема защиты GenAI-контура и стандартизации AI Egress/DLP сейчас в самом топе. Будет здорово обменяться опытом и посмотреть на наработки в рамках RFC Linux Foundation.
Привет! Полноценного открытого бенчмарка (датасета) с замерами метрик (Precision/Recall/F1) под все краевые случаи NER в тексте мы пока не публиковали, но это отличная идея для отдельной статьи или дополнения в README.
Если говорить о том, как система справляется с описанными сценариями на практике:
Падежи и склонения: Современные NER-модели (Natasha / spaCy / Transformer-based) неплохо вытаскивают косвенные падежи за счет синтаксического контекста, но пропускают редкие/сложные формы (особенно в узкоспециализированных текстах).
Слова, совпадающие с фамилиями/именами: Главная проблема — фамилии, омонимичные нарицательным существительным («Мороз», «Король», «Надежда»). В строчном регистре без заглавных букв точность детекции традиционными правилами резко падала, поэтому мы опираемся на эмбеддинги и контекстное окружение.
Инициалы и сокращения: Шаблоны с инициалами (И.О. Фамилия, Фамилия И., И. О. Фамилия) закрываются комбинацией регулярных выражений и NER-токенизации достаточно стабильно.
Как решаем проблему неидентификации (False Negatives):
Hybrid Architecture: Регулярки и детерминированные алгоритмы (Лун, ИИН, IBAN, API-ключи) дают ~100% точность на жестких форматах, а NER закрывает мягкие сущности (ФИО, адреса).
Local Fallback (Ollama/vLLM): Спорные фрагменты или промпты с низкой уверенностью (confidence threshold) детектора переводятся на локальную LLM, чтобы не рисковать отправкой в публичный API.
Мы планируем собрать синтетический датасет с русскоязычными/казахстанскими ФИО (включая омонимию, опечатки, нижний регистр и разный порядок инициалов) и выложить публичные замеры Precision/Recall. Если есть интересные тест-кейсы — буду рад, если закинете их в issues на GitHub!
Привет! Огромное спасибо за детальный разбор и качественный архитектурный аудит. Редко в комментариях видишь настолько глубокий и системный подход к безопасности — это реально ценно.
Пройдусь по каждому из подсвеченных пунктов и расскажу, как мы это видим, и что уходит в ближайший backlog:
1. Валидация структур и границы допуска
Согласен. Повышение качества регулярных выражений и алгоритмов валидации (Лун, ИИН/БИН) — это лишь первый рубеж. Если структура запроса или контекста ломает логику связывания маскировка -> демаскировка, механизм дает сбой. Усилим строгую валидацию входных/выходных структур данных до передачи их в движок маскирования.
2. Безопасность Browser Extension и DOM
Отличное замечание по архитектуре. Изолированный JS-контекст (Content Script) действительно защищает переменные расширения от скриптов страницы, но сам DOM остаётся общим пространством. Если сама страница (например, веб-интерфейс ChatGPT/Claude) захочет прочитать то, что было вставлено в поле ввода после демаскировки — она это сделает.
Как планируем закрыть: Для сценариев с критичным контуром правильный вектор — это уход от подмены текста напрямую в DOM вендора в пользу отдельного UI-интерфейса (pop-up / standalone overlay) либо использование сетевого Egress-прокси вместо браузерного расширения. Добавим соответствующее предупреждение в документацию к Extension-модулю.
3. Полнота перехвата на Endpoint (Clipboard vs Network)
Полностью подписываюсь. Polling клипборда — это именно «удобный костыль» для UX (быстрый детектив перед вставкой в IDE/Chat), но ни в коем случае не DLP-гарантия. Настоящий контроль в Enterprise должен обеспечиваться на сетевом уровне (Egress Proxy / WAF / DNS sinkhole) с блокировкой прямого доступа к API вендоров в обход шлюза. Обязательно четко разграничим это в документации к агенту.
4. Криптография и Zero-Dependency
Важная дилемма проекта. Мы сознательно шли в Zero-Dependency для ядра, чтобы минимизировать Supply Chain риски и сделать возможной работу в жестких Air-Gapped средах «из коробки».
По поводу PRF-CTR / HMAC: вы абсолютно правы, изобретать свою криптографию — грех. Мы опирались на стандартные secrets и hashlib из stdlib Python, но для production-профиля разумнее дать возможность переключения на стандартные, проверенные сообществом AEAD-библиотеки (например, cryptography / Fernet) или KMS.
По поводу памяти и обратного индекса: очистка ссылок в Python действительно ограничена работой GC и internal string interning. Внесем сноску о специфике работы memory manager в Python.
5. Hardening & Supply Chain
Принято. Zero-dependency в коде приложения не отменяет уязвимостей в самом Python runtime, системных библиотеках Alpine/Debian и контейнерной среде.
В ближайших релизах вынесем в документацию рекомендуемый Prod-профиль: включение TLS/mTLS на шлюзе, обязательную RBAC-аутентификацию, фиксирование digest'ов базовых Docker-образов (pinning by hash) и пайплайн сканирования (Trivy/Grype).
6. Тестирование и позиционирование
Золотые слова. Успешный pytest тестирует только то, что придумал разработчик, но не гарантирует отсутствие скрытых каналов утечки или сложных инъекций. Разделим метрики в README на:
Точность/полноту детекции паттернов.
Гарантии изоляции сетевого контура.
Еще раз спасибо за точный и конструктивный аудит! Если есть желание — буду рад видеть ваши issue или PR в репозитории AI-Gateway!
Отличный и очень детальный разбор! Отдельный плюс за глубокий тест на сложных фичах PostgreSQL (партиционирование, INHERITS, составные типы и GENERATED ALWAYS) — именно на них обычно «спотыкаются» большинство сапмописных скриптов и упрощенных утилит обезличивания.
Из того, что особенно отозвалось по практическому опыту SecOps / DBA:
Дилемма «Псевдонимизация vs Обезличивание»: Очень правильно подсвечен тезис о том, что pg_anon по умолчанию создает псевдонимизированную копию. Если словарь просто подменяет ФИО на случайный Hash/Faker, но сохраняет связность уникальных внешних ключей и специфические бизнес-метрики, обратная деанонимизация через контекстный анализ всё ещё возможна. Настройка словарей под честное обезличивание — это всегда тонкий баланс между безопасностью и сохранением репрезентативности данных для тестировщиков.
Исправление задвоения при INHERITS: Проблема дублирования строк при дампе иерархических таблиц через родителя — настоящая боль крупных legacy-баз. Здорово, что в 1.11.0 это закроссили.
Контейнеризация и REST API (pg_anon_api): Упаковка утилиты в полноценный Python-пакет (pip install pg_anon[api]) и вынос PG_ANON_HOME под отдельные тома сильно упрощает встраивание маскирования в ночные CI/CD-пайплайн развертывания анонимизированных Dev-стендов.
Сквозной проброс опций (--pg-dump-options / --pg-restore-options): Гибкость под капотом решать редкие края (вроде твиков параллелизма --jobs или специфических флагов очистки) без необходимости форкать сам инструмент — отдельное спасибо.
Спасибо авторам и команде за развитие Open Source инструмента для экосистемы Postgres!
Отличный кейс, абсолютно согласен по поводу связки LLM + CLI для рутины. Когда агент получает прямой доступ к SSH/Bash, скорость разворачивания и миграции нетиповых инстансов возрастает в разы.
Но по поводу 1С я бы добавил пару нюансов:
Проблема не в языке, а в экосистеме: Написать модуль на 1С для LLM не проблема - контекстное окно спокойно переваривает конфигурации. Главный блокер в том, что 1С - это закрытый «вещь в себе» контур. Там нет нормального headless-CLI, адекватно интегрированного в современный DevSecOps-пайплайн, где нейросеть могла бы сама выполнить git diff, запустить тесты в контейнере, применить миграции и сразу проверить runtime-ошибки.
Безопасность и промпты: При передаче агенту боевых кредов от хостинга (даже для миграции 10 сайтов) стоит внедрять хотя бы базовые валидационные пробы или запуск через изолированные сервисные учетки. Главный риск таких «независимых» сессий - не сам процесс переноса, а момент, когда модель решает тихо выполнить rm -rf или затереть конфиг, посчитав его устаревшим.
А так - да, ручной L1/L2 администринг и типовой веб-девопс для SMB уже фактически закрываются агентами. Кто научился правильно обволакивать модели инструментами автоверификации, тот и выигрывает в скорости.
Отличная статья и монументальный объём низкоуровневой работы! Читать про реверс-инжиниринг ANE, работу с XPC и сборку пайплайна через MIL-код - одно удовольствие.
Пара мыслей по прочитанному:
1. Трюки с KV-кэшем и ограничениями MIL: Решение с эмуляцией обновления кэша через комбинацию gather + select по маске вместо отсутствующего slice_update - это изящный костыль, который реально работает в условиях жестких ограничений компилятора ANE.
2. Асинхронность и Overhead: Замена синхронного вызова на completionHandler с atomic-wait и плотная набивка очереди ANE — ключевой момент всей оптимизации. Взаимодействие процессов через XPC в macOS всегда славилось конским оверхедом на контекст-свитчах, и сокращение простоя NPU на 10-15% дает ощутимый буст к TTFT.
3. Перспективы Qwen 3.5 & DeltaNet: С появлением рекуррентных архитектур и гибридных слоев (как в Qwen 3.5) нагрузка на память действительно падает, но отсутствие нативной поддержки depthwise-сверток на ANE «из коробки» — неприятный блокер. Будет интересно посмотреть, удастся ли разложить их на цепочку из батчевых matmul или эмулировать через групповые операции.
Спасибо за открытый репозиторий и подробный разбор системных логов! Буду следить за обновлениями по части OpenAI API и квантизации.
Понимаю боль - на больших объёмах «дикого» текста опечатки и отсутствующие пробелы вроде
т.к.королевойломают и простые правила, и стандартный NER.В AI-Gateway мы подходим к этому с точки зрения двухконтурной защиты:
Регулярки + Алгоритмы: Работают там, где есть строгая математика и формат (ИИН/БИН, карты по Луну, IBAN, API-ключи).
Контекстный NER: Извлекает ФИО и мягкие сущности с учетом синтаксического окружения.
Маршрутизация (Fail-Safe): Если текст "сложный" или содержит нешаблонные чувствительные данные, промпт не рискует отправкой во внешние LLM, а автоматически перенаправляется на локальную модель (Ollama / vLLM).
Спасибо за кейс! Обязательно внесем подобные слипшиеся слова и опечатки в тестовый датасет для проверки точности NER.
Спасибо! С удовольствием спишемся — тема защиты GenAI-контура и стандартизации AI Egress/DLP сейчас в самом топе. Будет здорово обменяться опытом и посмотреть на наработки в рамках RFC Linux Foundation.
Привет! Полноценного открытого бенчмарка (датасета) с замерами метрик (Precision/Recall/F1) под все краевые случаи NER в тексте мы пока не публиковали, но это отличная идея для отдельной статьи или дополнения в README.
Если говорить о том, как система справляется с описанными сценариями на практике:
Падежи и склонения: Современные NER-модели (Natasha / spaCy / Transformer-based) неплохо вытаскивают косвенные падежи за счет синтаксического контекста, но пропускают редкие/сложные формы (особенно в узкоспециализированных текстах).
Слова, совпадающие с фамилиями/именами: Главная проблема — фамилии, омонимичные нарицательным существительным («Мороз», «Король», «Надежда»). В строчном регистре без заглавных букв точность детекции традиционными правилами резко падала, поэтому мы опираемся на эмбеддинги и контекстное окружение.
Инициалы и сокращения: Шаблоны с инициалами (
И.О. Фамилия,Фамилия И.,И. О. Фамилия) закрываются комбинацией регулярных выражений и NER-токенизации достаточно стабильно.Как решаем проблему неидентификации (False Negatives):
Hybrid Architecture: Регулярки и детерминированные алгоритмы (Лун, ИИН, IBAN, API-ключи) дают ~100% точность на жестких форматах, а NER закрывает мягкие сущности (ФИО, адреса).
Local Fallback (Ollama/vLLM): Спорные фрагменты или промпты с низкой уверенностью (confidence threshold) детектора переводятся на локальную LLM, чтобы не рисковать отправкой в публичный API.
Мы планируем собрать синтетический датасет с русскоязычными/казахстанскими ФИО (включая омонимию, опечатки, нижний регистр и разный порядок инициалов) и выложить публичные замеры Precision/Recall. Если есть интересные тест-кейсы — буду рад, если закинете их в issues на GitHub!
Привет! Огромное спасибо за детальный разбор и качественный архитектурный аудит. Редко в комментариях видишь настолько глубокий и системный подход к безопасности — это реально ценно.
Пройдусь по каждому из подсвеченных пунктов и расскажу, как мы это видим, и что уходит в ближайший backlog:
1. Валидация структур и границы допуска
Согласен. Повышение качества регулярных выражений и алгоритмов валидации (Лун, ИИН/БИН) — это лишь первый рубеж. Если структура запроса или контекста ломает логику связывания
маскировка -> демаскировка, механизм дает сбой. Усилим строгую валидацию входных/выходных структур данных до передачи их в движок маскирования.2. Безопасность Browser Extension и DOM
Отличное замечание по архитектуре. Изолированный JS-контекст (Content Script) действительно защищает переменные расширения от скриптов страницы, но сам DOM остаётся общим пространством. Если сама страница (например, веб-интерфейс ChatGPT/Claude) захочет прочитать то, что было вставлено в поле ввода после демаскировки — она это сделает.
Как планируем закрыть: Для сценариев с критичным контуром правильный вектор — это уход от подмены текста напрямую в DOM вендора в пользу отдельного UI-интерфейса (pop-up / standalone overlay) либо использование сетевого Egress-прокси вместо браузерного расширения. Добавим соответствующее предупреждение в документацию к Extension-модулю.
3. Полнота перехвата на Endpoint (Clipboard vs Network)
Полностью подписываюсь. Polling клипборда — это именно «удобный костыль» для UX (быстрый детектив перед вставкой в IDE/Chat), но ни в коем случае не DLP-гарантия. Настоящий контроль в Enterprise должен обеспечиваться на сетевом уровне (Egress Proxy / WAF / DNS sinkhole) с блокировкой прямого доступа к API вендоров в обход шлюза. Обязательно четко разграничим это в документации к агенту.
4. Криптография и Zero-Dependency
Важная дилемма проекта. Мы сознательно шли в Zero-Dependency для ядра, чтобы минимизировать Supply Chain риски и сделать возможной работу в жестких Air-Gapped средах «из коробки».
По поводу PRF-CTR / HMAC: вы абсолютно правы, изобретать свою криптографию — грех. Мы опирались на стандартные
secretsиhashlibиз stdlib Python, но для production-профиля разумнее дать возможность переключения на стандартные, проверенные сообществом AEAD-библиотеки (например,cryptography/ Fernet) или KMS.По поводу памяти и обратного индекса: очистка ссылок в Python действительно ограничена работой GC и internal string interning. Внесем сноску о специфике работы memory manager в Python.
5. Hardening & Supply Chain
Принято. Zero-dependency в коде приложения не отменяет уязвимостей в самом Python runtime, системных библиотеках Alpine/Debian и контейнерной среде.
В ближайших релизах вынесем в документацию рекомендуемый Prod-профиль: включение TLS/mTLS на шлюзе, обязательную RBAC-аутентификацию, фиксирование digest'ов базовых Docker-образов (pinning by hash) и пайплайн сканирования (Trivy/Grype).
6. Тестирование и позиционирование
Золотые слова. Успешный
pytestтестирует только то, что придумал разработчик, но не гарантирует отсутствие скрытых каналов утечки или сложных инъекций. Разделим метрики в README на:Точность/полноту детекции паттернов.
Гарантии изоляции сетевого контура.
Еще раз спасибо за точный и конструктивный аудит! Если есть желание — буду рад видеть ваши issue или PR в репозитории AI-Gateway!
Отличный и очень детальный разбор! Отдельный плюс за глубокий тест на сложных фичах PostgreSQL (партиционирование,
INHERITS, составные типы иGENERATED ALWAYS) — именно на них обычно «спотыкаются» большинство сапмописных скриптов и упрощенных утилит обезличивания.Из того, что особенно отозвалось по практическому опыту SecOps / DBA:
Дилемма «Псевдонимизация vs Обезличивание»: Очень правильно подсвечен тезис о том, что
pg_anonпо умолчанию создает псевдонимизированную копию. Если словарь просто подменяет ФИО на случайный Hash/Faker, но сохраняет связность уникальных внешних ключей и специфические бизнес-метрики, обратная деанонимизация через контекстный анализ всё ещё возможна. Настройка словарей под честное обезличивание — это всегда тонкий баланс между безопасностью и сохранением репрезентативности данных для тестировщиков.Исправление задвоения при
INHERITS: Проблема дублирования строк при дампе иерархических таблиц через родителя — настоящая боль крупных legacy-баз. Здорово, что в 1.11.0 это закроссили.Контейнеризация и REST API (
pg_anon_api): Упаковка утилиты в полноценный Python-пакет (pip install pg_anon[api]) и выносPG_ANON_HOMEпод отдельные тома сильно упрощает встраивание маскирования в ночные CI/CD-пайплайн развертывания анонимизированных Dev-стендов.Сквозной проброс опций (
--pg-dump-options/--pg-restore-options): Гибкость под капотом решать редкие края (вроде твиков параллелизма--jobsили специфических флагов очистки) без необходимости форкать сам инструмент — отдельное спасибо.Спасибо авторам и команде за развитие Open Source инструмента для экосистемы Postgres!
Отличный кейс, абсолютно согласен по поводу связки LLM + CLI для рутины. Когда агент получает прямой доступ к SSH/Bash, скорость разворачивания и миграции нетиповых инстансов возрастает в разы.
Но по поводу 1С я бы добавил пару нюансов:
Проблема не в языке, а в экосистеме: Написать модуль на 1С для LLM не проблема - контекстное окно спокойно переваривает конфигурации. Главный блокер в том, что 1С - это закрытый «вещь в себе» контур. Там нет нормального headless-CLI, адекватно интегрированного в современный DevSecOps-пайплайн, где нейросеть могла бы сама выполнить
git diff, запустить тесты в контейнере, применить миграции и сразу проверить runtime-ошибки.Безопасность и промпты: При передаче агенту боевых кредов от хостинга (даже для миграции 10 сайтов) стоит внедрять хотя бы базовые валидационные пробы или запуск через изолированные сервисные учетки. Главный риск таких «независимых» сессий - не сам процесс переноса, а момент, когда модель решает тихо выполнить
rm -rfили затереть конфиг, посчитав его устаревшим.А так - да, ручной L1/L2 администринг и типовой веб-девопс для SMB уже фактически закрываются агентами. Кто научился правильно обволакивать модели инструментами автоверификации, тот и выигрывает в скорости.
Отличная статья и монументальный объём низкоуровневой работы! Читать про реверс-инжиниринг ANE, работу с XPC и сборку пайплайна через MIL-код - одно удовольствие.
Пара мыслей по прочитанному:
1. Трюки с KV-кэшем и ограничениями MIL: Решение с эмуляцией обновления кэша через комбинацию
gather+selectпо маске вместо отсутствующегоslice_update- это изящный костыль, который реально работает в условиях жестких ограничений компилятора ANE.2. Асинхронность и Overhead: Замена синхронного вызова на
completionHandlerсatomic-waitи плотная набивка очереди ANE — ключевой момент всей оптимизации. Взаимодействие процессов через XPC в macOS всегда славилось конским оверхедом на контекст-свитчах, и сокращение простоя NPU на 10-15% дает ощутимый буст к TTFT.3. Перспективы Qwen 3.5 & DeltaNet: С появлением рекуррентных архитектур и гибридных слоев (как в Qwen 3.5) нагрузка на память действительно падает, но отсутствие нативной поддержки depthwise-сверток на ANE «из коробки» — неприятный блокер. Будет интересно посмотреть, удастся ли разложить их на цепочку из батчевых
matmulили эмулировать через групповые операции.Спасибо за открытый репозиторий и подробный разбор системных логов! Буду следить за обновлениями по части OpenAI API и квантизации.