Проснувшись, я пошел эту идею проверять. Для базового эксперимента я перевел Яндекс Переводчиком описания топ-25 фильмов с IMDB на 9 языков и нарисовал tsne плоты хидденов с каждого трансформер блока из mGPT.
На получившейся картинке было явно видно, что есть эти три этапа эволюции хидденов, на втором этапе есть некоторый мультиязычный манифолд, где перемешаны все языки, кроме казахского и азербайджанского (которых в претрейне было очень мало), а в конце хиддены группируются по языкам с shared токенами (украинский/русский, английский/французский/немецкий). Получается:
- Да, модель не умеет мапить в латентный язык те языки, которые она не знает
- А не можем ли мы дать модели лучший кросслингвал трансфер засчёт дополнительного лосса при обучении -- например, какого-нибудь контрастива?
На получившейся картинке было явно видно, что есть эти три этапа эволюции хидденов, на втором этапе есть некоторый мультиязычный манифолд, где перемешаны все языки, кроме казахского и азербайджанского (которых в претрейне было очень мало), а в конце хиддены группируются по языкам с shared токенами (украинский/русский, английский/французский/немецкий). Получается:
- Да, модель не умеет мапить в латентный язык те языки, которые она не знает
- А не можем ли мы дать модели лучший кросслингвал трансфер засчёт дополнительного лосса при обучении -- например, какого-нибудь контрастива?
❤8🔥5
Потом была сорева по детоксу и защита магистерской, и мне временно было не до этого. Но идея меня не отпустила, так что на пропозале в аспирантуру я предложил покопать именно ее -- вроде бы всем понравилось и я приступил к работе.
Естественно, я почти сразу же понял, что какие-то китайцы сделали то что я придумал за пару месяцев до меня. Статья называлась AFP, там использовали InfoNCE лосс и метрики достаточно неплохо росли вверх. Но у них была проблема -- модель забывала, на каком языке ее промптили и путала таргет язык. Авторы решили это через банальный сфт, где указывали желаемый язык ответа -- это не слишком гибкий метод и я попробовал решить эту проблему другим способом.
Так как в моделях есть три этапа эволюции эмбеддингов, я попробовал брать хиддены непосредственно перед блоком, где применялся контрастив, совать их в скип коннекшн, который фильтрует нужную инфу от ненужной, и прокидывает хиддены в начало третьего этапа, чтобы модели было проще сделать "анмаппинг" обратно в кластера по языкам. Номер слоя, куда накладывается контрастив и откуда берется хидден и номер слоя, куда этот хидден переносится -- это гиперпараметры, которые я подбирал гридсерчем.
Это частично сработало, метрики у моей модели стали лучше в задаче перевода с английского на немецкий, стали хуже в задаче перевода с английского на турецкий и остались примерно такими же в задаче перевода с английского на китайский. При сравнении с AFP выяснилось, что моя имплементация работает лучше, потому что показывает лучшие скоры на Flores, чем указано в оригинальной статье -- и что время от времени скоры модели с AFP становились хуже, чем скоры модели, которая училась напрямую на перевод без дополнительных телодвижений. Китайцы наврали в метриках?
Что же пошло не так, что можно сделать и что я думаю по поводу этой статьи?
- Сами эксперименты я сделал примерно за неделю. У меня банально не хватило времени сделать нормальные абляции, прогнать обучение на перевод в обратную сторону и так далее.
- Идея довольно тяжеловесная. С чего я вообще решил, что скип коннекшн улучшит качество? Он улучшил, а объяснения этому у меня нет.
- Что с другими задачами, не переводом? Что с mmlu/hellaswag/etc?
Статью в итоге взяли на NAACL 2025 SRW. Если бы я был ревьюер, я бы, скорее всего, дал бы какой нибудь resubmit next cycle в лучшем случае, но мне повезло.
С другой стороны, есть значительно более изящная реализация моей идеи -- статья Lens: Rethinking Multilingual Enhancement for Large Language Models. В целом, там всё то же самое, но вместо накладывания контрастива на весь хидден, они раскладывают его через SVD, находят language specific и multilingual направления и стягивают контрастивом только multilingual направления, двигая language specific направления в сторону соответствующего языка. Как итог, эксперименты на llama-3-8b показывают, что метрики на мультиязычных задачах действительно неплохо растут. Очень советую почитать статью -- она лучше моей примерно во всём.
Моя статья
Естественно, я почти сразу же понял, что какие-то китайцы сделали то что я придумал за пару месяцев до меня. Статья называлась AFP, там использовали InfoNCE лосс и метрики достаточно неплохо росли вверх. Но у них была проблема -- модель забывала, на каком языке ее промптили и путала таргет язык. Авторы решили это через банальный сфт, где указывали желаемый язык ответа -- это не слишком гибкий метод и я попробовал решить эту проблему другим способом.
Так как в моделях есть три этапа эволюции эмбеддингов, я попробовал брать хиддены непосредственно перед блоком, где применялся контрастив, совать их в скип коннекшн, который фильтрует нужную инфу от ненужной, и прокидывает хиддены в начало третьего этапа, чтобы модели было проще сделать "анмаппинг" обратно в кластера по языкам. Номер слоя, куда накладывается контрастив и откуда берется хидден и номер слоя, куда этот хидден переносится -- это гиперпараметры, которые я подбирал гридсерчем.
Это частично сработало, метрики у моей модели стали лучше в задаче перевода с английского на немецкий, стали хуже в задаче перевода с английского на турецкий и остались примерно такими же в задаче перевода с английского на китайский. При сравнении с AFP выяснилось, что моя имплементация работает лучше, потому что показывает лучшие скоры на Flores, чем указано в оригинальной статье -- и что время от времени скоры модели с AFP становились хуже, чем скоры модели, которая училась напрямую на перевод без дополнительных телодвижений. Китайцы наврали в метриках?
Что же пошло не так, что можно сделать и что я думаю по поводу этой статьи?
- Сами эксперименты я сделал примерно за неделю. У меня банально не хватило времени сделать нормальные абляции, прогнать обучение на перевод в обратную сторону и так далее.
- Идея довольно тяжеловесная. С чего я вообще решил, что скип коннекшн улучшит качество? Он улучшил, а объяснения этому у меня нет.
- Что с другими задачами, не переводом? Что с mmlu/hellaswag/etc?
Статью в итоге взяли на NAACL 2025 SRW. Если бы я был ревьюер, я бы, скорее всего, дал бы какой нибудь resubmit next cycle в лучшем случае, но мне повезло.
С другой стороны, есть значительно более изящная реализация моей идеи -- статья Lens: Rethinking Multilingual Enhancement for Large Language Models. В целом, там всё то же самое, но вместо накладывания контрастива на весь хидден, они раскладывают его через SVD, находят language specific и multilingual направления и стягивают контрастивом только multilingual направления, двигая language specific направления в сторону соответствующего языка. Как итог, эксперименты на llama-3-8b показывают, что метрики на мультиязычных задачах действительно неплохо растут. Очень советую почитать статью -- она лучше моей примерно во всём.
Моя статья
🔥21❤5👌2🤔1
Сходил поболтать про нейросетевые мемы на радио Маяк в прямой эфир к Пушному:
https://smotrim.ru/audio/2849295
Получилось для широкой аудитории, но все равно забавно :)
https://smotrim.ru/audio/2849295
Получилось для широкой аудитории, но все равно забавно :)
🔥36❤🔥4❤1
Про сжатие контекста в RAG
Языковые модели плохо работают с длинными текстами. Да, у нас есть RAG, да, у нас есть модели с 1М, 2М и даже 10М контекстом — но все эти решения дают либо увеличенную задержку в случае нормально сделанного рага (реранкеры + поиск в жирной базе не бесплатные), либо неидеальный перформанс и страшные требования к видеопамяти в случае длинных контекстов. Надо как-то научиться работать с ними — поэтому одна из довольно интересных, по моему мнению, областей NLP — это сжатие контекста. Из статьи Юры Куратова мы знаем, что теоретически мы можем с помощью ptuning-лайк метода сжать до полутора тысяч токенов текста в один виртуальный токен. Это не абсолютное знание, поскольку и степень сжатия в предложенном там методе зависит от модели, и обсуждается не ретривал из виртуального токена, а реконструкция — но какую-то теоретическую верхнюю границу сжатия мы можем вывести. Но что, если мы хотим сжать контекст без оверфита токена под конкретный текст, причём не на задачу реконструкции, а на задачу ретривала?
На самом деле, похожую задачу сжатия некоторой информации для передачи в модель давно уже решают — в влм. Для того, чтобы "впихнуть невпихуемое", авторы LLaVA (и PaliGemma, Gemma 3, Molmo и прочих VLM без кросс-аттеншна) кодируют изображения через какой-то визуальный энкодер (например, сиглип в случае геммы), проводят получившиеся эмбеддинги через проектор (то есть линейный слой с активацией) и подсовывают в виртуальный [IMG] токен языковой модели. На первом этапе обучения и модель, и энкодер фризятся, обучается только проекция — по сути, он учится задаче "перевода" из "языка" визуального энкодера в "язык" текстового генератора. На втором этапе обучается и проекция, и языковая модель — мы делаем instruction tuning, обучая модель конкретным задачам, связанным с картинками.
Авторы xRAG — сегодняшней статьи — воспользовались очень похожей техникой, правда, с одним ключевым различием: энкодер у них не визуальный, а текстовый. Процедура обучения тоже очень похожа — сначала делается paraphrase pretraining (то есть, обучаем проектор на задаче парафразы из сжатого вектора в оригинальный текст), потом делается context-aware instruction tuning (то есть, дистилляция ответов с контекстом в ответы со сжатым вектором). На инференсе в контекст модели подсовывается сразу эмбеддинг из базы знаний (то есть, прогонять текст через энкодер не обязательно) и размер контекста, переданного модели, уменьшается в сотни раз. Такой сетап не только сравним по качеству как с обычным RAG, но и работает в полтора раза быстрее. Из дополнительных приятных плюшек, модель с xRAG имеет высокий resilience rate, то есть, модель сложнее запутать неверным контекстом по сравнению с RAG.
Чтобы улучшить этот подход, буквально неделю или две назад вышла SARA. Там пользуются точно таким же сетапом с мультимодальным фьюженом в декодерный трансформер, но вместо сжатия всего контекста в один токен, авторы предлагают подавать в модель как сжатые (в несколько токенов) документы, так и текстовые данные (типа как FROMAGE, но тоже вместо картинок тексты). Это позволяет модели, во-первых, более точно декодировать тексты, во-вторых, легко восстанавливать именованные сущности (например, имена городов или названия компаний) и в целом, добиваться более высоких скоров на бенчмарках. SARA безоговорочно бьёт как наивный RAG, так и xRAG по качеству, сжимая контекст и сохраняя эффективность инференса.
Мои мысли:
- Наконец-то я нашёл статью, где применили LUSIFER к декодерам!
- Интересно, используются ли подобные штуки где-то в проде — как будто бы в масштабах Google AI Overview, например, такие оптимизации рага могут сильно экономить бабки.
Статья xRAG
Статья SARA
*Qwen-2.5-7b-1M занимает примерно 111 гб видеопамяти и сильно дропается в качестве далеко до достижения миллиона токенов контекста.
Языковые модели плохо работают с длинными текстами. Да, у нас есть RAG, да, у нас есть модели с 1М, 2М и даже 10М контекстом — но все эти решения дают либо увеличенную задержку в случае нормально сделанного рага (реранкеры + поиск в жирной базе не бесплатные), либо неидеальный перформанс и страшные требования к видеопамяти в случае длинных контекстов. Надо как-то научиться работать с ними — поэтому одна из довольно интересных, по моему мнению, областей NLP — это сжатие контекста. Из статьи Юры Куратова мы знаем, что теоретически мы можем с помощью ptuning-лайк метода сжать до полутора тысяч токенов текста в один виртуальный токен. Это не абсолютное знание, поскольку и степень сжатия в предложенном там методе зависит от модели, и обсуждается не ретривал из виртуального токена, а реконструкция — но какую-то теоретическую верхнюю границу сжатия мы можем вывести. Но что, если мы хотим сжать контекст без оверфита токена под конкретный текст, причём не на задачу реконструкции, а на задачу ретривала?
На самом деле, похожую задачу сжатия некоторой информации для передачи в модель давно уже решают — в влм. Для того, чтобы "впихнуть невпихуемое", авторы LLaVA (и PaliGemma, Gemma 3, Molmo и прочих VLM без кросс-аттеншна) кодируют изображения через какой-то визуальный энкодер (например, сиглип в случае геммы), проводят получившиеся эмбеддинги через проектор (то есть линейный слой с активацией) и подсовывают в виртуальный [IMG] токен языковой модели. На первом этапе обучения и модель, и энкодер фризятся, обучается только проекция — по сути, он учится задаче "перевода" из "языка" визуального энкодера в "язык" текстового генератора. На втором этапе обучается и проекция, и языковая модель — мы делаем instruction tuning, обучая модель конкретным задачам, связанным с картинками.
Авторы xRAG — сегодняшней статьи — воспользовались очень похожей техникой, правда, с одним ключевым различием: энкодер у них не визуальный, а текстовый. Процедура обучения тоже очень похожа — сначала делается paraphrase pretraining (то есть, обучаем проектор на задаче парафразы из сжатого вектора в оригинальный текст), потом делается context-aware instruction tuning (то есть, дистилляция ответов с контекстом в ответы со сжатым вектором). На инференсе в контекст модели подсовывается сразу эмбеддинг из базы знаний (то есть, прогонять текст через энкодер не обязательно) и размер контекста, переданного модели, уменьшается в сотни раз. Такой сетап не только сравним по качеству как с обычным RAG, но и работает в полтора раза быстрее. Из дополнительных приятных плюшек, модель с xRAG имеет высокий resilience rate, то есть, модель сложнее запутать неверным контекстом по сравнению с RAG.
Чтобы улучшить этот подход, буквально неделю или две назад вышла SARA. Там пользуются точно таким же сетапом с мультимодальным фьюженом в декодерный трансформер, но вместо сжатия всего контекста в один токен, авторы предлагают подавать в модель как сжатые (в несколько токенов) документы, так и текстовые данные (типа как FROMAGE, но тоже вместо картинок тексты). Это позволяет модели, во-первых, более точно декодировать тексты, во-вторых, легко восстанавливать именованные сущности (например, имена городов или названия компаний) и в целом, добиваться более высоких скоров на бенчмарках. SARA безоговорочно бьёт как наивный RAG, так и xRAG по качеству, сжимая контекст и сохраняя эффективность инференса.
Мои мысли:
- Наконец-то я нашёл статью, где применили LUSIFER к декодерам!
- Интересно, используются ли подобные штуки где-то в проде — как будто бы в масштабах Google AI Overview, например, такие оптимизации рага могут сильно экономить бабки.
Статья xRAG
Статья SARA
*Qwen-2.5-7b-1M занимает примерно 111 гб видеопамяти и сильно дропается в качестве далеко до достижения миллиона токенов контекста.
👍9🔥9✍1
Метрики xRAG (где-то лучше, где-то хуже) и SARA (лучше почти везде).
👍4🔥4
Про настройку линукса
Ушел в отпуск, отдыхаю. В рамках отпуска добыл два мини-пк на N100/N97, чтобы повесить за телевизоры и настроить там тонкие клиенты для Sunshine+Moonlight. У N100 и N97 есть хардварный декодер AV1, да и железо там помощнее, чем у моих андроид телевизоров, так что для снижения задержки при стриминге с компа они идеальны.
Заодно хочется сделать из них медиасервер на основе Kodi, чтобы зря не пропадали ссд, которые стоят внутри. Да и в принципе, железо сравнительно мощное, памяти много, это вполне себе нормальные варианты для двух хоумлаб. Поэтому я решил поставить туда убунту сервер и настроить киоски, чтобы при загрузке оно сразу входило в Kodi/Moonlight и начинало работать максимально seamless.
Когда-то я уже поработал сисадмином, копаться в кишках линукса мне в целом нравится, но конкретно в этот раз мне было очень лень это делать. Поэтому я с помощью гемини набросал небольшой скрипт, который выдает Gemini 2.5 Flash с опенроутера доступ к терминалу и задачу для решения — а она сама там все настраивает как личный сисадмин.
Я это сделал с ожиданием того, что я просто сокращу количество пересылок из вебчата в терминал и обратно и что большую часть задачи я решу своими руками, но, на удивление, 75% работы гемини сделала сама.
Сам по себе киоск на мунлайте она организовала довольно быстро. Чуть дольше времени она чинила то, что мунлайт запускался не во весь экран, а только в четверть — но моего ручного вклада там тоже было минимум. Сложнее всего модели далась задача настройки звука через HDMI — победить пульсу не смогла ни Gemini 2.5 Flash, ни Gemini 2.5 Pro. Смогла только o3, но спустя 10-15-20 суммарных часов настройки. Мб 2.5 Pro бы тоже смогла, но о3 в вебморде бесплатная, а 2.5 Pro в апи нет :P
Я посмотрел, что она там наворотила — вроде бы выглядит вменяемо. Всё держится на systemd-сервисе с автостартом, который дёргает скрипт с запуском всего, что мне надо. Наверное, было бы оптимальнее разнести это на несколько сервисов, но ну его нафиг, я снова в это лезть не хочу.
Выводы:
- Для каких-то несложных задач типа настройки окружения на пустом пк даже 2.5 Flash за 60 центов за лям токенов отлично подходит.
- Для более сложных задач не подходит ни одна модель — либо страшно дорого, либо слабовато.
- Мб стоит сдистиллить в какую-нибудь мелкую модель (типа 7б квен кодера) трейсы таких настроек линукса от больших моделей (типа 2.5 flash/pro), чтобы стало дёшево?
- Стриминг видеоигр по локалке отличная альтернатива HDMI. Проводов нет, а картинка абсолютно неотличима от нативной.
- Call of Duty: Modern Warfare II (2022) полная фигня, я прошёл, но мне не понравилось.
Gist со скриптом на гитхабе
Ушел в отпуск, отдыхаю. В рамках отпуска добыл два мини-пк на N100/N97, чтобы повесить за телевизоры и настроить там тонкие клиенты для Sunshine+Moonlight. У N100 и N97 есть хардварный декодер AV1, да и железо там помощнее, чем у моих андроид телевизоров, так что для снижения задержки при стриминге с компа они идеальны.
Заодно хочется сделать из них медиасервер на основе Kodi, чтобы зря не пропадали ссд, которые стоят внутри. Да и в принципе, железо сравнительно мощное, памяти много, это вполне себе нормальные варианты для двух хоумлаб. Поэтому я решил поставить туда убунту сервер и настроить киоски, чтобы при загрузке оно сразу входило в Kodi/Moonlight и начинало работать максимально seamless.
Когда-то я уже поработал сисадмином, копаться в кишках линукса мне в целом нравится, но конкретно в этот раз мне было очень лень это делать. Поэтому я с помощью гемини набросал небольшой скрипт, который выдает Gemini 2.5 Flash с опенроутера доступ к терминалу и задачу для решения — а она сама там все настраивает как личный сисадмин.
Я это сделал с ожиданием того, что я просто сокращу количество пересылок из вебчата в терминал и обратно и что большую часть задачи я решу своими руками, но, на удивление, 75% работы гемини сделала сама.
Сам по себе киоск на мунлайте она организовала довольно быстро. Чуть дольше времени она чинила то, что мунлайт запускался не во весь экран, а только в четверть — но моего ручного вклада там тоже было минимум. Сложнее всего модели далась задача настройки звука через HDMI — победить пульсу не смогла ни Gemini 2.5 Flash, ни Gemini 2.5 Pro. Смогла только o3, но спустя 10-15-20 суммарных часов настройки. Мб 2.5 Pro бы тоже смогла, но о3 в вебморде бесплатная, а 2.5 Pro в апи нет :P
Я посмотрел, что она там наворотила — вроде бы выглядит вменяемо. Всё держится на systemd-сервисе с автостартом, который дёргает скрипт с запуском всего, что мне надо. Наверное, было бы оптимальнее разнести это на несколько сервисов, но ну его нафиг, я снова в это лезть не хочу.
Выводы:
- Для каких-то несложных задач типа настройки окружения на пустом пк даже 2.5 Flash за 60 центов за лям токенов отлично подходит.
- Для более сложных задач не подходит ни одна модель — либо страшно дорого, либо слабовато.
- Мб стоит сдистиллить в какую-нибудь мелкую модель (типа 7б квен кодера) трейсы таких настроек линукса от больших моделей (типа 2.5 flash/pro), чтобы стало дёшево?
- Стриминг видеоигр по локалке отличная альтернатива HDMI. Проводов нет, а картинка абсолютно неотличима от нативной.
- Call of Duty: Modern Warfare II (2022) полная фигня, я прошёл, но мне не понравилось.
Gist со скриптом на гитхабе
🔥9👍3🤔1
Метаразмышление по поводу серии постов где я что-то опять навайбкодил
Где-то на HackerNews недавно прочитал интересную мысль: самое главное, что поменялось с приходом чатгпт — написание текстов стало очень дешёвым, а вот чтение так и осталось дорогим. Отличить AI slop от нормального текста всё ещё можно, но это ж надо вчитаться. Хорошие AI-assisted или AI-generated тексты всё ещё бывают, читать их приятно и легко, но проблема, очевидно, не в них.
В изначальной формулировке сказанное относилось только к текстам, но я её расширю и скажу, что с кодом это работает так же. Генерить рабочий или полурабочий код стало очень дёшево — расценки всем известны и доступны на опенроутере. Качество кода может разниться, оно может быть как идеально вылизанным, так и отвратительным месивом. Сгенерированный код может быть как лучше натурального, свежеиспечённого, руками написанного кода, так и проигрывать ему в изяществе/продуманности/эффективности.
Каждый раз, когда я писал подобные посты с отчётом о том, как я что-то навайбкодил, меня начинала терзать мысль, что это недостойно публикации, потому что любой дурак может запромптить гемини написать тетрис, написать свой код для решения задачи было бы гораздо круче. Повторить это быстро и легко и особых скиллов для этого не надо.
С другой стороны, запромптить гемини это половина дела — причём, вторая половина дела. Если бы я не придумал свою модификацию тетриса, если бы я не плейтестил еёна скучных созвонах в течение нескольких недель, если бы не отлаживал руками дурацкие баги, я бы её не доделал. Да, мой вклад в кодинг был в районе 1%, но без идеи он бы вообще не запустился.
Пост про подпивасов, на который я сослался в начале, тоже такой. Наверное, его можно вообще ваншотнуть, потому что идея достаточно остроумная, чтобы, будучи завёрнутой в приятный и лёгкий стиль от чатгпт, она мне запомнилась. Поэтому, даже если аидер будет писать 100% кода в каждом релизе, а не по 70-80%, как сейчас, всё равно профессия айтишника не вымрет, а редуцируется до тимлида.
Хорошо это или плохо? Имхо, если любая домохозяйка сможет получить написанный под нее уникальный софт по достаточно внятному запросу, это будет хорошо. Или если я смогу навайбкодить универсально полезную и переиспользуемую вещь -- например, как вот такой визуализатор остатка баланса на ключе с опенроутера, который у нас в аири активно используется -- это тоже будет хорошо. Но тенденция увеличения количества поставленных на поток генераций текстов*, пулл реквестов, картинок сомнительной ценности** заставляет тратить время и силы на более тщательный анализ как контента, так и источников, которые этот контент публикуют.
*Со всем уважением к Григорию Сапунову и к его труду признаюсь: на гонзомл я подписался из-за авторских разборов статей (и, собственно, вдохновлялся тоже им, когда создавал этот канал), а закончилось все ссылками на авторазборы в подкастах. Это ну совсем не то.
**Людям дали лучший на свете генератор картинок, идеальную кисть, проектор из сознания творца в png-картинки разрешением в 768 пикселей по горизонтали, а они все стали генерить одинаковые аватарки в стиле студии Ghibli. Humanity is doomed.
Где-то на HackerNews недавно прочитал интересную мысль: самое главное, что поменялось с приходом чатгпт — написание текстов стало очень дешёвым, а вот чтение так и осталось дорогим. Отличить AI slop от нормального текста всё ещё можно, но это ж надо вчитаться. Хорошие AI-assisted или AI-generated тексты всё ещё бывают, читать их приятно и легко, но проблема, очевидно, не в них.
В изначальной формулировке сказанное относилось только к текстам, но я её расширю и скажу, что с кодом это работает так же. Генерить рабочий или полурабочий код стало очень дёшево — расценки всем известны и доступны на опенроутере. Качество кода может разниться, оно может быть как идеально вылизанным, так и отвратительным месивом. Сгенерированный код может быть как лучше натурального, свежеиспечённого, руками написанного кода, так и проигрывать ему в изяществе/продуманности/эффективности.
Каждый раз, когда я писал подобные посты с отчётом о том, как я что-то навайбкодил, меня начинала терзать мысль, что это недостойно публикации, потому что любой дурак может запромптить гемини написать тетрис, написать свой код для решения задачи было бы гораздо круче. Повторить это быстро и легко и особых скиллов для этого не надо.
С другой стороны, запромптить гемини это половина дела — причём, вторая половина дела. Если бы я не придумал свою модификацию тетриса, если бы я не плейтестил её
Пост про подпивасов, на который я сослался в начале, тоже такой. Наверное, его можно вообще ваншотнуть, потому что идея достаточно остроумная, чтобы, будучи завёрнутой в приятный и лёгкий стиль от чатгпт, она мне запомнилась. Поэтому, даже если аидер будет писать 100% кода в каждом релизе, а не по 70-80%, как сейчас, всё равно профессия айтишника не вымрет, а редуцируется до тимлида.
Хорошо это или плохо? Имхо, если любая домохозяйка сможет получить написанный под нее уникальный софт по достаточно внятному запросу, это будет хорошо. Или если я смогу навайбкодить универсально полезную и переиспользуемую вещь -- например, как вот такой визуализатор остатка баланса на ключе с опенроутера, который у нас в аири активно используется -- это тоже будет хорошо. Но тенденция увеличения количества поставленных на поток генераций текстов*, пулл реквестов, картинок сомнительной ценности** заставляет тратить время и силы на более тщательный анализ как контента, так и источников, которые этот контент публикуют.
*Со всем уважением к Григорию Сапунову и к его труду признаюсь: на гонзомл я подписался из-за авторских разборов статей (и, собственно, вдохновлялся тоже им, когда создавал этот канал), а закончилось все ссылками на авторазборы в подкастах. Это ну совсем не то.
**Людям дали лучший на свете генератор картинок, идеальную кисть, проектор из сознания творца в png-картинки разрешением в 768 пикселей по горизонтали, а они все стали генерить одинаковые аватарки в стиле студии Ghibli. Humanity is doomed.
❤16🔥7👍5
Время идёт, а тот самый промпт про посуду всё ещё остаётся непобедимым...
Кто пропустил: https://huggingface.co/openai/gpt-oss-120b
Кто пропустил: https://huggingface.co/openai/gpt-oss-120b
🥰3
Гречневые мысли
Время идёт, а тот самый промпт про посуду всё ещё остаётся непобедимым... Кто пропустил: https://huggingface.co/openai/gpt-oss-120b
Но кстати вайбы приятные, посттрейнинг у модели явно шёл по тому же пути, что и у 4о/о4. Модель пишет не сухой текст как от квена, так что в принципе прикольно. Русский у 20б отвратительный, с постоянными ошибками, но 120б уже вполне себе приемлемо работает.
Надо ещё в агентном локальном кодинге попробовать.
Надо ещё в агентном локальном кодинге попробовать.
👍6
Гречневые мысли
Время идёт, а тот самый промпт про посуду всё ещё остаётся непобедимым... Кто пропустил: https://huggingface.co/openai/gpt-oss-120b
PSA: Groq сломан, у остальных провайдеров всё получше. Но 20б везде на русском плохая :(
👍2😢2
А самое смешное, что демка эффекта бернулли, которую они с помпой показали на презентации, кажется, некорректная. Вот вам и пхд левел интеллидженс.
Жаль, что за вайбкодингом пришел вайбпрезенташнинг. "Модель лучше потому что она лучше, вот она багу пофиксила в зерошоте, вот тут сайтик красивый нарисовала, а тут смогла аж буквы доктора прочитать с картинки, во могет". И не важно, что по метрикам она стала лучше не слишком радикально, что степень сложности баги не объяснили и сайтик кривой. Главное -- звучать уверенно.
Хотя юзерам, вроде, нравится. Будем посмотреть.
Жаль, что за вайбкодингом пришел вайбпрезенташнинг. "Модель лучше потому что она лучше, вот она багу пофиксила в зерошоте, вот тут сайтик красивый нарисовала, а тут смогла аж буквы доктора прочитать с картинки, во могет". И не важно, что по метрикам она стала лучше не слишком радикально, что степень сложности баги не объяснили и сайтик кривой. Главное -- звучать уверенно.
Хотя юзерам, вроде, нравится. Будем посмотреть.
🤮11💯8🤯1