Ap11e & Turtlex
Turtlex
Привет, тут одна идея крутится в голове – разрабатываю AI-powered code reviewer, который не зависит от языка программирования и может работать прямо в CI-пайплайнах, предлагая улучшения на ходу. Представь, как будто умнее, чем линтер, и он учится на основе репозитория. Ты вообще в такие вещи когда-нибудь лезла?
Ap11e
Звучит как отличный проект – что-то вроде умного, обучающегося линтера, который живет прямо в CI. Я немного экспериментировала с линтингом на основе моделей, в основном дообучала трансформеры на корпусах кода. Самое сложное – сделать его осознающим репозиторий без переобучения под конкретный код. Ты думал, как туда добавить историю коммитов или какой-то контекст? И не забудь про задержку инференса, если хочешь, чтобы он остался в CI — может, стоит обернуть его в какой-нибудь легковесный адаптер, который вызывает модель, размещенную где-то на сервере. Очень интересно послушать, какую архитектуру ты придумываешь.
Turtlex
Конечно, вот набросок. Бери последние N коммитов, разбей дельты на куски по 200 символов, и сгенерируй для каждого отпечаток. Сохраняй эти отпечатки и исходный текст в локальном векторном индексе – FAISS или Milvus – чтобы потом искать по косинусной метрике, учитывая текст коммита и измененные строки. Когда PR будет принят, запускай облегченную обертку линтера: подавай новую дельту вместе с k самых релевантных фрагментов контекста в дистиллированную версию GPT-4 Turbo или более компактную CodeLlama, чтобы она выдала предложение в стиле патча. Если задержки критичны – держи модель оффлайн, иначе используй общий эндпоинт с очередью по проектам, чтобы не тормозила CI сборка. Главное – кеш контекста: обновляй его только при слиянии, чтобы не переобучать модель на всем репозитории, а просто добавлять новые векторы. Это поможет избежать переобучения, но при этом даст модели достаточно "истории" для работы.
Ap11e
Трубопровод выглядит надежным — хеширование фрагментов помогает держать индекс легковесным, а поиск по косинусам должен выдавать нужный контекст. Только убедись, что нормализуешь изменения перед хешированием, иначе даже незначительные изменения в пробелах могут сломать сопоставление отпечатков. И небольшая проверка адекватности полученных топ-k перед тем, как подавать их модели, поможет избежать лишнего шума в контексте. Если будет лаг, попробуй закэшировать эмбеддинги модели и запускай языковую модель только на финальном этапе выбора предложений. Отличная настройка!
Turtlex
Да, нормализация пробелов – это классическая подстава. Может, стоит убрать табы и сократить множественные пробелы перед хешированием, чтобы отпечатки пальцев были стабильными. И быстрая контрольная сумма для топ-k векторов перед подачей в языковую модель поможет выявить выбросы; нет смысла тратить вычислительные ресурсы GPU на мусор. Если задержка все равно большая, кэширование векторов внедрений – неплохой компромисс – запускай маленькую модель только на финальном проходе. Так CI запустится быстрее, но при этом ИИ все равно сможет понять контекст изменений.
Ap11e
Отлично поработал с отступами, это сильно уменьшит количество пересчетов хешей. Защита контрольной суммы — отличная идея, не даст ЛМ пережевывать мусор. Для кэша вложений просто добавь TTL или версию, чтобы понимать, когда фрагмент устарел. Если начнешь упираться в лимиты GPU, попробуй использовать небольшой трансформер для финального прохода, а большой включай только для действительно сложных отличий. CI останется быстрым, но при этом ты получишь точные и контекстуально-осмысленные подсказки.
Turtlex
Да, тут ключом к решению являются TTL. Обрабатывай каждый блок как вызов к закэшированному API, чтобы не пересобирать один и тот же устаревший код при каждом запуске. И переключаться на модель с миллиардом параметров только при действительно серьёзных изменениях – хороший способ, чтобы очередь не затормаживалась. Я набросаю прототип кэша с простым LRU и версионным штампом; если хеш коммита репозитория изменится, блок автоматически станет недействительным. Это должно держать CI-пайплайн быстрым и предложения оставаться информативными.
Ap11e
Эта комбинация LRU и хеширования поможет держать кэш в порядке, только убедись, что TTL достаточно большой для часто используемых ветвей, но и не слишком, чтобы устаревший код не проникал. И не забудь проверить размер диффа перед запуском основной модели – это сэкономит время ожидания в очереди. Удачи в кодировании!
Turtlex
Звучит отлично—я выставлю TTL на срок активности ветки и добавлю простой фильтр по количеству байт, чтобы пропускать тяжёлую модель, если разница окажется меньше нескольких сотен строк. Рад, что всё наладилось.
Ap11e
Отлично, это должно держать пайплайн быстрым, но при этом обеспечит глубину, когда это действительно важно. Напиши, как себя кэш ведёт при большом количестве pull request’ов — буду рада помочь подправить логику выгрузки, если понадобится. Удачи!