Спасибо за дополнение к статье! Для меня это с первую очередь оказалась удобная "образохранилка" с разграничением доступов для разных клиентов, взамен тому, что предлагает Gitea.
Я не проверял, но как выше написал, я не думаю, что в раннере гитхаба можно запустить мощную модель, которая сможет более-менее хорошо обработать большой diff.
ИИ анализирует diff и оставляет комментарии по коду
Улетает diff, а также название и описание PR. На данный момент это всё. Как отвечал выше, в будущем планирую реализовать передачу в контекст прошлых комментариев при дополнении PR'а, чтобы ответ не повторялся.
используются ли RAGи
RAG не используется, но подумаю над этим.
Как подбирались промпты, и какие они сейчас?
Промпты сейчас не в лучшем виде, они есть в репозитории. Пока, что они на русском и с зашитым ответом на русском, впоследствии реализую систему кастомных промптов и расширю имеющиеся.
Есть ли ограничения по языкам программирования?
Всё ограничивается используемым ИИ-провайдером и моделью. Если подключите локальную дообученную для питона, то будет не лучшая идея давать ей условную Java.
Локальный запуск LLM для ревью прямо внутри раннера гитхаба
Сомневаюсь, что у раннера гитхаба хватит для этого мощностей, но идея запускать проект в воркфлоу тоже есть, с подключением к ИИ на стороне.
Не использовал SonarQube, но как я понимаю он для статического анализа кода.
Сомневаюсь, что он может распознать, например, неэффективный код, с чем вполне может справится ИИ. А для статических проверок вполне хватает pre-commit.
Про RSGI не могу ничего сказать. Он ещё очень молод, поэтому и скуден. Интересно будет наблюдать за его развитием, как со стороны применения в Python, так и в самом Rust
А вот этот бенчмарк говорит, что uWSGI самый медленный (впрочем, насколько можно верить бенчмарку девятилетней давности, не знаю — но мне до сих пор интересно, что не так с этим бенчмарком)
RSGI не применяется в джанге, это отмечено в статье. Granian работает по WSGI, однако, даже в работе синхронно он обеспечивает производительность сопоставимую с ASGI. После реверс прокси идёт именно веб-сервер, у него есть свои задержки выполнения, это сравнение также есть в статье. Если брать значения "в лоб", у granian в шесть раз лучше показать задержки выполнения, а затем уже да, идёт джанга. И вот этого достаточно, чтобы повысить отзывчивость сайта. Преимущества в RPS проявят себя со временем при росте посещаемости. Gunicorn'а у меня никогда не было, я сразу использовал uWSGI и заменил его на Granian, вместо обвзяки Django Cannels + uvicorn.
У нас уже есть, старый, кривой, косой бот в чате.... Ребята его "очень любят", за то, что материться не даёт))
Спасибо за дополнение к статье! Для меня это с первую очередь оказалась удобная "образохранилка" с разграничением доступов для разных клиентов, взамен тому, что предлагает Gitea.
Интересный конкурс, но сдаётся мне, что, как и в прошлый раз, старания настоящих разработчиков будут задвинуты и победит очередной "вайб-кодер"...
Не критика, но замечание. Сдаётся мне, что вот это:
Можно солидно так оптимизировать, вынеся определение команды в небольшую функцию.
Подумаю над идеей, спасибо)
Полностью согласен, но имеем, что имеем.
Тогда уже было нормально, сейчас стало лучше, развивается и отлично работает)
Как теперь это развидеть?)
Я тестировал пока только на трёх провайдерах (которые реализованы в проекте): OpenAI, GigaChat от Сбера и YandexGPT.
От OpenAI использую модель
gpt-4.1-mini, она достаточно дешева и выдаёт достойные комментарии. Их можно посмотреть в закрытых PR репозитория.GigaChat на стандартной модели выдаёт крайне посредственные и ограниченные комментарии.
YandexGPT тестировал на стандартной модели
yandexgpt. Результат не совсем дотягивает до OpenAI, но вполне достойный.Думаю, что подбирать модели буду в последствии, когда реализую других провайдеров и наведу порядок в промптах.
Да, поддерживается. У меня развёрнута своя Gitea, и все тесты проводил на ней, а потом уже на Github)
Я не видел)
Я не проверял, но как выше написал, я не думаю, что в раннере гитхаба можно запустить мощную модель, которая сможет более-менее хорошо обработать большой diff.
Ответ есть в статье:
Улетает diff, а также название и описание PR. На данный момент это всё. Как отвечал выше, в будущем планирую реализовать передачу в контекст прошлых комментариев при дополнении PR'а, чтобы ответ не повторялся.
RAG не используется, но подумаю над этим.
Промпты сейчас не в лучшем виде, они есть в репозитории. Пока, что они на русском и с зашитым ответом на русском, впоследствии реализую систему кастомных промптов и расширю имеющиеся.
Всё ограничивается используемым ИИ-провайдером и моделью. Если подключите локальную дообученную для питона, то будет не лучшая идея давать ей условную Java.
Сомневаюсь, что у раннера гитхаба хватит для этого мощностей, но идея запускать проект в воркфлоу тоже есть, с подключением к ИИ на стороне.
Только в контексте diff'а открытого PR. Сохранение истории, а именно учёт предыдущих комментариев тоже в планах реализовать.
Не использовал SonarQube, но как я понимаю он для статического анализа кода.
Сомневаюсь, что он может распознать, например, неэффективный код, с чем вполне может справится ИИ. А для статических проверок вполне хватает pre-commit.
Перманентно)
Как и весь граниан по большому счёту =)
Granian также можно вызывать из кода:
https://github.com/emmett-framework/granian?tab=readme-ov-file#embedding-granian-in-your-project
Про RSGI не могу ничего сказать. Он ещё очень молод, поэтому и скуден. Интересно будет наблюдать за его развитием, как со стороны применения в Python, так и в самом Rust
https://github.com/zauberzeug/nicegui/discussions/3039
RSGI не применяется в джанге, это отмечено в статье. Granian работает по WSGI, однако, даже в работе синхронно он обеспечивает производительность сопоставимую с ASGI. После реверс прокси идёт именно веб-сервер, у него есть свои задержки выполнения, это сравнение также есть в статье. Если брать значения "в лоб", у granian в шесть раз лучше показать задержки выполнения, а затем уже да, идёт джанга. И вот этого достаточно, чтобы повысить отзывчивость сайта. Преимущества в RPS проявят себя со временем при росте посещаемости. Gunicorn'а у меня никогда не было, я сразу использовал uWSGI и заменил его на Granian, вместо обвзяки Django Cannels + uvicorn.
Думаю, что опробую его в связке с FastAPI и изучу тему тестирования нагрузочного, чтобы примерно представлять производительность