Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 12
А какой контекст у моделей на ревью? Есть что то кроме дифа, и как она его получает, как он ей передается?
К слову сейчас агенты могут по дифу найти всю необходимую информацию по проекту. Так что то, какой кодинг агент используется, не менее важно, чем модель.
Если это просто послать по апишке модели в облако диф + RAG - это уже пастген,
Помимо diff, как я писал в статье, я использовал RAG. Это позволяло моделям при необходимости получать дополнительный контекст из файлов репозитория и анализировать не только изменения в PR, но и связанные части кодовой базы
Было было интересно почитать, как именно у вас устроен rag? Это некий grep по файлам + чтение файлов, или особый способ семантического поиска по символам, как например работает в vscode #functionName или @someVariable?
Спасибо за вопрос, на самом деле всё устроено немного сложнее, чем просто grep по файлам.
В моём случае RAG реализован через комбинацию локальных эмбеддингов, векторной базы данных и алгоритма BM25. Если кратко описать процесс:
При первом запуске инструмент читает файлы репозитория, разбивает их на фрагменты и строит для них векторные представления (embeddings).
Эти данные индексируются и кешируются, чтобы при последующих запусках не перегружать ПК или сервер повторной обработкой всей кодовой базы.
Когда модели нужен дополнительный контекст, выполняется поиск по индексу: используется комбинация семантического поиска по эмбеддингам и BM25, чтобы находить наиболее релевантные куски кода.
Найденные фрагменты затем передаются модели как дополнительный контекст для анализа PR.
По сути это гибридный поиск: частично семантический, частично текстовый, чтобы лучше находить нужные участки кода.
Если честно, вся реализация получилась довольно объёмной, и, пожалуй, это тема для отдельной статьи, где можно подробно разобрать архитектуру RAG в проекте и все нюансы его работы.
хорошо, что поставили эксперимент на реальных PR и ввели в оценку человеческий acceptance rate — это сильно ближе к практике, чем просто «модель нашла N багов».Было бы интересно увидеть продолжение: пробовали ли вы мерить влияние этих моделей на реальное время ревью (до/после) и на количество багфиксов после мержа, чтобы понять, где отдача от LLM‑ревью максимальна?
Спасибо за интересный вопрос. На практике я действительно ежедневно использую свой инструмент для этих целей на работе, и по наблюдениям количество багов, которые доходят до этапа ревью или продакшена, снизилось примерно в 1.5-2 раза.
Пока это скорее практическое наблюдение, а не формализованная метрика - я не проводил отдельного замера времени ревью «до/после» или количества багфиксов после мержа. Но идея очень интересная: можно попробовать сделать более системный эксперимент и замерить такие показатели.
Спасибо за идею - это действительно может стать хорошим продолжением статьи)
Модель находит реальные проблемы в коде
Как вы это определяете? Если модель находит только одну проблему, это тоже засчитывается? Хотя может на самом деле проблем может быть несколько и модель их не увидела.
Например, у меня одна модель указала 9 проблем в коде, а вторая - 27. Если бы я использовал только первую модель, то считал бы, что модель сделала хорошее ревью.
Хороший вопрос. Я не оценивал модели только по количеству найденных проблем, потому что это действительно может искажать результат. Если модель нашла одну проблему, это само по себе не означает, что ревью было качественным.
Поэтому в статье используется несколько метрик: accuracy, depth, hallucination, practical fixes и human acceptance rate. Я смотрел не только на количество комментариев, но и на то, насколько они реальны, аргументированы и полезны разработчику.
Например, модель может написать 27 комментариев, но если половина из них - поверхностные замечания или ложные срабатывания, то такое ревью не обязательно будет лучше, чем 9 более точных и полезных комментариев.
Поэтому итоговая оценка складывается из качества замечаний, их применимости и вероятности того, что разработчик действительно воспользуется рекомендациями.
Интересно было бы посмотреть сравнение ещё этих:
Glm5
Qwen3 Coder Next
Kimi2.5
Спасибо за идею, список действительно интересный.
GLM-5, Qwen3 Coder Next и Kimi 2.5 сейчас выглядят довольно перспективно для задач анализа кода. Я пока не успел протестировать их в рамках этого эксперимента, но это хороший кандидат для следующего сравнения моделей.
Думаю попробовать провести ещё один эксперимент и добавить туда больше моделей, чтобы посмотреть, как они ведут себя на реальных Pull Request и насколько отличаются по глубине анализа и качеству предложенных исправлений.
Спасибо за предложение - обязательно возьму их в список для следующей статьи)
тут интереснее почему v3.1 а не v3.2, который на голову лучше в том числе в колонне, но такое ощущение что продается в жутких квантах через ollama. Я бы предположил что у вас давнее тестирование, но новый qwen то присутствует. А уж если сравните с новеньким 27b по своей методике для релевантности - это прям отдельное спасибо.
Ollama предоставляет удобный способ работать
Вы серьёзно? Чем конкретно удобный? Может хватит уже из каждого утюга форсить этот комбайн, выросший из частного и забагованного форка llamacpp?
С какой точностью квантования работают модели их облачных провайдеров? У Ollama даже с локальными моделями по этой части есть проблемы, и что-то мне подсказывает, в облаке ничуть не лучше. Я бы не стал к этому цепляться, если бы в статье не было сравнения моделей, но оно есть, а без такой информации любое тестирование моделей имеет мало смысла, просто потому, что Qwen3.5-397B-A17B BF16 ≠ Qwen3.5-397B-A17B IQ1_S
Когда стоит использовать Ollama для code review? если проект содержит чувствительный код или ограничения NDA;
При локальном запуске - допустим. Не лучшее решение, поскольку llamacpp во всём будет лучше, но допустим. А В ОБЛАКЕ!? У вас же вся статья про ОБЛАЧНЫЙ сервис от Ollama! От заголовка до последней крупицы контента... Вы как к такому выводу вообще пришли!?
Где можно почитать про провайдеров, которых задействует Ollama? Про политику сбора данных у этих провайдера? Сами то они пишут, "мы не собираем данные, мамой клянусь", а провайдер? Я очень сомневаюсь, что у Ollama есть свои собственные мощности для массового инференса крупных моделей, скорее всего они работают как посредник. И даже если допустить, что они не являются посредником, какие у вас могут быть причины доверять Ollama Cloud свои данные ПОД NDA?
Чем облачная часть этого поделия лучше, чем старый добрый OpenRouter? Хочешь, пользуйся через API со своего фронтенда, хочешь на сайте. Там ещё есть огромный плюс, что ты платишь за токены, а не за подписку. И в USDT оплату принимают. И ВСЮ информацию предоставляют, какая только у них есть. Это, конечно, не повод пользоваться ими из под NDA, я думаю, вас за такое любой юрист нахлобучит. Но OpenRouter по крайней мере сразу говорят: вот этот провайдер декларирует отсутствие сбора данных, вот тот - как минимум хранит их 30 дней, а вооот этот даже обучает свои модели на ваших данных. И вы сами можете решить, насколько это согласуется с уровнем чувствительности ваших данных, в случаях, когда прямых обязательств о неразглашении нет. И с точностью тоже проблем нет - открыто и явно сообщают, что вот у этого провайдера вот эта конкретная модель запущена с точностью FP8, вот у этого INT4, а этот полновесную запускает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облачные модели Ollama в задачах code review — честное сравнение на примерах