Мне вот тоже что-то такое видится, но как конкретно, не понятно. Что мне сейчас не нравится в трендах с LLM - они работают с тестом который по сути одномерный, это сильно упрощает модель мира
Я бы сказал дьявол кроется в деталях. Есть большое количество частных случаев и я ничего не имею против. Кошек действительно надо уметь готовить.
Но основной посыл статьи в том что авто тесты делаются по большей части тем кто не умеет.
И моя безопасная рекомендация - идти от REST API (или его аналога), потому что там есть очень четкий критерий хорошо/не хорошо. В остальных случаях - может быть так что тестов много покрытие отличное, но это ничего не значит.
То, что сравниваются модели звучит довольно странно. Из моего опыта
собственно модели одного поколения примерно одинаковые
сами модели почти ничего не могут, рабочий инструмент это AI Code Assistant который их использует и сравнивать имеет смысл скажем JetBrains Junie vs Github Copilot. Там основное соревнование сейчас идет про то как кто лучше построит последовательность вызовов моделей, как построит контекст как построит план, как интегрируется с информацией о проекте которую дает IDE.
Вы же не используете в разработке модель прям из окошка чата OpenAI, используется плагин к IDE и там качество работы зависит в основном от плагина а не от модели. Тот же Junie может под капотом для разного плана и сложности задач использовать разные модели не рассказывая эти подробности пользователю.
В общем противоречивые эмоции. С одной стороны хочется конечно 100% совместимости. Чтобы вот обновляешь версию Ява машины и все работает бесшовно. Это было раньше и я не скажу, что развитие Явы в те времена меня устраивало.
Сейчас да есть несовместимости если "вы делаете странное" (давайте называть вещи своими именами).Но вроде фиксится не очень ужасно, за Яву скорее рад чем наоборот.
Все же развития языка для меня важнее, чем совместимость сломанная на private static reflection.
Очень интересная статья код к сожаленю не работает, не хватает настроек по ходу
Traceback (most recent call last): File "C:_work__llm\test.py", line 14, in model = PeftModel.from_pretrained( File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 332, in from_pretrained model.load_adapter(model_id, adapter_name, is_trainable=is_trainable, **kwargs) File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 662, in load_adapter dispatch_model( File "C:\bin\python\lib\site-packages\accelerate\big_modeling.py", line 368, in dispatch_model raise ValueError( ValueError: We need an offload_dir to dispatch this model according to this device_map, the following submodules need to be offloaded: base_model.model.model.layers.20, base_model.model.model.layers.21, base_model.model.model.layers.22, base_model.model.model.layers.23, base_model.model.model.layers.24, base_model.model.model.layers.25, base_model.model.model.layers.26, base_model.model.model.layers.27, base_model.model.model.layers.28, base_model.model.model.layers.29, base_model.model.model.layers.30, base_model.model.model.layers.31, base_model.model.model.norm, base_model.model.lm_head.
Ну я имею ввиду что бабла поток, но сама windows в этом потоке не asset а скорее все же liability. Не зря же SQL сервер на линукс портировали. Машина крутится и с этим нчиего не сделать, но выпендириваться с отдельной ОС становится все более и более обременительно.
В 2026 советовать прочитать Фаулера, как это мило, спасибо!
golang? это который? if (errcode) - напишем пару строче кода
Давайте подождем когда его уже доделают.
Мне вот тоже что-то такое видится, но как конкретно, не понятно. Что мне сейчас не нравится в трендах с LLM - они работают с тестом который по сути одномерный, это сильно упрощает модель мира
Вот да особенно зло unit тесты вредят рефекторингу, забыл про это написать.
Фактически при мощном покрытии тестами рефакторинг превращается в ад.
Щаз допишу, спасибо, что напомнили.
Я бы сказал дьявол кроется в деталях. Есть большое количество частных случаев и я ничего не имею против. Кошек действительно надо уметь готовить.
Но основной посыл статьи в том что авто тесты делаются по большей части тем кто не умеет.
И моя безопасная рекомендация - идти от REST API (или его аналога), потому что там есть очень четкий критерий хорошо/не хорошо. В остальных случаях - может быть так что тестов много покрытие отличное, но это ничего не значит.
Ну если нет каких-то скрытых законов природы, то разница между кремнием и био очень условная. Немного другая технология изготовления чипов.
Ну как есть, может быть и поделка, но лучшей пока как-то не видно.
Вот да, как это киллограм+ нейронов умудряется работать это прям чертова магия. GPU прям очень далеко еще не там
То, что сравниваются модели звучит довольно странно. Из моего опыта
собственно модели одного поколения примерно одинаковые
сами модели почти ничего не могут, рабочий инструмент это AI Code Assistant который их использует и сравнивать имеет смысл скажем JetBrains Junie vs Github Copilot. Там основное соревнование сейчас идет про то как кто лучше построит последовательность вызовов моделей, как построит контекст как построит план, как интегрируется с информацией о проекте которую дает IDE.
Вы же не используете в разработке модель прям из окошка чата OpenAI, используется плагин к IDE и там качество работы зависит в основном от плагина а не от модели. Тот же Junie может под капотом для разного плана и сложности задач использовать разные модели не рассказывая эти подробности пользователю.
Мне кажется это несколько упрощенный взгляд на вещи
ну просто если говорить об аудито то надо как минимум вспомнить MDC и UUID запроса например.
logback апендеры достаточно гибкая штука, их конфигурация позволяют отправлять в несколько получателей.
А не лучше использовать https://github.com/danielwegener/logback-kafka-appender ?
ну микросервисный подход, когда можно апать версию для отдельныхз сервисов и кодовая база не такая здоровая - сильно спасает.
Тот самый последный дремучий микросервис который не меняется 8 лет, можно на 7-ой яве оставить. Фиг с ним
В общем противоречивые эмоции. С одной стороны хочется конечно 100% совместимости. Чтобы вот обновляешь версию Ява машины и все работает бесшовно. Это было раньше и я не скажу, что развитие Явы в те времена меня устраивало.
Сейчас да есть несовместимости если "вы делаете странное" (давайте называть вещи своими именами).Но вроде фиксится не очень ужасно, за Яву скорее рад чем наоборот.
Все же развития языка для меня важнее, чем совместимость сломанная на private static reflection.
Интересно бы узнать почему закрыли. Экономически оказалось таки не выгодно или еще что-то
Ясно попробую питон снести и заново поставить. Спасибо
Очень интересная статья код к сожаленю не работает, не хватает настроек по ходу
Traceback (most recent call last):
File "C:_work__llm\test.py", line 14, in
model = PeftModel.from_pretrained(
File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 332, in from_pretrained
model.load_adapter(model_id, adapter_name, is_trainable=is_trainable, **kwargs)
File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 662, in load_adapter
dispatch_model(
File "C:\bin\python\lib\site-packages\accelerate\big_modeling.py", line 368, in dispatch_model
raise ValueError(
ValueError: We need an
offload_dirto dispatch this model according to thisdevice_map, the following submodules need to be offloaded: base_model.model.model.layers.20, base_model.model.model.layers.21, base_model.model.model.layers.22, base_model.model.model.layers.23, base_model.model.model.layers.24, base_model.model.model.layers.25, base_model.model.model.layers.26, base_model.model.model.layers.27, base_model.model.model.layers.28, base_model.model.model.layers.29, base_model.model.model.layers.30, base_model.model.model.layers.31, base_model.model.model.norm, base_model.model.lm_head.Не понял, а где статья? Открыл, хотел почитать, а контента нет. Похоже текст не приложился. Поправьте пожалуйста
Ну я имею ввиду что бабла поток, но сама windows в этом потоке не asset а скорее все же liability. Не зря же SQL сервер на линукс портировали. Машина крутится и с этим нчиего не сделать, но выпендириваться с отдельной ОС становится все более и более обременительно.