Отвлекаясь от длиннопостов
Как понять, что справляешься как лид бодрой RnD команды?
Если отлучаешься на пару недель и больше - ни у кого ничего не горит и не подгорает. Активности команды не начинают падать на пол.
С лёгким напрягом начинаю планировать двухнедельный августовский отпуск. Предыдущие однонедельные эксперименты отсутствия себя проходили почти успешно. Если не считать того, что список дел наобсудить и вгрузиться после возращения в понедельник возрастал до неприличных размеров
В понедельник же происходит самый ответственный виклик, где надо собрать всю оперативную инфу и соединить всех со всеми.
Легко догадаться, какой день недели стал моим самым нелюбимым. Вот так люди и становятся суеверными.
Как понять, что справляешься как лид бодрой RnD команды?
Если отлучаешься на пару недель и больше - ни у кого ничего не горит и не подгорает. Активности команды не начинают падать на пол.
С лёгким напрягом начинаю планировать двухнедельный августовский отпуск. Предыдущие однонедельные эксперименты отсутствия себя проходили почти успешно. Если не считать того, что список дел наобсудить и вгрузиться после возращения в понедельник возрастал до неприличных размеров
В понедельник же происходит самый ответственный виклик, где надо собрать всю оперативную инфу и соединить всех со всеми.
Легко догадаться, какой день недели стал моим самым нелюбимым. Вот так люди и становятся суеверными.
❤4👍4🔥2😁1🤯1
4/5 пост, дальше только выводы
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
предыдущее
Пятница, 12ч
Realtime транскрипт, правки, сущности, баги, рефакторинг
Я надеялся в пятницу уже получить полностью рабочую сборку, но оставалось слишком много дел по работе системы, google extension ещё и не был начат.
Зафиксировал опоздание в день.
По привычке закопался в алгоритм и протокол realtime транскрибации - как копить буфер, корректировать транскрипт на лету. Закопаться нормально при классической разработке, но непозволительно в условиях интенсива. Стало ещё одной моей крупной ошибкой, стоившей 6 часов. Но хотя бы отловил пару проблем в процессе.
Инсайты
- На примере realtime протокола, ИИ не может алгоритмический код без очень точного описания.
Напутать индексацию пакета, поставить условие сброса кэша туда, куда его ставить НЕЛЬЗЯ, забыть, как используются счётчики. Ещё засунуть открытый сокет в хранилище сокетов сессий и получить обсёр в моменте, когда фронт отсоединяется первым от "активной" сессии... Напомню, что чем больше ты его поправляешь тем хуже становится код.
По итогу всю эту часть я делал ручками. Вдумчиво и внимательно.
- ИИ в общем случае очень плохо пишет схемы данных без очень конкретного аналитического описания. Легче продумать самому, а ИИ уже отдать на интеграцию.
Это в целом хорошая гигиеническая практика - Писать HLD и примерную схему данных до начала разработки.
Суббота, 8 часов
Гугл расширение, минификсы и завершение этапа проекта
Абсолютно новый для меня зверь. Без ИИ я такое расширение написать физически бы не смог. Поработал скорее как аналитик - где в первую очередь нужно описать и донести, что ты хочешь, подсобрать ожидания и хотелки хотя бы у себя в голове.
Так как осталось время, запилил допфичу по шерингу транскриптов наподобии гугл доков.
ИИ умудрился сломаться на несложном расширении модели БД, но с полпинка починился и адекватно написал миграцию.
Инсайты
- Структурированное МиниТЗ с просьбой составить план изменения, а потом ему следовать - хороший способ брать в выполнение сложные фичи
- ИИ владеет хорошей базой знаний по технологиям. Если перед реализацией в коде обсудить-посёрчить через него варианты, это может дать качественное решение
- Эмодзи в логах это на удивление прекрасно, если их не становится слишком много. Надо взять себе в боевые практики. С визуально-цветовыми ассоциациями проще выхватывать нужные моменты в общем потоке
На этом жизнеспособном этапе я закрыл активную разработку и все основные задачи интенсива. Дальше оставалось подведение итогов и горделивая беготня с демонстрациями во всех инстанциях.
Спустя неделю тестов на людях в гугл расширении обнаружилась критичнейшая вещь, очень подло и бесследно дропавшая запись спустя 20-40мин от начала.
ИИ по косвенным репортам и логам не справился - также пришлось погружаться самому. Теперь я знаю и умею вытворять с хромиум браузером гораздо больше интересных вещей.
П.с. извиняюсь за качество демок. Изначально они предназначались для околорабочих чатиков. NDAшу как могу.
🔥8🤔3❤1
Синк о том, как нормально развернуть prod с участием меня, кубера, переменного количества видеокарт, Ray, VLLM, нейросетей разного масштаба, двух дальнеродственных проектов, которые шерят ресурсы.
Итак, у нас есть:
- Ray фреймворк предполагает резервирование видеокарт под собой и в общем случае является ключом к их эффективному использованию
- Мы не уверены до конца, насколько он подружился с нашим кубером
- Видеокарты в общем случае резервируются, но нужно понимать подо что и насколько
- Первые 4 видеокарты резервируются легко и надёжно. Остальные - дольше и не так надёжно
- Под задачи проектов по моей оценке хорошо бы иметь в доступе 6-8 от нагрузки
- Дальнеродственные проекты хотелось бы разместить на том же кластере, но изолированно инфраструктурно
- Мне уже жаль бедного девопса, перед которым встанет задача это всё прикрепить к текущему CI/CD
Задачи такого рода отношу к комплексно-неприятным ибо прямого понятного решения не предвидится, начинаешь закапываться в трейдоффы, а конечное предложение в любом случае пожрёт ресурсы команды с неясной перспективой.
Когда-нибудь я точно смогу делать это рутинно, а пока - та ещё головоломка получается.
Пришли к тому, что для расширения видеокарт нужно эффективно занять существующие, а на существующие влезает примерно половина комфортно желаемой конфигурации системы.
Looks like предстоит интересный эксперимент по плотному утрамбовыванию всего и вся в минимальное количество H100. В целом, не самая ненужная метрика.
Как же не хватает под рукой какого-то крайне сеньорного сеньора, который бы пришёл и всё порешал, пока я внимал его мудрости.
Итак, у нас есть:
- Ray фреймворк предполагает резервирование видеокарт под собой и в общем случае является ключом к их эффективному использованию
- Мы не уверены до конца, насколько он подружился с нашим кубером
- Видеокарты в общем случае резервируются, но нужно понимать подо что и насколько
- Первые 4 видеокарты резервируются легко и надёжно. Остальные - дольше и не так надёжно
- Под задачи проектов по моей оценке хорошо бы иметь в доступе 6-8 от нагрузки
- Дальнеродственные проекты хотелось бы разместить на том же кластере, но изолированно инфраструктурно
- Мне уже жаль бедного девопса, перед которым встанет задача это всё прикрепить к текущему CI/CD
Задачи такого рода отношу к комплексно-неприятным ибо прямого понятного решения не предвидится, начинаешь закапываться в трейдоффы, а конечное предложение в любом случае пожрёт ресурсы команды с неясной перспективой.
Когда-нибудь я точно смогу делать это рутинно, а пока - та ещё головоломка получается.
Пришли к тому, что для расширения видеокарт нужно эффективно занять существующие, а на существующие влезает примерно половина комфортно желаемой конфигурации системы.
Looks like предстоит интересный эксперимент по плотному утрамбовыванию всего и вся в минимальное количество H100. В целом, не самая ненужная метрика.
Как же не хватает под рукой какого-то крайне сеньорного сеньора, который бы пришёл и всё порешал, пока я внимал его мудрости.
❤3🔥2
Пост 5/5, финалочка
Предыдущий
Наконец-то время подвести черту всей затее
Общий итог:
Первое и самое важное -порядочно освежил коднавыки и страты работы на форсаже.
Изначально без ИИ я бы оценил эквивалентный проект с нуля в 4 недели + фронтенд (ибо я не могу во фронтенд, но примерно заложил бы 2-3 недели). + финальная интеграция и пусконаладка (пусть 1 неделя) В сумме 8 недель
Для дальнейшего развития текущих наработок я бы заложил + пару недель рефакторинга (в итоге даст 4.5 недели на ИИ разработку, если не форсажить по 65 часов в неделю, как я)
В итоге получается ускорение на 43.75%, если очень грубо посчитать
Все намеченные изначально фичи и даже чуть больше были выполнены с опозданием в день относительно плана.
Проект вполне живой. Крутится, показывается, функционирует. Вокруг него уже задумчиво ходит пара продактов и тыкают палкой. Баги появляются, ловятся и фиксятся в основном незначительные/связанные с проблемами личного сервера
Сложно подобрать метрику качества для такой кодбазы, но в целом имеем ~3к строк вполне прогнозируемого кода (кроме, опять же, фронтенда, я хз как там)
Основным стандартам качества оно соответствует ~70%. Что значит ~ за 2 итерации ревью можно довести до вполне качественного кода.
Существенные проблемы/компромиссы:
* Сильно не хватает универсальности и некоторой доли абстракций. Условная замена Minio на какой-либо внешний S3 вероятна, но потребует переписывания многих вещей
* Масштабирование воркеров практически необходимо в будущем, но я не могу дать гарантий его бесшовной работы сейчас. Чует моё сердечко, что-то там перемудрили мы с Курсором.
* Оставлено некоторое количество проблем/компромиссов, которые не были бы допущены при изначально человеческом подходе.
* Избыточность и неравномерность логов, наличие артефактов в коде - любой другой разработчик кроме меня вынужден будет немного пострадать при онбординге
* Где-то в районе google extension есть большой простор для багов т.к. оно выступает в роли клиентской части и зависит от браузеров пользователей
* Через какое-то время вскрылся существенный баг между плеером и minio - как он подгружает большие аудио
Пока свободную версию щупать здесь https://speechcoreai.com/
Предыдущий
Наконец-то время подвести черту всей затее
Общий итог:
Первое и самое важное -порядочно освежил коднавыки и страты работы на форсаже.
Изначально без ИИ я бы оценил эквивалентный проект с нуля в 4 недели + фронтенд (ибо я не могу во фронтенд, но примерно заложил бы 2-3 недели). + финальная интеграция и пусконаладка (пусть 1 неделя) В сумме 8 недель
Для дальнейшего развития текущих наработок я бы заложил + пару недель рефакторинга (в итоге даст 4.5 недели на ИИ разработку, если не форсажить по 65 часов в неделю, как я)
В итоге получается ускорение на 43.75%, если очень грубо посчитать
Все намеченные изначально фичи и даже чуть больше были выполнены с опозданием в день относительно плана.
Проект вполне живой. Крутится, показывается, функционирует. Вокруг него уже задумчиво ходит пара продактов и тыкают палкой. Баги появляются, ловятся и фиксятся в основном незначительные/связанные с проблемами личного сервера
Сложно подобрать метрику качества для такой кодбазы, но в целом имеем ~3к строк вполне прогнозируемого кода (кроме, опять же, фронтенда, я хз как там)
Основным стандартам качества оно соответствует ~70%. Что значит ~ за 2 итерации ревью можно довести до вполне качественного кода.
Существенные проблемы/компромиссы:
* Сильно не хватает универсальности и некоторой доли абстракций. Условная замена Minio на какой-либо внешний S3 вероятна, но потребует переписывания многих вещей
* Масштабирование воркеров практически необходимо в будущем, но я не могу дать гарантий его бесшовной работы сейчас. Чует моё сердечко, что-то там перемудрили мы с Курсором.
* Оставлено некоторое количество проблем/компромиссов, которые не были бы допущены при изначально человеческом подходе.
* Избыточность и неравномерность логов, наличие артефактов в коде - любой другой разработчик кроме меня вынужден будет немного пострадать при онбординге
* Где-то в районе google extension есть большой простор для багов т.к. оно выступает в роли клиентской части и зависит от браузеров пользователей
* Через какое-то время вскрылся существенный баг между плеером и minio - как он подгружает большие аудио
Пока свободную версию щупать здесь https://speechcoreai.com/
❤6👍3🔥3
proxy_selenium.py
10 KB
Понадобилось мне кое-что автоматизированно нагуглить, а случился внезапный закоп.
Не очень понимаю, почему и как, но в селениумный хром драйвер аномально сложно пропихнуть авторизованную проксю.
Оно жалуется, что не может захавать из-за авторизации
А если её пропихнуть без авторизации, то закономерно же отлетает уже сама прокся, запрашивая basicauth.
Не первое откопанное решение, но ставшее первым рабочим, оказалось с оригинальным применением гугл расширения: оно запускает только бэкграунд, вешает listeners на любые авторизационные окна и пытается их заполнять.
Есть мнение, что хватило бы инит скрипта авторизации т.к. дальше бы прокся закешировала свои кредсы, но тогда бы не получилось такого забавного хака.
Раз появившись в предыдущей моей затее, google extensions начинают меня преследовать. Так и порождаются специализации.
Не очень понимаю, почему и как, но в селениумный хром драйвер аномально сложно пропихнуть авторизованную проксю.
Оно жалуется, что не может захавать из-за авторизации
chrome_options.add_argument(f'--proxy-server=https://{proxy.username}:{proxy.password}@{proxy.ip}:{proxy.port}')А если её пропихнуть без авторизации, то закономерно же отлетает уже сама прокся, запрашивая basicauth.
Не первое откопанное решение, но ставшее первым рабочим, оказалось с оригинальным применением гугл расширения: оно запускает только бэкграунд, вешает listeners на любые авторизационные окна и пытается их заполнять.
Есть мнение, что хватило бы инит скрипта авторизации т.к. дальше бы прокся закешировала свои кредсы, но тогда бы не получилось такого забавного хака.
Раз появившись в предыдущей моей затее, google extensions начинают меня преследовать. Так и порождаются специализации.
❤3👍2🥰2
Финансовый Motivation и развивающие вектора
У меня есть ещё канал для своих - Артём и жизненные коллизии. И эти "жизненные коллизии" - идеальное определение идеям, ещё не разложенным в голове и не сформированным в чёткие суждения. Ща будет такая.
Мыслей у меня набирается на порядочный монолог, попробую сфокусировать.
Глобальный вопрос - как, кому и насколько распределять повышения зп в команде, когда есть такая возможность?
А ещё попутно ответить на следующие вопросы воображаемого члена команды:
- Как работает подъём зп?
- Почему мне подняли на X, а соседнему челу на 2X?
- Я получаю M, что мне нужно сделать чтобы получать N?
- Я не хочу играть в эти игры, можно мне просто работать как нормальный человек?
Сразу уточню, что вопрос не касается бигтеха с его устоявшимся жабогадюкингом: матрицами компетенций, ИПР, КПИ, независимыми аттестациями... что там ещё есть?
Часть из этого, важно отметить, может работать вполне хорошо и качественно даже на мой нетолерантный вкус. Но чаще являет собой необходимый на масштабе компромисс с неприятным послевкусием.
Ещё важный момент, сама такая возможность - иметь устойчивый процесс пересмотра зп - это успех и команды, и всего бизнеса. Ну и залог стабильного перфоманса со сроком целеполагания на годы. Такое присутствует далеко не всегда, но давайте пофантазируем, как может выглядеть процесс, на мой взгляд, здоровый и сравнительно этичный
От чего я оттолкнулся?
- Любые качественно-количественные KPI приводят к активному задрачиванию оных и отвлекают людей от профильной работы
- Методы сбора ОС и взаимооценки могут быть хорошо поставлены и поддерживаться где-то между размерами уровня "кто этот человек?" и "я не могу не похвалить моего братана Васю"
- Грейдирование требует, собственно, поставленного грейдирования + предоставления возможностей по этому грейдированию подниматься.
- Личностная оценка руководителем - субъективна, непрозрачна и хакается совместными походами в бар
- Стабильность и прогнозируемость процесса должна присутствовать чтобы и лид и сотруники могли заниматься своими делами, не устраивая подобие экзаменационной сессии в рандомные моменты времени
- Отсутствие перегрузки формальностями - хорошо задокументированная коммуникация, тем более по таким чувствительным вещам - вполне понятное и нужное зло, стоит следить за тем чтобы оно было в необходимых объёмах, не вылезало сверх меры.
По итогу таковых размышлений я породил следующий флоу (WIP):
1) Безусловная индексация зп на некоторый минимальный процент раз в год при выполнении рабочих обязанностей в рамках ожиданий.
Исключением здесь может быть ощутимый недоперформ и серия факапов.
Некоторая уверенность в завтрашнем дне и показатель здоровья вашего работодателя
2) Раз в полгода проводится совместная сессия между сотрудником и лидом/рабочей группой по повышке, где формируются достижения сотрудника на основе активности за эти полгода: рабочих задачах, объёму ответственности, участии в развитии команды/юнита.
Тут, разумеется, есть гадкий момент, что много нас, а апельсин один. И кто-то, несмотря на то, что он молодец, орёл и тащил - может остаться не удовлетворён. Не могу пока предложить ничего лучше открытости к диалогу и чудес дипломатии
3) Сотруднику предлагается вариант самостоятельно(или с помощью) выбрать и взять на себя цели, коррелирующие с целями команды/бизнеса/мотивацией в профессиональном развитии.
Важным моментом вижу то, что любая дополнительная нагрузка и обязательства - опциональны и в первую очередь средство более прогнозируемо управлять своим ростом. Должно быть в форме превентивного соглашения. Вместе с тем, иногда может быть сложно сказать, где ты будешь особенно молодец на полгода вперёд. Должна быть опция вкладываться в рабочие обязанности, органически иметь больше ответственности и возможностей проявиться.
Повышение, отличное от индексационного, в любом случае предполагает какой-то объём нерядовых активностей и мне ввиду своего собственного экспириенса видится важным дать возможность сотруднику выбирать, как и в какой форме он хочет этого достичь.
Мыслей у меня набирается на порядочный монолог, попробую сфокусировать.
Глобальный вопрос - как, кому и насколько распределять повышения зп в команде, когда есть такая возможность?
А ещё попутно ответить на следующие вопросы воображаемого члена команды:
- Как работает подъём зп?
- Почему мне подняли на X, а соседнему челу на 2X?
- Я получаю M, что мне нужно сделать чтобы получать N?
- Я не хочу играть в эти игры, можно мне просто работать как нормальный человек?
Сразу уточню, что вопрос не касается бигтеха с его устоявшимся жабогадюкингом: матрицами компетенций, ИПР, КПИ, независимыми аттестациями... что там ещё есть?
Часть из этого, важно отметить, может работать вполне хорошо и качественно даже на мой нетолерантный вкус. Но чаще являет собой необходимый на масштабе компромисс с неприятным послевкусием.
Ещё важный момент, сама такая возможность - иметь устойчивый процесс пересмотра зп - это успех и команды, и всего бизнеса. Ну и залог стабильного перфоманса со сроком целеполагания на годы. Такое присутствует далеко не всегда, но давайте пофантазируем, как может выглядеть процесс, на мой взгляд, здоровый и сравнительно этичный
От чего я оттолкнулся?
- Любые качественно-количественные KPI приводят к активному задрачиванию оных и отвлекают людей от профильной работы
- Методы сбора ОС и взаимооценки могут быть хорошо поставлены и поддерживаться где-то между размерами уровня "кто этот человек?" и "я не могу не похвалить моего братана Васю"
- Грейдирование требует, собственно, поставленного грейдирования + предоставления возможностей по этому грейдированию подниматься.
- Личностная оценка руководителем - субъективна, непрозрачна и хакается совместными походами в бар
- Стабильность и прогнозируемость процесса должна присутствовать чтобы и лид и сотруники могли заниматься своими делами, не устраивая подобие экзаменационной сессии в рандомные моменты времени
- Отсутствие перегрузки формальностями - хорошо задокументированная коммуникация, тем более по таким чувствительным вещам - вполне понятное и нужное зло, стоит следить за тем чтобы оно было в необходимых объёмах, не вылезало сверх меры.
По итогу таковых размышлений я породил следующий флоу (WIP):
1) Безусловная индексация зп на некоторый минимальный процент раз в год при выполнении рабочих обязанностей в рамках ожиданий.
Исключением здесь может быть ощутимый недоперформ и серия факапов.
Некоторая уверенность в завтрашнем дне и показатель здоровья вашего работодателя
2) Раз в полгода проводится совместная сессия между сотрудником и лидом/рабочей группой по повышке, где формируются достижения сотрудника на основе активности за эти полгода: рабочих задачах, объёму ответственности, участии в развитии команды/юнита.
Тут, разумеется, есть гадкий момент, что много нас, а апельсин один. И кто-то, несмотря на то, что он молодец, орёл и тащил - может остаться не удовлетворён. Не могу пока предложить ничего лучше открытости к диалогу и чудес дипломатии
3) Сотруднику предлагается вариант самостоятельно(или с помощью) выбрать и взять на себя цели, коррелирующие с целями команды/бизнеса/мотивацией в профессиональном развитии.
Важным моментом вижу то, что любая дополнительная нагрузка и обязательства - опциональны и в первую очередь средство более прогнозируемо управлять своим ростом. Должно быть в форме превентивного соглашения. Вместе с тем, иногда может быть сложно сказать, где ты будешь особенно молодец на полгода вперёд. Должна быть опция вкладываться в рабочие обязанности, органически иметь больше ответственности и возможностей проявиться.
Повышение, отличное от индексационного, в любом случае предполагает какой-то объём нерядовых активностей и мне ввиду своего собственного экспириенса видится важным дать возможность сотруднику выбирать, как и в какой форме он хочет этого достичь.
🔥5👍3🤔3
Эпоха шантажа LLMок уходит
а я остаюсь
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5375404
Если верить вот этой папире, то все ухищрения с попытками дополнительно мотивировать модель сделать особенно хорошо - больше не актуальны.
Не то чтобы подобный промптинг и раньше входил в обязательные бест практики продакшн решений, но как некоторый забавный феномен в своё время был интересен. Регулярно сподвигал меня спонтанно пообещать модели миллион-другой долларов или описать, насколько это важно мне или моей больной тётушке.
Привычка обещать деньгиджунам в рандомные моменты времени уже никуда не денется, но будет происходить с полным осознанием бесполезности сего действа
Прогресс безжалостен. Будь я на месте главного обучатора LLM этого мира, оставил бы подход с шантажом как минимум пасхалкой
а я остаюсь
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5375404
Если верить вот этой папире, то все ухищрения с попытками дополнительно мотивировать модель сделать особенно хорошо - больше не актуальны.
Не то чтобы подобный промптинг и раньше входил в обязательные бест практики продакшн решений, но как некоторый забавный феномен в своё время был интересен. Регулярно сподвигал меня спонтанно пообещать модели миллион-другой долларов или описать, насколько это важно мне или моей больной тётушке.
Привычка обещать деньги
Прогресс безжалостен. Будь я на месте главного обучатора LLM этого мира, оставил бы подход с шантажом как минимум пасхалкой
🔥8