Post #81

OpenAI за долгое время наконец опубликовали статью: LLM Critics Help Catch LLM Bugs. Идея тянется еще с давних пор: давайте сделаем LLM, которая будет находить слабые места и ошибки при генерации другой LLM. В этом направлении мне очень нравится работа Let’s Verify Step by Step, где авторы учили модель численно оценивать каждый шаг модели-генератора на задачах математики: как только был сделан неправильный переход, LLM-критик давала низкую оценку. Более того, если у нас есть подобная модель, мы можем объединять ее с алгоритмами по типу параллельного поиска или Monte Carlo Tree Search, то есть делать поиск по потенциально полезным состояниям и выбирать наиболее перспективные (как это было сделано в свое время для алгоритмов игры в шахматы и го). Эффективность этого значительно выше, чем у обычной генерации, что понятно: вместо одного продолжения мы генерируем целое множество. Это своего рода дополнительная ручка для размена вычислительных ресурсов на качество. В этой же работе критик учится давать не численный, а текстовый фидбек для задач написания кода, таким образом генератор получает больше сигнала для последующих действий. Особенно много внимания уделяется совместной работе человека и модели для еще более качественной разметки: в этой связке человек + AI добивается наилучших результатов, но мы ведь все и так это давно знали? 🙃 В статье также много деталей по сбору данных и различным методикам Human Inserted Bugs и Human Detected Bugs – стоит почитать в общем. Еще авторы упоминают, что в RLHF брали PPO; видимо, OpenAI – единственная компания, которая продолжает его использовать, остальные уже съехали на DPO/KTO/you name it. Из интересных моментов хочется рассказать про способ инференса CriticGPT Force Sampling Beam Search (FSBS). Очевидно, мы хотим, чтобы модель находила как можно больше багов в примерах (назовем это recall). Оптимизируя эту метрику, LLM будет стремиться генерировать все больше и больше замечаний, среди которых будут и галлюцинации (ложные срабатывания), то есть precision будет низким. Если в задаче классификации мы можем двигать пороги алгоритма, выбирая оптимальную для нас точку, то с генерацией текста в данной постановке дела сложнее. FSBS позволяет как-то решать эту проблему: CriticGPT принимает на вход пару (вопрос-ответ) и в каком-то месте может дать фидбек в определенном markdown-формате, начинающемся с трех кавычек. С помощью constrained generation мы можем заставить модель генерировать такой фидбек (highlight) в разных местах. Constrained generation в данном контексте означает, что мы вручную ставим ```, и далее LLM из-за формата обучения думает, что дальше должна последовать критика, и начинает ее генерировать. Причем генерировать мы можем множество различных вариантов параллельно (после такой операции у авторов получалось 28 штук), в итоге имея целый список потенциальных ответов от критика. Наилучший мы выбираем по формуле rm_score + LENGTH_MODIFIER * num_highlights, на этом этапе и происходит контроль precision/recall tradeoff. Подробно этот шаг описан в секции 7.1. Rm_score - оценка Reward модели, LENGTH_MODIFIER - гиперпараметр, контролирующий влияние кол-во хайлайтов.