Forwarded from Alexander Sukovatitcin
О, пост для прикрепления к заявлению о депортации - смело
😁20🤡16 3
Наблюдаю интересную метаморфозу спам ботов. Раньше это были шлюхоботы, которые были с аватаркой красивой девочки и зазывали тебя весело провести вечер. Сейчас же почти на каждый пост приходят эти "книголюбы", которых хлебом не корми дай поделится впечатлениями о прочитанном.
Вам как моей аудитории вероятно должно быть лестно. Ведь теперь они играют не на базовых потребностях, а на чем-то высоком. Но заебали они конечно знатно, наверное уже нужно какой-то фильтр настроить.
Вам как моей аудитории вероятно должно быть лестно. Ведь теперь они играют не на базовых потребностях, а на чем-то высоком. Но заебали они конечно знатно, наверное уже нужно какой-то фильтр настроить.
🤡22 10
Что такое мониторинг?
У нас есть приложение и нужно как-то проверить, а оно вообще там живое нет? Желательно словить момент, когда оно не живое до того как это сделают пользователи. Народная мудрость: быстро поднятое не считается упавшим – тут работает прекрасно.
Если у нас один инстанс на бэке то никакой мониторинг не нужен, можно и по логам быстро понять, что что-то не так. Однако если у тебя сотни тысяч клиентов, а на бэке у тебя 10-ки разных сервисов по 5-6 инстансов каждый без грамотного мониторинга ты быстро дашь ебу.
Есть два основных типа мониторинга: pull и push.
Мобилки да и вообще весь фронтенд работает по типу push. Это когда мы агрегируем метрики локально и затем переодически отправляем их на бэк. Если же сети нет, ждем пока появится и отправляем позже.
Бэк почти всегда работает по типу pull. Это когда наше приложение также собирает метрики в памяти, затем какая-то сторонняя система сама дергает наш бэк и мы отдаем ей то, что насобирали.
Как это выглядит в коде. В мобилке и фронте чаще всего используют проприетарные SDK: типа Firebase Crashlytics, Apple MetricKit, Setry, Яндекс Метрика либо вообще пишут что-то свое. SDK в свою очередь отправляет метрику в какую-то TSDB (time series database).
На бэке почти всегда используется стандарт OpenTelemetry. Для любого языка есть SDK в котором ты объявляешь переменные (их три типа) и далее просто используешь их в коде. Затем ты делаешь какой-то endpoint типа "/metrics" в котором ты, используя тот же SDK, генеришь ответ в специальном формате. После уже какой-нибудь Prometheus дергает этот endpoint и уже сохраняет метрики в TSDB.
Далее мы уже идем в интерфейс который работает с TSDB и создаем какие-то алерты, строим графики, перегоняем данные в другие БД короче развлекаемся как хотим.
У нас есть приложение и нужно как-то проверить, а оно вообще там живое нет? Желательно словить момент, когда оно не живое до того как это сделают пользователи. Народная мудрость: быстро поднятое не считается упавшим – тут работает прекрасно.
Если у нас один инстанс на бэке то никакой мониторинг не нужен, можно и по логам быстро понять, что что-то не так. Однако если у тебя сотни тысяч клиентов, а на бэке у тебя 10-ки разных сервисов по 5-6 инстансов каждый без грамотного мониторинга ты быстро дашь ебу.
Есть два основных типа мониторинга: pull и push.
Мобилки да и вообще весь фронтенд работает по типу push. Это когда мы агрегируем метрики локально и затем переодически отправляем их на бэк. Если же сети нет, ждем пока появится и отправляем позже.
Бэк почти всегда работает по типу pull. Это когда наше приложение также собирает метрики в памяти, затем какая-то сторонняя система сама дергает наш бэк и мы отдаем ей то, что насобирали.
Как это выглядит в коде. В мобилке и фронте чаще всего используют проприетарные SDK: типа Firebase Crashlytics, Apple MetricKit, Setry, Яндекс Метрика либо вообще пишут что-то свое. SDK в свою очередь отправляет метрику в какую-то TSDB (time series database).
На бэке почти всегда используется стандарт OpenTelemetry. Для любого языка есть SDK в котором ты объявляешь переменные (их три типа) и далее просто используешь их в коде. Затем ты делаешь какой-то endpoint типа "/metrics" в котором ты, используя тот же SDK, генеришь ответ в специальном формате. После уже какой-нибудь Prometheus дергает этот endpoint и уже сохраняет метрики в TSDB.
Далее мы уже идем в интерфейс который работает с TSDB и создаем какие-то алерты, строим графики, перегоняем данные в другие БД короче развлекаемся как хотим.
🤡29🔥14❤8
Итак, frostpunk 2.
Год назад делал прост про первый frostpunk. Первую часть я прям полюбил, проходил ее раз 5 наверное. Под конец прошлого года вторую часть наконец-то портировали на PS5 и я смог ее заценить. И честно говоря я был разочарован, она полностью потеряла ту атмосферу за которую я полюбил первую часть.
Вторая стала масштабнее, теперь ты не возводишь отдельные здания, а целые районы. Поселение теперь не одно, соответственно тебе приходится налаживать логистику между городами. Система политики усложнилась, теперь не ты принимаешь решение которое считаешь нужным, тебе это решение еще нужно продать парламенту, в котором есть разные фракции и кто-то будет за, кто-то против. Прикиньте при принятии закона кто-то может быть против, эх ну понавыдумывают же!
Геймплейно она стала разнообразнее, шире дерево технологий, больше типов зданий короче всего больше, но она потеряла ламповость. В первой части было маленькое поселение, где ты буквально мог на жителя тыкнуть и узнать что-то про него. Тебя не отпускало вот это ощущение, что вот этот городок это последнее убежище человечества и если вы не выживаете, не выживает никто. Вторая часть это потеряла, сложно словить это ощущение когда у тебя 3 города, и каждый уже чуть ли не мегаполис.
Это как знаете, устраиваешься в галеру, которая вот только только начала работать, где все говорят, что мы тут друганы, никого не обидим. И первое время там и правда круто и лампово. Через несколько лет компания разрастается и начинается какая-то дичь. Вот такая история и с frostpunk.
Короче я ее в итоге забросил, из-за ублюдской оптимизации. На 5-й плойке она под конец игры она стала страшно лагать, из-за количества зданий. При этом там не вау графика и видимо разработчики сильно торопились с портом.
Год назад делал прост про первый frostpunk. Первую часть я прям полюбил, проходил ее раз 5 наверное. Под конец прошлого года вторую часть наконец-то портировали на PS5 и я смог ее заценить. И честно говоря я был разочарован, она полностью потеряла ту атмосферу за которую я полюбил первую часть.
Вторая стала масштабнее, теперь ты не возводишь отдельные здания, а целые районы. Поселение теперь не одно, соответственно тебе приходится налаживать логистику между городами. Система политики усложнилась, теперь не ты принимаешь решение которое считаешь нужным, тебе это решение еще нужно продать парламенту, в котором есть разные фракции и кто-то будет за, кто-то против. Прикиньте при принятии закона кто-то может быть против, эх ну понавыдумывают же!
Геймплейно она стала разнообразнее, шире дерево технологий, больше типов зданий короче всего больше, но она потеряла ламповость. В первой части было маленькое поселение, где ты буквально мог на жителя тыкнуть и узнать что-то про него. Тебя не отпускало вот это ощущение, что вот этот городок это последнее убежище человечества и если вы не выживаете, не выживает никто. Вторая часть это потеряла, сложно словить это ощущение когда у тебя 3 города, и каждый уже чуть ли не мегаполис.
Это как знаете, устраиваешься в галеру, которая вот только только начала работать, где все говорят, что мы тут друганы, никого не обидим. И первое время там и правда круто и лампово. Через несколько лет компания разрастается и начинается какая-то дичь. Вот такая история и с frostpunk.
Короче я ее в итоге забросил, из-за ублюдской оптимизации. На 5-й плойке она под конец игры она стала страшно лагать, из-за количества зданий. При этом там не вау графика и видимо разработчики сильно торопились с портом.
🤡46❤18🗿3 1
Аааакция, я возвращаю реакцию клоунов на пару часов, попробуй успеть!
51🤡185😁5🗿5🔥1
Dev Easy Notes
Аааакция, я возвращаю реакцию клоунов на пару часов, попробуй успеть!
Кто отписывается после такого тот гей
102🤡98 10🥰6😁3💩3❤1
Ну что, те кто хотел сделали каминг аут, поэтому давайте двигаться дальше.
Что такое RAG?
RAG (Retrieval Augmented Generation) – переводится букально как генерация с дополнением извлечением. Чего извлекается, дополняется и генерируется давайте раскидаем.
Самая дефолтная задача для RAG это сделать ИИ бота который например отвечает по документации вашего продукта. Базовая LLM очень хорошо умеет работать с текстом, выдавать суть генерить примеры и не огрызается. Однако есть проблема, LLM ничего не знает о нашем продукте. Есть два путя как решить эту проблему:
1. Дообучить модель
2. Взять вообще всю доку по нашему проекту и отправлять ее на каждый запрос
Как сказал бы солист группы Бредорс, шо то очень хорошо, шо это не то чтобы круто. В первом это просто прям дорого, во втором случае зависит от размеров доки, но даже если дока небольшая точность ответов скорее всего будет так себе. Поэтому на сцену выходит RAG.
Что если не отправлять нейронке не всю доку, а только релевантные страницы? И LLM будет отвечать точнее, и мы не потратим кучу токенов и деняк на дообучение. Как это сделать?
Берем нашу доку, режем на части, затем отправяем в embedder. Embedder – модель которая из текста нашей доки сделает числовые вектора, грубо говоря вектора смыслов. Далее эти вектора мы кладем в специальную векторную базу, которая умеет круто их индексировать.
Далее происходит следующее, мы получаем запрос от пользователя, преобразуем вопрос в вектора при помощи того же Embedder'а затем используя этот вектор запроса находим ближайшие вектора в нашей векторной базе. Так как речь идет именно о смысловых векторах, но вероятнее всего полученные вектора будут ближе к тому о чем спрашивает пользователь. Векторая база рядом с векторами также хранит и текст из которых этот вектор был получен, поэтому мы в итоге получаем части текста нашей доки – чанки.
Далее из текста запроса и чанков мы генерим промпт для LLM. При обновлении доки мы должны опять нарезать ее на части и отправить в Embedder, т.е проиндексировать короче. Таким образом убиваем двух зайцев и модель не нужно дообучать и токенов много не тратится.
Разумеется в теории все просто но на практике начинаются приколы: как подобрать Embedder, какую базу выбрать, какие параметры для базы подобрать, какую модель выбрать и еще куча всего. Также желательно иметь свой бенчмарк с запросами ответами чтобы от версии к версии проверять не ухудшилась ли выдача системы.
Что такое RAG?
RAG (Retrieval Augmented Generation) – переводится букально как генерация с дополнением извлечением. Чего извлекается, дополняется и генерируется давайте раскидаем.
Самая дефолтная задача для RAG это сделать ИИ бота который например отвечает по документации вашего продукта. Базовая LLM очень хорошо умеет работать с текстом, выдавать суть генерить примеры и не огрызается. Однако есть проблема, LLM ничего не знает о нашем продукте. Есть два путя как решить эту проблему:
1. Дообучить модель
2. Взять вообще всю доку по нашему проекту и отправлять ее на каждый запрос
Как сказал бы солист группы Бредорс, шо то очень хорошо, шо это не то чтобы круто. В первом это просто прям дорого, во втором случае зависит от размеров доки, но даже если дока небольшая точность ответов скорее всего будет так себе. Поэтому на сцену выходит RAG.
Что если не отправлять нейронке не всю доку, а только релевантные страницы? И LLM будет отвечать точнее, и мы не потратим кучу токенов и деняк на дообучение. Как это сделать?
Берем нашу доку, режем на части, затем отправяем в embedder. Embedder – модель которая из текста нашей доки сделает числовые вектора, грубо говоря вектора смыслов. Далее эти вектора мы кладем в специальную векторную базу, которая умеет круто их индексировать.
Далее происходит следующее, мы получаем запрос от пользователя, преобразуем вопрос в вектора при помощи того же Embedder'а затем используя этот вектор запроса находим ближайшие вектора в нашей векторной базе. Так как речь идет именно о смысловых векторах, но вероятнее всего полученные вектора будут ближе к тому о чем спрашивает пользователь. Векторая база рядом с векторами также хранит и текст из которых этот вектор был получен, поэтому мы в итоге получаем части текста нашей доки – чанки.
Далее из текста запроса и чанков мы генерим промпт для LLM. При обновлении доки мы должны опять нарезать ее на части и отправить в Embedder, т.е проиндексировать короче. Таким образом убиваем двух зайцев и модель не нужно дообучать и токенов много не тратится.
Разумеется в теории все просто но на практике начинаются приколы: как подобрать Embedder, какую базу выбрать, какие параметры для базы подобрать, какую модель выбрать и еще куча всего. Также желательно иметь свой бенчмарк с запросами ответами чтобы от версии к версии проверять не ухудшилась ли выдача системы.
🔥21❤3
Все же слышали что AI сейчас очень сильно меняет профессию разработчика, сейчас покажу как это происходит.
Раньше:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в БД получаем данные, делаем json отдаем клиенту
Сейчас:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в LLM получаем json, отдаем его клиенту
Раньше:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в БД получаем данные, делаем json отдаем клиенту
Сейчас:
– Фронтенд: идем в бэк, получаем json, рисуем списочки и красим кнопки
– Бэкенд: получаем запрос, идем в LLM получаем json, отдаем его клиенту
😁43❤1🥰1
Web1.0 Web2.0 Web3.0
В начале 2000-х интернет был в некотором смысле гораздо более децентрализованный. У многих был личный сайт/блог на какой-нибудь CMS или своем хостинге. Форумы были разбросаны по всему интернету, не было одной точки входа. Чтобы что-то найти, нужно было прям искать, эдакий аналог закрытого клуба. Если тебя не пригласили то ты скорее всего так и не узнаешь о существовании этого сайта/блога и т.д. Это был Web1.0.
Затем пришли соцсети, мессенджеры и крупные платформы. Все они централизовали интернет. Удобство всегда побеждает. Зачем тебе хостить свой блог и бороться с CMS, если ты можешь в две кнопки зарегаться в условном твитере и сразу получить большую аудиторию? Это Web2.0.
Ну и Web 3.0, который базируется на базе блокчейна. Никому не доверяемвсе пидорасы доверяем только коду и математике простых чисел. Web 3.0 должен был прийти на смену злым корпорациям! Но так и не стрельнул, по крайне мере пока. Потому как чаша весов на которой с одной стороны централизация, а с другой удобство никуда не делась. Насколько я знаю все еще нет платформы построенной на Web 3.0 и при этом, чтобы она была удобной для обычного пользователя, а не гика.
И вот я думаю, с этими лютыми блокировками вероятнее всего будет два исхода. Первый мы вернемся опять в Web1.0, я думаю у многих айтишных блогеров проскакивает мысль, что лучше уже сделать свой сайт или приложение, чем переходить в макс. Второй мы перейдем в Web 3.0, который по задумке можно заблокировать только если вообще уже все провода обрубить по стране. Этот вариант выглядит нереалистичным, с другой стороны сейчас даже бабушки научились с впн работать...
В начале 2000-х интернет был в некотором смысле гораздо более децентрализованный. У многих был личный сайт/блог на какой-нибудь CMS или своем хостинге. Форумы были разбросаны по всему интернету, не было одной точки входа. Чтобы что-то найти, нужно было прям искать, эдакий аналог закрытого клуба. Если тебя не пригласили то ты скорее всего так и не узнаешь о существовании этого сайта/блога и т.д. Это был Web1.0.
Затем пришли соцсети, мессенджеры и крупные платформы. Все они централизовали интернет. Удобство всегда побеждает. Зачем тебе хостить свой блог и бороться с CMS, если ты можешь в две кнопки зарегаться в условном твитере и сразу получить большую аудиторию? Это Web2.0.
Ну и Web 3.0, который базируется на базе блокчейна. Никому не доверяем
И вот я думаю, с этими лютыми блокировками вероятнее всего будет два исхода. Первый мы вернемся опять в Web1.0, я думаю у многих айтишных блогеров проскакивает мысль, что лучше уже сделать свой сайт или приложение, чем переходить в макс. Второй мы перейдем в Web 3.0, который по задумке можно заблокировать только если вообще уже все провода обрубить по стране. Этот вариант выглядит нереалистичным, с другой стороны сейчас даже бабушки научились с впн работать...
Forwarded from Стой под стрелой (Nikita Prokopov)
Шопился вчера в интернет-магазине, который ставил на колени мой старенький дохленький десятиядерный M4 Pro. Шутка ли — семь мегабайт джаваскрипта на каждой загрузке страницы.
Нам ведь обещали что? Загрузишь такую байду один раз, зато потом можно за час долететь. А на деле получается: открыл я новую вкладку — пошел нафиг. Нажал кнопку назад — пошел нафиг. Поискал по истории и достал страницу, на которой уже был — пошел нафиг. То есть я регулярно смотрел просто на белый экран по две-три секунды, пока весь этот ваш джаваскрипт распарсится и скомпилируется.
Еще и анимации эти ебучие, когда нельзя просто показать страницу, нужно ее аНиМиРоВаТь. Типа смотрите как все красиво из белого экрана выезжает как из тумана. Прикольно ровно один раз, а все остальные два часа и пару тысяч загрузок страниц оно проверяет твои нервы. Не, глаз дергается, эффект достигнут.
(Пользуясь случаем, Эплу тоже привет передайте. Захочешь выбрать нотбук — посмотри один и тот же тридцатисекундный мультик восемьдесят пять раз. Сука, я буквально скроллю мышкой быстрее, чем они свои анимации загружают. То есть на сайте Эпла я обычно просто по пустым экранам бегаю, где то темный фон, то светлый, а текст с картинками еще не загрузились и не анимировались)
Я не знаю, что может быть проще, чем написать интернет-магазин. Реально, самая типовая задача из типовых. ВЕСЬ стек сделан и годами заточен на то, чтобы блин этот ваш магазин летал на кнопочных телефонах Нокия, а вам для этого даже пальцем пошевелить не нужно было. Послал запрос в базу, база сделала селект по таблице из 1000, от силы, товаров с двумя-тремя фильтрами, шаблонизатор сложил три строки, энжинкс отдал картинки. Тут просто НЕЧЕМУ тормозить.
Но неет. У нас тЕхНоЛоГиИ. У нас пРоГрЕсс. У нас кОмФоРт рАзРаБоТчИкА. Тьфу на вас. ИИ, жги.
Нам ведь обещали что? Загрузишь такую байду один раз, зато потом можно за час долететь. А на деле получается: открыл я новую вкладку — пошел нафиг. Нажал кнопку назад — пошел нафиг. Поискал по истории и достал страницу, на которой уже был — пошел нафиг. То есть я регулярно смотрел просто на белый экран по две-три секунды, пока весь этот ваш джаваскрипт распарсится и скомпилируется.
Еще и анимации эти ебучие, когда нельзя просто показать страницу, нужно ее аНиМиРоВаТь. Типа смотрите как все красиво из белого экрана выезжает как из тумана. Прикольно ровно один раз, а все остальные два часа и пару тысяч загрузок страниц оно проверяет твои нервы. Не, глаз дергается, эффект достигнут.
(Пользуясь случаем, Эплу тоже привет передайте. Захочешь выбрать нотбук — посмотри один и тот же тридцатисекундный мультик восемьдесят пять раз. Сука, я буквально скроллю мышкой быстрее, чем они свои анимации загружают. То есть на сайте Эпла я обычно просто по пустым экранам бегаю, где то темный фон, то светлый, а текст с картинками еще не загрузились и не анимировались)
Я не знаю, что может быть проще, чем написать интернет-магазин. Реально, самая типовая задача из типовых. ВЕСЬ стек сделан и годами заточен на то, чтобы блин этот ваш магазин летал на кнопочных телефонах Нокия, а вам для этого даже пальцем пошевелить не нужно было. Послал запрос в базу, база сделала селект по таблице из 1000, от силы, товаров с двумя-тремя фильтрами, шаблонизатор сложил три строки, энжинкс отдал картинки. Тут просто НЕЧЕМУ тормозить.
Но неет. У нас тЕхНоЛоГиИ. У нас пРоГрЕсс. У нас кОмФоРт рАзРаБоТчИкА. Тьфу на вас. ИИ, жги.
Unix Way
Вы делаете какую-то CLI программу или скрипт, который(ая) например генерируетзалупу какой-то отчет по вашему коду. Далее этот отчет нужно отправить в какой-то рабочий чат. Как правильно сделать такую задачу?
Есть два путя. Первый это прикрутить отправку в чат в сам CLI, чтобы прога сама отправляла куда нужно. Второй это мы не выебываемся и делаем CLI который только генерит отчет, а отправку делаем другим скриптом.
Второй вариант это и есть Unix Way. Основные принципы которого звучат так:
- Делай одно – делай хорошо. Вот этот single responsibility ногами отсюда растет.
- Пиши программы, которые работают вместе. Не нужно делать программу которая делает все, лучше использовать выход одной программы как вход другой
- Работай с текстом. Текстовые потоки – универсальный интерфейс.
В реальности я чаще всего вижу ситуацию, когда пытаются делать один скрипт который делает все. Сам не без греха, и кучу вещей так делал.
С одной стороны это и правда удобнее, ведь сегодня тебе нужно отчет отправлять в чат, а завтра попросят в s3 сохранять. И прикручивать s3 это разбираться с sdk, добавлять зависимости, обрабатывать ошибки и вот это все. При этом просто прикрутить рядом s3cmd это дело 5 минут.
С другой, это может быть не так удобно. Например что если нужно отправлять уже в несколько чатов, тут уже unix way становится сложнее, ведь появится уже bash скрипт который вызывает твою программу, а потом еще каким-то циклом будет вызывать скрипт отправки. Можно было в одном скрипте исправит пару строчек и не пачкаться о bash.
Короче сложно, как всегда однозначного решения нет. Однако последнее время я стараюсь делать скрипты по Unix Way, в большей части кейсов получается в разы проще. Правда держу в голове, что если где-то начинается прикол со сложным bash скриптом, то лучше переписать на скрипт который все делает сам.
Вы делаете какую-то CLI программу или скрипт, который(ая) например генерирует
Есть два путя. Первый это прикрутить отправку в чат в сам CLI, чтобы прога сама отправляла куда нужно. Второй это мы не выебываемся и делаем CLI который только генерит отчет, а отправку делаем другим скриптом.
Второй вариант это и есть Unix Way. Основные принципы которого звучат так:
- Делай одно – делай хорошо. Вот этот single responsibility ногами отсюда растет.
- Пиши программы, которые работают вместе. Не нужно делать программу которая делает все, лучше использовать выход одной программы как вход другой
- Работай с текстом. Текстовые потоки – универсальный интерфейс.
В реальности я чаще всего вижу ситуацию, когда пытаются делать один скрипт который делает все. Сам не без греха, и кучу вещей так делал.
С одной стороны это и правда удобнее, ведь сегодня тебе нужно отчет отправлять в чат, а завтра попросят в s3 сохранять. И прикручивать s3 это разбираться с sdk, добавлять зависимости, обрабатывать ошибки и вот это все. При этом просто прикрутить рядом s3cmd это дело 5 минут.
С другой, это может быть не так удобно. Например что если нужно отправлять уже в несколько чатов, тут уже unix way становится сложнее, ведь появится уже bash скрипт который вызывает твою программу, а потом еще каким-то циклом будет вызывать скрипт отправки. Можно было в одном скрипте исправит пару строчек и не пачкаться о bash.
Короче сложно, как всегда однозначного решения нет. Однако последнее время я стараюсь делать скрипты по Unix Way, в большей части кейсов получается в разы проще. Правда держу в голове, что если где-то начинается прикол со сложным bash скриптом, то лучше переписать на скрипт который все делает сам.
❤10 6🔥1
Я понимаю когда бывшие разрабы начинают развлекаться с нейронками и создавать какие-то инструменты, которые помогают в работе, но как в этой тусовке оказались звезды?
PewDiePie строит у себя дома мини-датацентр на котором гоняет локальные языковые модели. Мила Йовович с другом сделала систему для памяти агентов и зашарила ее на github. Репозиторий за пару суток набрал более 7к звезд. Как там ваши репозитории поживают, пацаны?
PewDiePie строит у себя дома мини-датацентр на котором гоняет локальные языковые модели. Мила Йовович с другом сделала систему для памяти агентов и зашарила ее на github. Репозиторий за пару суток набрал более 7к звезд. Как там ваши репозитории поживают, пацаны?
😁17🔥2🤔1🗿1
Как оценить работу модели?
Часто вижу высказывания в стиле: вот новый клод стал тупее, или сжатие контекста работает плохо или так себе удерживается контекст. Я всегда задаюсь вопросом а как вы это поняли? Как ты понял, что новая версия модели стала работать хуже, или что контекст стал удерживаться не так как раньше?
В идеале чтобы это понимать у тебя должен быть свой бенчмарк на это. Желательно прям на задачи которые ты делаешь. Потому как открытые бенчмарки, которые используются для маркетинга новой версии модели особо ничего не дают. То что модель проходит swe bench не дает гарантию что на твоих задачах она покажет такой-же результат. Я к таким бенчмаркам скептично отношусь, потому как скорее всего модели прям под эти бенчмарки и обучаются.
Еще у нас у самих мозг довольно плохо контекст держит, сегодня ты поспал хуже, в итоге в промте не указал не всю информацию и вот уже нейронка отупела.
При этом понятное дело, что собирать свой серьезный бенчмар, это прям дело не простое. Еще и систему для запусков и оценки нужно делать, а это уже прям на целый проект тянет. В итоге так и получается что оцениваем мы модели в итоге чисто по вайбу.
Часто вижу высказывания в стиле: вот новый клод стал тупее, или сжатие контекста работает плохо или так себе удерживается контекст. Я всегда задаюсь вопросом а как вы это поняли? Как ты понял, что новая версия модели стала работать хуже, или что контекст стал удерживаться не так как раньше?
В идеале чтобы это понимать у тебя должен быть свой бенчмарк на это. Желательно прям на задачи которые ты делаешь. Потому как открытые бенчмарки, которые используются для маркетинга новой версии модели особо ничего не дают. То что модель проходит swe bench не дает гарантию что на твоих задачах она покажет такой-же результат. Я к таким бенчмаркам скептично отношусь, потому как скорее всего модели прям под эти бенчмарки и обучаются.
Еще у нас у самих мозг довольно плохо контекст держит, сегодня ты поспал хуже, в итоге в промте не указал не всю информацию и вот уже нейронка отупела.
При этом понятное дело, что собирать свой серьезный бенчмар, это прям дело не простое. Еще и систему для запусков и оценки нужно делать, а это уже прям на целый проект тянет. В итоге так и получается что оцениваем мы модели в итоге чисто по вайбу.
Меня вот что еще дико бесит, через год я буду уже как 10 лет в индустрии и все равно, каждый сука год я напарываюсь на одну и туже херабору. Ты делаешь проект, используешь хорошие как тебе кажется практики, нейронкой генеришь целые модули, пытаешься сделать все красиво, чтобы решить конкретную задачу.
И только когда уже закончил натыкаешься на решение, используя которое ты мог не делать 90% работы, при этом оно еще и работало бы лучше и стабильнее!
В итоге сидишь с осознанием что то, что ты делал условно месяц ты мог сделать за пару дней, а всемогущий claude даже намека на это решение тебе не дал. Сука...
И только когда уже закончил натыкаешься на решение, используя которое ты мог не делать 90% работы, при этом оно еще и работало бы лучше и стабильнее!
В итоге сидишь с осознанием что то, что ты делал условно месяц ты мог сделать за пару дней, а всемогущий claude даже намека на это решение тебе не дал. Сука...