Super Ethical Reality: о чем нужно задуматься прежде, чем использовать LLM в разработке
Стоит ли нам доверять тому, что не способно осознавать последствий своих действий? Кажется, что ответ очевиден, но по мере развития ниши лингвистических моделей мы всё чаще поручаем ИИ выполнять за нас часть рутинных задач.
Меня зовут София, я сотрудница RnD-отдела компании Raft, работаю на стыке ML и backend. Сегодня мне бы хотелось обсудить вопросы этики использования LLM в контексте процессов разработки. Посмотрим обзорно на то, какие существуют проблемы, каковы превентивные меры, а еще узнаем, какие вопросы мы должны задать сами себе перед тем, как внедрять в продукт лингвистическую модель!
Взаимосвязь LLM и этики
LLM aka Large Language Model — такой вид модели, которая способна «понимать», обрабатывать и генерировать человекоподобный текст. Это знакомые нам GPT, Llama и прочие звери.
Когда мы общаемся с людьми, нам следует придерживаться определенных этических принципов: не стоит обманывать собеседников, раскрывать их секреты, подвергать людей опасности. Теперь же мы общаемся еще и с лингвистическими моделями, делегируем им задачи.
Почти все хотя бы раз просили GPT сгенерировать кусочек кода. И генерация кода — не единственный use-case в области разработки. LLM уже научились успешно использовать для создания архитектуры приложений, написания тест-кейсов, анализа кода на уязвимости. На сегодняшний день использование AI стало частью нашей рутины.
Давайте рассмотрим основные проблемы, с которыми мы можем столкнуться во время использования LLM:
Конфиденциальность и безопасность данных
Этика и безопасность находятся в тесной диалектической связи. Нас в первую очередь интересуют вопросы ответственности создания и использования технологий, безопасности их применения, защиты от неправильного применения.
Первое что приходит в голову, когда мы говорим о безопасности LLM, — это, конечно же, OWASP. Open Web Application Security Project (OWASP) — некоммерческая организация, которая занимается изучением методов повышения уровня безопасности ПО. В конце 2024 года они выпустили обновленный топ уязвимостей, которым подвержены лингвистические модели. Мои коллеги сделали перевод данного материала на русский язык, и уже скоро можно будет ознакомиться с ним.
Обновленный топ включает в себя проблемы манипуляции моделью через промпты, вопросы корректности данных для обучения, обработки вывода, разделения полномочий. Игнорирование этих угроз может привести к серьезным экономическим и имиджевым потерям, деградации сервисов и даже к судебным разбирательствам.
Всё, что мы выше перечислили, очень важно, но помимо классического пользования моделью в каких-то человеческих бытовых целях важно еще рассматривать угрозы, возникающие, когда языковые модели используются для написания кода или проектирования архитектуры
Например, в основе GitHub Copilot тоже лежит LLM. В 2021 году было выпущено исследование, по итогам которого выяснилось, что около 40% кода, генерируемого Copilot, содержит в себе уязвимости. В целом, это не удивительно, если модель обучается на коде, который парсят с GitHub.
Делитесь фейлами своего Copilot в комментариях. Источник: https://x.com/Yampeleg
Как снизить риски?
Обеспечьте системному промпту достаточную защиту от раскрытия и модификации.
Не включайте в промптперсональные данные, финансовые сведения и конфиденциальные бизнес-данные.
Проверяйте плагины, поставщиков плагинов, данные для обучения, а также не оставляйте необработанным ответ модели.
Ограничьте полномочия модели, не оставляйте в ее распоряжении ненужные или опасные функции.
Не забывайте про DoS, ограничивайте ресурсы и вводите лимиты на запросы.
LLM заполняет пробелы в своих данных, используя статистические закономерности. Используйте RAG или fine-tuning, чтобы этого избежать.
Внедрите анализаторы уязвимостей кода в процессы разработки. От себя советую добавить отдельный стейдж с Sonarqube в CI\CD-пайплайн.
Предвзятость и справедливость
Предвзятость LLM — это явление, когда модель начинает генерировать ответы, которые отражают стереотипы, ошибки или чьи-то взгляды, заложенные в обучающие данные. Это может проявляться, например, в дискриминации, неточностях или подтасовках фактов.
Почему это происходит? Модельки учатся на данных, которые уже есть в интернете или других источниках, а там полно всего — и полезного, и не очень. Если в данных много предвзятых мнений, модель их тоже усвоит.
Какое отношение это может иметь к коду или архитектуре? Когда LLM генерирует код, она может выдавать устаревшие решения, небезопасные конструкции или игнорировать лучшие практики, потому что училась на таких данных. Рассмотрим конкретные примеры.
Неэффективность и ненадежность:
Если модель обучалась на старых репозиториях, она может генерировать код, который использует deprecated-функции, небезопасные конструкции или просто неэффективные подходы.
Пример:
Использование
varвместоconst/letв JavaScript, что сейчас считается устаревшей практикой.Генерация SQL-запросов без защиты от инъекций.
Популярный не равно лучший:
Модель может отдать предпочтение популярным, но плохим или небезопасным решениям, если они часто встречались в обучающих данных.
Пример:
Хардкод паролей или ключей, в данных эта ошибка часто встречается.
Использование массивов вместо хэш-таблиц для больших объемов данных, где важна производительность.
Отсутствие индивидуальности:
Модель может генерировать решения, которые плохо подходят для конкретной задачи или языка. Она может предпочесть популярные библиотеки или подходы вместо более специализированных и оптимальных.
Пример:
Генерация решения для Python, основанного на pandas из-за популярности библиотеки, даже если задача лучше решается через встроенные структуры данных.
Как решать данные проблемы?
Использовать подход human evaluation
Прогонять модель на существующих бенчмарках по программированию (или создать свой)
Пользоваться SOTA-техниками промптинга с четким указанием технологий и кросс-проверкой моделью своих же ответов
Стараться избегать делегирования выбора технологий модели
Использовать линтеры и другие статические анализаторы кода
Внедрить и постоянно прогонять юнит-тесты
Дезинформация и неинформативность
AI-тексты быстро создаются, но часто содержат ошибки, предвзятость и галлюцинации. Это особенно опасно в медицине, праве и других серьёзных сферах.
Модели обучаются на данных из интернета, где достаточно неточностей и стереотипов, а сами они не всегда понимают контекст и просто подбирают слова статистически. Подробнее узнать о том, почему LLM врут, можно в статье моего коллеги в нашем блоге.
Отмечу, что под словом «дезинформация» в заголовке мы понимаем ненамеренное введение пользователя в заблуждение со стороны лингвистической модели. Поэтому важно проверять факты: оценивать автора и его квалификацию, возвращаться к оригинальным источникам, анализировать цель публикации. Также стоит учитывать возможные предвзятости, смотреть на актуальность данных и проверять, насколько материалы признаны другими специалистами.
Как бороться с этими проблемами?
Использовать несколько источников для подтверждения фактов, таких как цифры, результаты, утверждения, даты, имена и т. д
Использовать инструменты для фактчекинга: Google Fact Check Explorer или Claimbuster
Оценивать правдоподобие и контекст. Задайтесь вопросом: звучит ли утверждение правдоподобно?
Обращать внимание на дату обновления баз модели.
Попросить модель перепроверить свой же ответ или даже напрямую дать задачу найти ошибки.
Цензура и интеллектуальная собственность
Многие коммерческие LLM (например, OpenAI GPT, Anthropic Claude) подвергаются цензуре или контентным ограничениям в соответствии с политиками компаний-разработчиков. Как это может мешать при разработке?
Модель может отказываться обрабатывать задачи, связанные с чувствительным кодом (например, задачи, предполагающие анализ или генерацию уязвимого кода). Ну и в целом существует проблема того, что код отправляется на сервера поставщика LLM, что противоречит принципам NDA.
При наличии достаточных мощностей можно использовать гибридный подход. Как вариант, использовать коммерческую модель для общей автоматизации и кастомную модель для задач, требующих большей гибкости. Например, OpenAI отправляем задачи по оптимизации простого кода, а локальной LLM отдаем более специфичные задачи, связанные с большим уровнем уязвимости. Общие задачи отправляем в коммерческие модели, а чувствительные и специфические — в self-hosted.
Вторая важная проблема связана с тем, как LLM обрабатывает и генерирует код и текст. При использовании таких моделей в разработке могут возникать риски нарушения прав интеллектуальной собственности.
Модель может воспроизводить фрагменты кода, защищённые авторским правом, если она была обучена на репозиториях, содержащих проприетарные лицензии. Есть небольшое исследование по теме.
Использование сгенерированного кода в проектах с различными лицензиями (например, MIT, GPL) может привести к конфликтам. Например, есть интересный тред на эту тему. Были случаи, когда Copilot генерировал код, защищённый лицензией GPL, что вызывало обеспокоенность относительно соблюдения условий этой лицензии.
Компании тоже обеспокоены этой проблемой и предоставляют свои решения. Например, Copilot имеет правовые гарантии. А Microsoft предоставляют защиту от судебных исков, связанных с интеллектуальной собственностью, при использовании их инструмента. Также существуют специальные инструменты, которые проверяют код на соответствие лицензии (например, FOSSology).
Как бороться с этими проблемами?
Использовать self-hosted LLM и/или добавлять в пайплайн классические ML модели
При наличии достаточных мощностей использовать гибридный подход
Подотчетность и управление принятием решений
Последний в сегодняшней статье, но самый дискуссионный пункт. Всегда будут актуальны вопросы «кто виноват?» и «что делать?», сфера IT не является исключением. Использование больших языковых моделей в процессах разработки обещает автоматизацию, ускорение выполнения задач и повышение производительности. Однако это также ставит важные вопросы. Например, кто несет ответственность за решения, принимаемые с участием LLM? Как управлять процессами, где модели играют ключевую роль? Ниже рассмотрим основные проблемы и варианты их решения.
Про неясность ответственности:
Когда LLM принимает или помогает принимать решения в процессах разработки, не всегда понятно, кто несет ответственность. Если LLM сгенерировала некорректный код или конфигурацию, которая вызвала сбой в продакшене, кто будет отвечать за последствия? Разработчик модели? Команда, которая внедрила LLM? Организация в целом? Правильного ответа нет.
Что делать?
Заблаговременно определить роли и зоны ответственности. Команды должны четко обозначить, кто несет ответственность за принятие окончательных решений. LLM должна выступать помощником, а не единоличным принимателем решений.
Рассмотреть внедрение «Human-in-the-loop» — это обязательная проверка инженерами всех критически важных решений, которые предложила LLM.
Про черный ящик:
Многие LLM являются «черными ящиками», то есть их внутренние процессы принятия решений непрозрачны для пользователей. Разработчики могут не понимать, почему модель предложила то или иное решение. Чтобы случайно не выстрелить себе в ногу, желательно понимать, что под капотом.
Как бороться?
Использовать интерпретируемые LLM.
Интегрировать решения, которые предоставляют не только результат, но и объяснение (например, технологии Explainable AI — XAI).
Все решения, принятые с использованием LLM, логировать, чтобы они были доступны для аудита в будущем. Это поможет выявлять ошибки и улучшать процессы.
Про чрезмерную ИИ-зависимость:
Постепенное перекладывание критически важных решений на LLM может привести к потере навыков у разработчиков, снижению контроля и отсутствию альтернативных решений в случае сбоя модели. Это не способствует росту профессионализма у сотрудников.
Какие методы решения?
Внедрить принцип «Human-in-the-loop», о котором писала чуть подробнее выше.
Ограничить полномочия LLM, четко запротоколировать в процессах, где применение ИИ уместно, а где задачи решаются исключительно человеческими усилиями.
Ограничить доступ LLM к критическим сценариям и сервисам.
Обучение и повышение квалификации сотрудников, чтобы знания и уровень компетенций не снижались со временем.
Разработать планы действий на случай недоступности или некорректной работы LLM. Тактика может включать использование стандартных скриптов, готовых процедур и пошаговых инструкций.
Проверять сервисы на отказоустойчивость.
Про этические и организационные риски:
Использование LLM может привести к предвзятым решениям, как мы уже проговаривали выше, или неправильным выводам из-за ошибок в обучении модели. Это довольно критично там, где важна точность и надежность.
Как противостоять данной проблеме?
Иметь внутреннюю политику и протоколы по использованию LLM, особенно в критически важных процессах.
Проверять результаты LLM на точность и корректность в «боевых» сценариях.
Что дальше?
LLM — очень мощный и действительно классный инструмент, но чтобы применять его максимально безопасно и эффективно, важно уметь им правильно пользоваться. Дружите с языковыми моделями, они готовы вам помочь. При этом помните, что следить за новостями в сфере безопасности LLM — современная необходимость.
Не стесняйтесь делиться своим опытом использования больших языковых моделей в процессах разработки в комментариях. Спасибо, что прогулялись по основным вопросам этики использования больших языковых моделей вместе со мной!
