Почему для оценки качества ответов LLM не используется многократный прогон модели на одних и тех же данных?
Привет. У меня вопрос к разработчикам LLM. Периодически читаю про жалобы на галлюцинации LLM и невозможность адекватной оценки вероятности её ответов (типа, уверенно врёт). При этом, я раньше занимался разработкой системы распознавания рукописного текста, и у нас была в чём-то схожая проблема (трудно было оценить достоверность результатов распознавания). Решалась она довольно неплохо путём прогона цепочки распознавания достаточно большого числа раз на одном и том же изображении, и последующей перенормировкой вероятностей в итоговом списке ответов (ответы, по существу генерировались методом монте-карло путём последовательного продвижения по графу возможных вариантов в байесовской цепи). Как понимаю, в LLM принцип генерации ответа в чём-то похожий (последовательный вероятностный перебор цепочки токенов с генерацией их в реальном масштабе времени). Соответственно, вопрос - а если повысить в разумных пределах температуру и Top P, прогонять цепочку несколько раз, а потом пересчитывать итоговую вероятность правильности ответа путём перенормировки списка, это не может ли помочь хотя бы частично решить проблему?
PS
Заранее извиняюсь, если что-то не догоняю, я в LLM не Копенгаген, но идея, думаю, понятна.
Как вариант - потому что у LLM вариативность входных данных сильно выше.
В целом если вы затачиваете LLM локально под нужные вам задачи - то этот метод подойдет неплохо. Но как только вы скормите сети другие входыне данные - там увеличится вероятность галлюцинации.
А ну и плюс для LLM это может быть технически долго\дорого, вполне может быть баланс для бизнеса
Тоже не эксперт, поэтому считайте это предположением
GavriKos, спасибо за отклик. Как понимаю, если данных, подобных тем, что на входе, в обучающей выборке не было, в любом случае вырастает вероятность галлюцинации. Но в случае прослеживания сразу нескольких траекторий мы будем иметь на выходе несколько примерно равновероятных (плохих) ответов. Поэтому и уверенность, что тот ответ, который был на первом месте, правильный, будет низкой (очень грубо говоря, Pbest/N, где N - число протестированных траекторий). Соответственно, и ответ LLM можно/нужно будет скорректировать до "я не знаю"/"я не компетентна ответить на этот вопрос". Если вероятность получится промежуточной (не совсем плохой, но и не очень хорошей) можно добавить к ответу - что то вроде "это лишь один из возможных вариантов, лучше так же уточнить в других источниках и т.д.
По поводу увеличения времени - это не обязательно увеличение на порядки, так как пересчитывать нужно будет лишь в некоторых вершинах графа, а именно, в тех, в которых есть наибольшая неопределённость. По крайней мере, в нашем случае, оно увеличивалось не более, чем в полтора - два раза. При этом, если вопрос простой, оно вообще практически не должно увеличиваться. Короче говоря, это как при выборе правильного хода в шахматах - если позиция очевидна, ходы делаются быстро, а вот если позиция сложная - надо подольше подумать. Мне кажется, улучшение качества ответов для бизнеса вполне может компенсировать некоторое уменьшение скорости. Да они могут и сами выбирать наиболее комфортный конкретно для них баланс скорость/качество, меняя порог, через который регулируется количество просматриваемых веток дерева при переборе вариантов.
Надеюсь, что, может быть, всё же кто-то, кто ближе к разработчикам реальных LLM всё же сможет прояснить этот вопрос.
Если вероятность получится промежуточной (не совсем плохой, но и не очень хорошей) можно добавить к ответу - что то вроде "это лишь один из возможных вариантов, лучше так же уточнить в других источниках и т.д.
Вот этот момент мне самому непонятен - почему не ставят пороговую функцию, и если вероятность ниже порога - просто "нафиг" и все. Может потому что сам этот порог сложно точно вычислить. А может все так же бизнес решает )
Можно даже не обязательно "нафиг", а просто всегда сопровождать любой ответ численной оценкой его истинности. А дальше уж пусть пользователи (хоть интеграторы, хоть сам бизнес) решают, что с этим делать. Мне кажется, эта оценка имеет ничуть не меньшую коммерческую ценность, чем сам формальный ответ.
Combinator_30, я когда давал deepseek простую задачу несколько раз, получал несколько разных вариантов кода. Часть вариантов решало задачу не полностью. Как их автоматически оценить по правильности? Как человек я понимаю что код - фигня, а llm нужна другая llm которая оценит код и скорректирует первую. Это вроде так работает сейчас режим размышления. В вашем кейсе с распознаванием одного и того же текста результат строго детерминирован этим самым текстом.
Не очень понял, что значит, "результат строго детерминирован этим самым текстом"? При таком подходе и выдаваемый llm код, строго говоря, детерминирован вашим промптом. А оценка ответов одной llm с помощью другой это альтернативный подход, их, в принципе, можно использовать вместе.
Потому что не в каждом случае можно понять, какой и 1000 ответов - верный, но там где это можно статистически - пользуются (и это повышает качество ответа, но линейно при экспоненциальных затратах - т.е. дорого).
(так было, сейчас стараются гонять больше параллельных агентов и рассуждениями).
Вообще то наибольшую пользу в тестах представляют логи прохождения тестов, например что бы узнать, какие задачи не были решены моделями, вот на них кросстестирование запускать на разных моделях интереснее.
И да, тесты гоняют не для нас, пользователей, а для компаний-производителей, для рекламы и очернения конкурента. Зачем им делать нам пользу? хочешь что то протестировать, сделай это сам, на своих данных, получишь совсем иную картину. Тем более сейчас инструкции или скрипты для проведения бенчмарка по твоим условиям пишет любая средняя модель за 10 минут с ней работы.
Предположу, что тут надо разбирать две метрики: температуру и Confidence score. При разумно выставленной температуре модель честно отвечает, что не может ответить на вопрос (если не может). А вот степень уверенности с разбросом в 100% - это уже про внутреннюю оценку. Даже в самых простых случаях динамика там очень высокая, и едва ли можно использовать этот показатель для тестирования.
Собственно, а у людей разве не так? Чем глупее человек - тем более он уверен в собственных выводах.
Да, у глупых людей, конечно, тоже так, но зачем нам копировать поведение глупого человека?) А вот рассмотрение сразу нескольких цепочек решения может, кмк, повысить надёжность самооценки качества ответа, см., например, дискуссию здесь: https://habr.com/ru/posts/1001552/
Combinator_30, тут два момента. NLP и зависимость от контекста. Если бы модель выдёргивала единственные верные решения (или максимально близкие, там скоринг простой) - никаких проблем. Вопросно-ответные системы примерно так и работают.
А вот второй момент - экономическая целесообразность и целесообразность вообще. LLM не задуманы как эксперты, владеющие истиной в последней инстанции. Речь всего лишь об устойчиво воспроизводимых речевых паттернах, имитирующих мышление. Зачем усложнять процесс?
Виктор Петров, так с использованием LLM в виде продвинутых болталок или справочников и сейчас проблем нет, с этим даже самые простые бесплатные модели справляются. Но производителям больше интересны серьёзные заказчики для серьезных задач, именно в этом секторе рынка, как понимаю, они собираются зарабатывать. Соответственно, и пиписьками самые продвинутые модели предпочитают мериться в тестах типа HLE и ARC-AGI-2, где и человеку приходится напрягаться. Я уже не говорю про решение математических проблем, которые пока и белковые математики не осилили. Именно здесь, я думаю, подключение проверки различных альтернативных путей по графу могут существенно улучшить результаты в плане соотношения качества и цены.
Combinator_30, ну вот я думаю, что тут индустрия очень сильно разделится. С одной стороны - суперкомпьютеры для супермоделей, затратные и закрытые. С другой - SLM, заточенные под агентские задачки, дешёвые и доступные массам.
То, что происходит в этой нише сейчас - какой-то шабаш и промискуитет. А выхлоп - очередные умные колонки и очки. Ну, и плюс генерация слопа на дичайших объёмах.
Средний
