Andrey Bodrov
Смотрите, все уже придумано до нас. Есть сфера, где крайне жесткие регуляции на то, как должна быть устроена инфраструктура. Я говорю про карточный процессинг. Естественно там есть та же самая проблема: нужны логи, но чувствительные данные не должны 1) храниться 2) утечь к хакерам 3) не быть доступным сотрудникам. Поэтому все логи, например, где участвуют номера карт скрывают все цифры кроме последних четырех. Этого достаточно для отладки и дебага, но недостаточно чтобы скомпрометировать кого-то. Та же самая история с токенами, ФИО и чем угодно. В логах данные маскируюся/обфусцируются, и тогда плевать кто их читает: хакеры, недобросовестные сотрудники или LLM.
нет, вы не правы. данные и код принципиально разделяемы и в критичных местах должны быть разделены. LLM тут рабоает с кодом, данные не утекут, если у вас все правильно организовано
в продуктивных логах чувствительные данные должны быть маскированы, например стандарт PCI-DSS заявляет об этом прямо.
в любом случае, отладка на продакшене не совсем рядовое явление, разработка обычно происходит в тестовом окружении, где чувствительных данных быть не должно быть (или они должны быть маскированы/обфусцированы)
что значит чувствительные данные? ключи/пароли/токены в любом случае в сессию не попадают, не кормите их LLMке и ничего утекать не будет. стандартно все токены лежат в .env и читается приложением, нужды отправлять в диалог сам токен нет
Мне если честно на это плевать: даже если вендору попадут мои токены от моих пет-прожектов меня это не сильно волнует.
Если речь о условно персональных данных, то анализировать с помощью ИИ большие объемы это сомнительная идея, в принципе данные обрабатываться должны детерминированными скриптами.
Кому прямо сильно актуально: 1) некоторые агенты уважают .gitignore и не могут из него читать 2) можно тот же claude запустить на приватном инстансе в облаке (aws bedrock). Но в целом проще исходить из того, что на всех ваших логах будут обучаться (и это скорее хорошо)
конечно :) только в этом случае автономность появляется
тесты -> логи -> фикс
и по новой
Изменения в структуре данных РСУБД делаются через миграции и миграции тоже можно тестровать. Про отладку в случае с ИИ важно делать подробные логи, потому что ИИ может перелопачивать большой данных, если ему подкладывать логи в формате [что, ожидаемый результат, фактический результат] это будет максимально эффективно
подождите, при грамотно выстроенном процессе (CI/CD) риск минимальный. В контексте ИИ вообще без разницы кто запускает миграцию/деплой на продакшене: у вас было и тестовой окружение, и препрод с продакшен данными, на которых вы все проверяете. Я не вижу тут разницы в контексте статьи. Или вы спрашиваете в принципе, как менять API/мигрировать БД при разработке?)
Смотрите, основная логика такая: результат отдельного запроса в агент недетерменированный и может содержать ошибки. То есть если мы просим написать сразу скрипт деплоя, он будет правильным на 80% (условно).
Поэтому мы либо просим агента задеплоить командами по одной в "ручном" режиме (он будет ошибаться и корректировать себя), потом оформляем в детерминированный скрипт.
Либо просим написать сразу скрипт деплоя и в несколько итераций доводим до рабочего решения. Ппосле этого мы получаем стабильный скрипт, который не трогаем.
Дальше агент его может вызывать просто как такой же тул; при этом не галлюцинировать и не совершать ошибок, ошибиться в вызове "./deploy_frontend.sh" будет сложно; если конечно же вы сделали краткий гайд, что деплой вызывается этой командой и даете этот гайд прочитать в начале каждой сессии
Это зависит от того как сделаете :)
Но если мы говорим про нашу гипотетическую систему с чувствительными данными в продакшене, то доступа к продуктивной БД вообще не должно быть ни у кого кроме эксплуатации и офицера ИБ.
И да, хорошие логи должны быть "traceability and observability". В больших и сложных системах например используется сквозной uuid запроса чтобы по нему сшить всю историю. Потому что какой смысл в логах, которые требуют похода в продакшен базу? О том, что что-то сломалось вам и пользователь сообщит и/или саппорт пользователя, толку от логов вида "ой какая-то ошибка произошла" ну особо нет, это даже не логи, а по факту счетчик ошибок.
Но если хочется прямо пустить LLM в локальную базу, то вы берете мощную, но все ещё commodity видеокарту (никто вам не запрещает использовать и более мощное железо; я говорю про бытовую карту потому что это доступный уровень для любой организации) и запускаете на ней опен сорс LLM, которые достаточно в общем умные чтобы логи анализировать. И тут ваши данные вообще никуда не утекают.