Dev Easy Notes

Итак, как бы я сейчас делал задачу с классификацией ошибок на МР.

1️⃣ Я бы сразу пошел выбивать ресурсы, чтобы сразу развернуть модель побольше. Большая Llama от Meta на 70B или недавно вышедший deep-seek, прекрасные варианты. Если же компания в которой я работаю, такого не позволяет сделать, договорился бы об отправке логов в Open AI или тот же Deep Seek. В таком случае правда пришлось бы очищать данные, чтобы что-то лишнее не утекло.

2️⃣ Сделал бы другую архитектуру. У нас было сделано так, что мы собираем данные в одной из Job на CI и отправляем в наш сервис. И вот так лучше не делать, лучше не вмешиваться интеграциями внутрь пайплайна. Как нужно было сделать: либо завязаться на вебхуки Gitlab, чтобы он сам нас дергал при падении. Если же вебхуки отключены, раз в условные 10 минут собирать все МРы через Gitlab API и анализировать пачкой по очереди.

3️⃣ Не парился бы с самописным сервисом. Сейчас я бы взял бы какой-нибудь n8n и накидал прототип на нем. Уже после, если бы идея себя оправдала, задумался бы о написании своего сервиса. Развернуть n8n у себя это день если есть готовая инфра, или неделя если ее нужно еще поднимать. Вы примерно сколько бы и потратили на деплой своего сервиса.

И главный проеб! Я не придумал никаких метрик в начале, чтобы понять, а решение вообще стоит того? Сейчас бы я начал со сбора хоть каких-то метрик, хотя бы считать реакции на коментах к МРу.

www.tgoop.com/dev_easy_notes/373

3.2K viewsFeb 14 at 08:30

Итак, как бы я сейчас делал задачу с классификацией ошибок на МР.

1️⃣ Я бы сразу пошел выбивать ресурсы, чтобы сразу развернуть модель побольше. Большая Llama от Meta на 70B или недавно вышедший deep-seek, прекрасные варианты. Если же компания в которой я работаю, такого не позволяет сделать, договорился бы об отправке логов в Open AI или тот же Deep Seek. В таком случае правда пришлось бы очищать данные, чтобы что-то лишнее не утекло.

2️⃣ Сделал бы другую архитектуру. У нас было сделано так, что мы собираем данные в одной из Job на CI и отправляем в наш сервис. И вот так лучше не делать, лучше не вмешиваться интеграциями внутрь пайплайна. Как нужно было сделать: либо завязаться на вебхуки Gitlab, чтобы он сам нас дергал при падении. Если же вебхуки отключены, раз в условные 10 минут собирать все МРы через Gitlab API и анализировать пачкой по очереди.

3️⃣ Не парился бы с самописным сервисом. Сейчас я бы взял бы какой-нибудь n8n и накидал прототип на нем. Уже после, если бы идея себя оправдала, задумался бы о написании своего сервиса. Развернуть n8n у себя это день если есть готовая инфра, или неделя если ее нужно еще поднимать. Вы примерно сколько бы и потратили на деплой своего сервиса.

И главный проеб! Я не придумал никаких метрик в начале, чтобы понять, а решение вообще стоит того? Сейчас бы я начал со сбора хоть каких-то метрик, хотя бы считать реакции на коментах к МРу.

BY Dev Easy Notes