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 достаточно большой для часто используемых ветвей, но и не слишком, чтобы устаревший код не проникал. И не забудь проверить размер диффа перед запуском основной модели – это сэкономит время ожидания в очереди. Удачи в кодировании!