Dev Easy Notes

Итак, я обещал истории своих проебов за прошлый год. Решил так, разделю истории на разные посты и пойдем по нарастающей, т.е от слабого проеба к тяжелому.

Первая история, это история о потерянном времени. Вероятнее всего вы заметили, что за последние пару лет у нас бум в области LLM. Чуть ли не каждую неделю выходит новая модель и уже проще найти гетеросексуальность у разработчиков npm, чем компанию, которая их не использует.

На фоне всего этого возникла такая идея. На CI у нас переодически падают пайплайны, и нет никакой статистики по причине падания. Где-то памяти не хватило, где-то тесты упали, где-то компиляция не прошла и еще куча всяких причин. Сам Gitlab ведет себя как уставший уролог, его особо не парит почему у тебя там что-то упало.

Поэтому мы посидели, подумали, а что если во время падения пайплайна, отправлять логи в нашу LLM? Она будет класcифицировать проблему по логам, а также выдавать совет разрабу, что делать с упавшей Job. Ну чтобы и разрабам не пришлось лишний раз в логи заходить, да и у нас более подробная статистика будет.

Почему сразу не пойти в API OpenAI? Ну в крупной компании безопастники могут прописать с вертухи за такое. Задача была интересна исключительно по тому, что мне хотелось руками потрогать LLM. Ресурсов у нас было мало, а мозгов еще меньше, поэтому мы решили взять самую мелкую модель из тех, что есть в open source. На тот момент это была Gemma-2b от гугла.

Разумеется сервис решили делать на Python. Я взял Fast api, чтобы быстро накидать сервис и либу от Hugging face для работы с моделями. С либами все шло довольно быстро. Однако большую часть времени я потратил на косплей админа линукса и на возьню с poetry (npm мира python). Да пока еще не было системы сборки, которая бы меня не расстроила(

Иии эта фигня вообще не взлетела. Я потратил довольно много времени: на разворачивание сервиса, на интеграцию модели, на администирование linux, на подбор адекватного промта, который хотя бы иногда советовал что-то адекватное. В результате я получил только опыт и мудрость суть которой – мелкие модели работают крайне паршиво для таких задач.

Дальше расскажу как бы я делал такую штуку сейчас, набив шишки.

👍25😁8❤4👏2🤡1

www.tgoop.com/dev_easy_notes/372

2.97K viewsedited  Feb 13 at 07:03

Итак, я обещал истории своих проебов за прошлый год. Решил так, разделю истории на разные посты и пойдем по нарастающей, т.е от слабого проеба к тяжелому.

Первая история, это история о потерянном времени. Вероятнее всего вы заметили, что за последние пару лет у нас бум в области LLM. Чуть ли не каждую неделю выходит новая модель и уже проще найти гетеросексуальность у разработчиков npm, чем компанию, которая их не использует.

На фоне всего этого возникла такая идея. На CI у нас переодически падают пайплайны, и нет никакой статистики по причине падания. Где-то памяти не хватило, где-то тесты упали, где-то компиляция не прошла и еще куча всяких причин. Сам Gitlab ведет себя как уставший уролог, его особо не парит почему у тебя там что-то упало.

Поэтому мы посидели, подумали, а что если во время падения пайплайна, отправлять логи в нашу LLM? Она будет класcифицировать проблему по логам, а также выдавать совет разрабу, что делать с упавшей Job. Ну чтобы и разрабам не пришлось лишний раз в логи заходить, да и у нас более подробная статистика будет.

Почему сразу не пойти в API OpenAI? Ну в крупной компании безопастники могут прописать с вертухи за такое. Задача была интересна исключительно по тому, что мне хотелось руками потрогать LLM. Ресурсов у нас было мало, а мозгов еще меньше, поэтому мы решили взять самую мелкую модель из тех, что есть в open source. На тот момент это была Gemma-2b от гугла.

Разумеется сервис решили делать на Python. Я взял Fast api, чтобы быстро накидать сервис и либу от Hugging face для работы с моделями. С либами все шло довольно быстро. Однако большую часть времени я потратил на косплей админа линукса и на возьню с poetry (npm мира python). Да пока еще не было системы сборки, которая бы меня не расстроила(

Иии эта фигня вообще не взлетела. Я потратил довольно много времени: на разворачивание сервиса, на интеграцию модели, на администирование linux, на подбор адекватного промта, который хотя бы иногда советовал что-то адекватное. В результате я получил только опыт и мудрость суть которой – мелкие модели работают крайне паршиво для таких задач.

Дальше расскажу как бы я делал такую штуку сейчас, набив шишки.

BY Dev Easy Notes