Привет! Спасибо за интерес к статье! У нас есть сравнение с аналогами, я думаю что и с Вашим примером можно было бы сравнить - но все же концептуально две разные плоскости. Мы отдаем продукт в опенсорс - тестируйте, прикручивайте NER модели, делайте все что угодно бесплатно)
Привет! Спасибо за интерес к статье и за Ваш комментарий! Да, вы абсолютно правы) С таким подходом все модели обучатся, что нас зовут не Васи и Вани, а <PERSON_1> и <PERSON_2> (чего конечно как мы сами понимаем не будет). Опять же мы шли от требований наших клиентов. Мы живем в РФ, у нас есть 152 ФЗ, для многих юридических организаций КРИТИЧНО не нарушать 152 фз и не сливать персональные данные за свой контур.
Привет! Спасибо большое за Ваш интерес! Тезисно - вы абсолютно правы. Сценариев использования LLM модели тысячи и тысячи тысяч. Очевидно что не под все подходит сама концепция анонимизации - тут уже встает вопрос кому и когда нужен этот фильтр. Основной упор, для нас, был на вайбкодеров - так как это основной пласт наших клиентов. И именно у них чаще всего могут утекать персональные данные, ключики, адреса серверов, пароли и прочее - не потому что они просят проанализировать их модель, а просто потому что модель их вычитывает из каких-то файлов в процессе работы. Действительно, странно использовать фильтр при задаче: посчитай сколько здесь паспортов которые начинаются на 4555. Конечно модель после маскировки их не увидит - и полезную работу не исполнит. Зато администратор будет знать, кто и в каком запросе попытался передать персональные данные за внутренний контур - это же основная задача. И касаемо "неизвестно что вырезал" - все известно! Все правила открыты, можно добавлять новые, проверять их в песочнице и главное смотреть в аудите, что именно и когда было замаскировано.
Резюмируя - наш инструмент для предотвращения утечки чувствительных данных. Если ваша задача работать с LLM моделью в контексте обработке персональных данных, то это ваши риски, ваше решение, и можете просто не использовать guardrails filter или, например, выключить в частном порядке правила - которые мешают именно Вашей работе.
Привет! Спасибо большое за интерес к статье! Вот касаемо чатов - смотря какой используете. Если установите ChatBox, например, поднимте guardrails, настроите, чтобы guardrails выступал как прокси до внешнего провайдера, а chatbox ходил в guardrails - то все и заработает. Единственное файлы лучше читать скиллами, а не использовать OCR модели. То есть чтобы чтение файлов происходило через тул колы, тогда вся чувствительная информация не утечет в модель!
Привет! Спасибо за интерес к статье и комментарию!
> При маскировании данных возникает неочевидная проблема: таблица соответствий "реальное значение → псевдоним" сама становится чувствительными данными и требует отдельной защиты
Это максимально корректное и валидное замечание, безусловно. В рамках продукта founudation models маппинг анонимизированных данных к оригинальным - защищен и уникальный для каждого запроса.
> Ещё коварнее другое – LLM способна восстанавливать замаскированные сущности из контекста: если в промпте [PERSON] "работает в [COMPANY] на должности [ROLE] в [CITY]", модель при достаточном контексте выводит, кто это, без явного имени.
Валидное замечание, но при анонимизации - в модель попадают ТОЛЬКО замаскированные данные, она не знает об оригинальных значениях и не может их восстановить. Модель не запоминает новые оригиналы из промпта — она работает только с тем, что видит в запросе, а в запросе она получает маски.
Привет! Спасибо за интерес к статье!
У нас есть сравнение с аналогами, я думаю что и с Вашим примером можно было бы сравнить - но все же концептуально две разные плоскости. Мы отдаем продукт в опенсорс - тестируйте, прикручивайте NER модели, делайте все что угодно бесплатно)
Привет! Спасибо за интерес к статье и за Ваш комментарий!
Да, вы абсолютно правы) С таким подходом все модели обучатся, что нас зовут не Васи и Вани, а <PERSON_1> и <PERSON_2> (чего конечно как мы сами понимаем не будет).
Опять же мы шли от требований наших клиентов. Мы живем в РФ, у нас есть 152 ФЗ, для многих юридических организаций КРИТИЧНО не нарушать 152 фз и не сливать персональные данные за свой контур.
Привет! Спасибо большое за Ваш интерес!
Тезисно - вы абсолютно правы. Сценариев использования LLM модели тысячи и тысячи тысяч. Очевидно что не под все подходит сама концепция анонимизации - тут уже встает вопрос кому и когда нужен этот фильтр.
Основной упор, для нас, был на вайбкодеров - так как это основной пласт наших клиентов. И именно у них чаще всего могут утекать персональные данные, ключики, адреса серверов, пароли и прочее - не потому что они просят проанализировать их модель, а просто потому что модель их вычитывает из каких-то файлов в процессе работы.
Действительно, странно использовать фильтр при задаче: посчитай сколько здесь паспортов которые начинаются на 4555. Конечно модель после маскировки их не увидит - и полезную работу не исполнит. Зато администратор будет знать, кто и в каком запросе попытался передать персональные данные за внутренний контур - это же основная задача.
И касаемо "неизвестно что вырезал" - все известно! Все правила открыты, можно добавлять новые, проверять их в песочнице и главное смотреть в аудите, что именно и когда было замаскировано.
Резюмируя - наш инструмент для предотвращения утечки чувствительных данных. Если ваша задача работать с LLM моделью в контексте обработке персональных данных, то это ваши риски, ваше решение, и можете просто не использовать guardrails filter или, например, выключить в частном порядке правила - которые мешают именно Вашей работе.
Привет! Спасибо большое за интерес к статье!
Вот касаемо чатов - смотря какой используете. Если установите ChatBox, например, поднимте guardrails, настроите, чтобы guardrails выступал как прокси до внешнего провайдера, а chatbox ходил в guardrails - то все и заработает. Единственное файлы лучше читать скиллами, а не использовать OCR модели. То есть чтобы чтение файлов происходило через тул колы, тогда вся чувствительная информация не утечет в модель!
Привет! Спасибо за интерес к статье и комментарию!
> При маскировании данных возникает неочевидная проблема: таблица соответствий "реальное значение → псевдоним" сама становится чувствительными данными и требует отдельной защиты
Это максимально корректное и валидное замечание, безусловно. В рамках продукта founudation models маппинг анонимизированных данных к оригинальным - защищен и уникальный для каждого запроса.
> Ещё коварнее другое – LLM способна восстанавливать замаскированные сущности из контекста: если в промпте [PERSON] "работает в [COMPANY] на должности [ROLE] в [CITY]", модель при достаточном контексте выводит, кто это, без явного имени.
Валидное замечание, но при анонимизации - в модель попадают ТОЛЬКО замаскированные данные, она не знает об оригинальных значениях и не может их восстановить. Модель не запоминает новые оригиналы из промпта — она работает только с тем, что видит в запросе, а в запросе она получает маски.