К содержанию
Новости

Почему LLM требуют проверки человеком: подход Human-in-the-Loop для повышения доверия к результатам

Почему LLM требуют проверки человеком: подход Human-in-the-Loop для повышения доверия к результатам
Фото: Towards AI

Системы на базе больших языковых моделей могут помогать искать уязвимости в программном коде. Речь о типичных проблемах вроде SQL injection, hardcoded secrets или небезопасного доступа к файлам. Часто это выглядит так: разработчик передаёт модели исходный код и просит найти потенциальные проблемы безопасности с пояснениями. После этого инструмент можно масштабировать и прогнать через него десятки тысяч пакетов. На практике, однако, быстро всплывает вопрос надёжности таких результатов.

Как пишет Towards AI, одна из главных слабых сторон подобных систем, непоследовательность. Один и тот же код с тем же запросом способен давать разные ответы. Например, в одном запуске модель указывает на SQL injection на строке 44, а в другом сообщает, что файл безопасен. Бывает и другая ситуация: модель звучит уверенно, но ошибается. Она сообщает об уязвимости, которая при проверке оказывается ложной. Так происходит, например, когда запрос на самом деле использует parameterized binding, а модель принимает за проблему закомментированную строку, фрагмент тестового кода или просто подозрительную на вид строку.

Такие ложные срабатывания приходится проверять вручную. Со временем это подтачивает доверие к инструменту. Если вывод регулярно оказывается ошибочным, команды просто перестают пользоваться системой. Причина кроется в самой природе LLM. Эти модели недетерминированы: они генерируют текст, выбирая следующий токен из распределения вероятностей. Поэтому разные запуски могут приводить к разным выводам.

Есть и ещё одна проблема. У модели нет надёжного способа оценивать собственную уверенность, любые "оценки вероятности" она тоже генерирует сама. К этому добавляется неоднозначность реального кода: закомментированные строки, тестовые фикстуры, уже очищенные входные данные или вызовы, которые выглядят небезопасно, хотя на деле допустимы. В итоге модель заполняет пробелы правдоподобными догадками, отсюда и возникают галлюцинации. В статье предлагают частично решать эту проблему через систему human-in-the-loop, когда экспертная проверка и накопление обратной связи постепенно повышают точность работы модели.

Ключевые факты

  • При повторном запуске анализа одного и того же кода с тем же промптом модель может дать разные ответы: например, в одном случае сообщить о SQL injection на строке 44, а в другом, заявить, что файл чист.

  • Модель может уверенно сообщать о «SQL injection на строке 44», хотя запрос безопасен и использует parameterized binding; причиной могут быть комментарии, тестовые фикстуры или строки, лишь похожие на уязвимость.

  • LLM генерирует текст, выбирая следующий токен из вероятностного распределения, поэтому без жесткой фиксации параметров разные запуски могут приводить к различным выводам.

  • Даже если модель выводит показатель уверенности вроде «0.9», это сгенерированное значение и не является калиброванной вероятностью правильности вывода.