Бенчмарки! Новый митап про DeepSWE, SWE-rebench v2 и др

Друзья, вы все еще верите бенчмаркам? Я вот все меньше. Наверняка уже все видели DeepSWE бенчмарк - пожалуй, наиболее противоречивый бенчмарк за последнее время, причем с полярными мнениями: для одних это единственный объективный бенчмарк, для других он абсолютно не имеет отношения к реальности. В общем, я подумал, что будет интересно разобраться глубже в современных бенчмарках - обсудить их достоинства и недостатки, чтобы понимать есть ли вообще смысл обращать внимание на SWE бенчмарки в 2026-м. Отдельно разберем обновленный SWE-rebench v2.
На митап мы позвали, вероятно, наиболее подкованного человека из русскоязычного пространства - Ибрагима Бадертдинова, он один из ключевых авторов бенчмарка SWE-rebench, который как раз недавно обновили. А еще, Ибрагим автор канала @c0mmit. А неудобные вопросы будет задавать горячо любимый друг нашего канала Максим Этихлид (@etechlead).

Будем обсуждать важность harness, утечки, бенчхакинг, важность флоу проекта (AGENTS.md, верификации и т. д.) и, конечно, методологии.

Дата и время: 9 июня 14:00 по МСК, 16:00 по Алматы, 13:00 CET, 12:00 по Лондону.
Ссылка на регистрацию на встречу.

Готовьте свои коварные вопросы, ведь будет уникальная возможность задать их Ибрагиму - автору одного из топовых бенчмарков.

—

Кстати, у нас было интервью с Ибрагимом, в котором мы разбирали подробно бенчмарк SWE-rebench, поэтому рекомендую к просмотру всем AI-энтузиастам и в качестве подготовки к нашему новому стриму: https://youtu.be/a5jf-kyV12Y

@ai_driven | AI-Driven Development: Родион Мостовой.

AgenticOps, часть №3 - платформа

Общие принципы
● агенты общаются с платформой через CLI + SKILL.md
● CLI-команды - плоские и максимально простые
● топология ресурсов приложения инкапсулирована в платформе
● даём агенту высокоуровневые инструменты, но стараемся избегать дырявых абстракций
● у агента могут быть как платформенные тулы, так и специфичные для его локального контекста
● почти всё типизировано, компилируется и тестируется (TypeScript + Deno) - детерминизм!

Части платформы

Адаптеры к базовым компонентам
TypeScript-обёртки вокруг API/CLI тех компонентов, которые были перечислены в посте №2 - отсюда и происходит требование к каждому компоненту иметь такие интерфейсы.

К примеру, для redis-cli, RabbitMQ HTTP API, для pg_dump - для всех них созданы обёртки в едином стиле.
Адаптеры знают, как общаться с компонентами инфраструктуры, ловят ошибки и работают с секретами.

И только адаптеры делают сырые вызовы к инфраструктурным компонентам и что-то от них парсят.

Дескриптор приложения
У платформы есть машиночитаемое описание приложения: дескриптор со списком ресурсов, и она знает, где что хостится, какие базовые компоненты нужны приложению и какие возможности они предоставляют.

Это позволяет агенту, к примеру, при дебаге не искать самому, где какой сервер, как к нему подключиться, а где у нас вообще логи, а что это за формат, а почему их тут 10 гигов, ааа..., а вместо этого:
● вызвать CLI-команду вида "дай логи с вот такими фильтрами"
● команда под капотом идёт к платформе
● платформа уже знает все места с логами для этого приложения
● платформа через адаптеры базовых компонентов сходит либо в файлы, либо в Loki, либо ещё куда, чтобы собрать логи
● логи агрегируются, чистятся и возвращаются агенту с пейджингом, удобным форматированием и указанием источника

Оркестрация
Тут живут и исполняются типовые сценарии и их шаблоны, такие как deploy, verify, diagnose и т.п.

К примеру, примерно так устроен шаблон для deploy:
● получаем сведения о конкретном приложении из дескриптора
● определяем, какие компоненты участвуют в deploy для этого приложения
● проверяем, живы ли они все
● получаем тег и/или версию из гита в качестве deploy tag
● проверяем, готов ли у нас билд и артефакты с нужным тегом, чтобы было из чего деплоить
● запускаем конкретный workflow деплоя (который определен в самом приложении, тут мы его деталей не должны знать)
● мониторим, как идёт, периодически рапортуем прогресс для агента-деплоера
● проверяем теги/версии на задеплоенных частях системы
● возвращаем итоговый отчёт агенту

Лирическое отступление
Казалось бы, можно просто обписать базовые компоненты адаптерами и накинуть сверху CLI + скиллы для агента.
И это вполне рабочий подход, когда приложений мало, их Ops не требует унификации и некоторое дублирование допустимо.
Но в моём случае (да и вообще в случае принятия платформенного подхода) - это именно то, от чего и хочется уйти :)

Преимущества тут такие:
● повторяемые процессы (или их части) отдаём платформе, чтобы агент делал меньше шагов, "ручных" действий и не загрязнял контекст лишними деталями
● можно менять топологию, расположение, и даже иногда сами базовые компоненты чисто на уровне самой платформы без необходимости менять инструкции для агентов-разработчиков
● безопасность - можно настроить набор тулов для конкретного агента, и ограничить его работу только с ресурсами, которые принадлежат его приложению - это тоже форсится платформой

CLI + SKILL.md для агентов
Агент пользуется плоским набором CLI-команд, главные из которых описаны в скилле.

Но при старте CLI сам делает discovery тех команд, которые доступны агенту.
Есть команды, специфичные для конкретного приложения, которые подгружаются динамически + платформа может включать/выключать некоторые команды.

Команды есть сценарные: deploy, verify, diagnose, а есть и для отдельных инструментов, типа redis flush namespace, s3 list.
Для каждой команды CLI может выдать хелп, который агент на ходу может изучить, а в некоторых ещё и follow up commands возвращает, давая подсказки, что ещё можно попробовать.

#ai #agentic_ops #devops

Сработаемся?

Навеяно обсуждением бенчмарков на недавнем стриме и тестированием Fable.

Смотрите, какая штука: кажется, фронтирные модели уже пересекли планку "достаточно" для "средних" задач во многих проектах по разработке.

А раз модели выдают решения, разницы между которыми по качеству не видно, то выбор перестаёт быть вопросом оценки модели в абстрактных попугаях.

Вместо этого на первый план выходит характеристика, которую не измерить публичными бенчами: "а сработаемся ли?".
В ней и то, впишется ли модель в ваши процессы, и насколько она инициативна, и даже попадает ли она в удобный для вас стиль общения (нередко - определяющая характеристика, как оказывается!).

● Ну т.е. бенчмарки - резюме модели, сигнал к тому, чтобы в принципе обратить на неё внимание.
● Эвалы - тестовое задание, вы даёте модели какие-то типовые для вашей работы задачи.
● Вайб-чеки - испытательный срок, с моделью нужно провести некоторое время, чтобы понять, сможете ли вы с ней эффективно работать.

И именно совместная работа на реальных задачах становится самым информативным этапом выбора.

—

Кстати, взял бы я на работу Fable?
Вайб-чек ещё в процессе, но в рамках подписки - да, это no brainer, как говорят в наших деревнях.

А какой модели/агента вам достаточно?
И достаточно ли :)

#короткопост

AI-вангование, итоги

8 месяцев назад довелось мне поучаствовать в круглом столе на FrontEnd Conf 2025, где мы обсуждали тему внедрения AI в SDLC.

А недавно Глеб сообщил о том, что записи наконец выложили в открытый доступ, так что теперь есть чем поделиться :)
Пересказывать видео не буду, советую всё-таки посмотреть - дискуссия во многом всё ещё актуальная:

Круглый стол про AI в SDLC

Лучше сделаю вот что.

Готовясь к выступлению, я набросал список своих наблюдений/предсказаний/идей о том, куда движется индустрия.
И вот, спустя восемь месяцев, стало любопытно сопоставить этот список с тем, к чему мы пришли: что подтвердилось, что устарело, о чём можно было сказать больше.

Список был такой:

🟢 1. Переход на работу с ИИ для разраба - смена психотипа с исполнителя на манагера, и сильно другой процесс мышления и навыков, не все переживут.

Подтвердился в полной мере. "Оркестратор агентов" стал общепринятым взглядом на то, как меняется профессия разработчика.

А "не все переживут" - по опросам, заметная доля компаний планирует расставаться с теми, кто не адаптируется.
Хотя я всё ещё считаю, что индустрия плохо старается в плане переучивания, а некоторые компании прям соревнуются в беге по граблям.

🟢 2. Цикл "постановка / ожидание / проверка" невыносим для некоторых психотипов.

Это из невысказанного :) За восемь месяцев народился целый жанр текстов про выгорание не от привычной работы, а от управления агентами: люди жалуются на возросшую когнитивную нагрузку, сложности с переключением, мелкую нарезку рабочего времени.

Да, с наскоку новый ритм оказался для многих выматывающим - сам через это проходил ещё на заре агентной эры, в ноябре 2024го.

🟡 3. Не все могут чётко выражать свои мысли - это независимо от профессии и места в иерархии.

Косвенно. Ну да, случились открытия, что качественно сформулировать намерение, чтобы бежать в правильную сторону - это, внезапно, важно.

Но одним из лейтмотивов того, почему у вроде бы одинаковых по скиллам людей получаются сильно разные результаты от ИИ, это наблюдение не стало.

А это, блин, вооот такенная проблема, особенно когда посмотришь вживую на то, как иногда ставятся задачи, и как в принципе передаётся информация от человека машине.

🟢 4. В оргах (и многих людях) дофига tacit knowledge, которое крайне сложно из них вытаскивается, но им самим кажется очевидным.

Этот, кажется, ещё и обострился. Мы за пару лет прошли от prompt engineering к context engineering, к скиллам и теперь вот даже целым бандлам скиллов для разных профессий, но проблема извлечения скрытого знания остаётся одним из главных узких мест в больших/старых организациях.

Более того, теперь ещё и чётко обозначилось сопротивление этому работников, особенно на фоне форсированного внедрения ИИ и запугивания увольнениями.

🟢 5. Успех внедрения ИИ зависит от доменной области, и если твой конкретный ИИ с ней плохо метчится - целый новый набор костылей нужен, боль и страдание.

Можно было бы ожидать появления ультра-эрудированных моделей, но увы. Если для вашей предметной у нейронки для обучения не хватило датасетов - интеллект её не спасёт: на каждый чих придётся собирать кучу контекста, т.к. знаний или хотя бы интуиции самой нейронки не хватит (даже если это Fable).

🟡 6. Сеньоры+, которые открыты к использованию ИИ - новая нефть )

Да, и даже уже находит денежное выражение. AI-суперюзеры могут быть в несколько раз продуктивнее медленных адоптеров, чаще получают повышение, а ещё местами практикуется надбавка за ИИ-скиллы и сопутствующее повышение эффективности.

А жёлтый тут потому, что "надбавки" недостаточно - люди будут уходить к более гибким конкурентам, делать свои продукты и строить AI-native teams и compounding startups.

🟢 7. Внедрение сверху ваще не работает в варианте "давайте просто купим подписки и курсы".

Ну это вообще стало базой, я и сам на нескольких докладах про это рассказывал, и мне даже реклама хайлоада постоянно попадается со слоганом "Cursor выдали — AI не внедрили" :)

Хочется успешных внедрений - нужно учиться гибридному подходу и создавать условия для того, чтобы инициатива сверху встретилась с энтузиазмом снизу. И это только начало пути.

🟢 8. Усилилось неравенство в командах, т.к. ИИ выступает мультипликатором (у кого-то - 1.1, а у кого-то - 0.9).

Тут я вилку, кажется, даже занизил - в действительности разброс оказался гораздо сильнее.
И да, реально есть те, у кого внедрение ИИ идёт в минус, как на уровне команд, так и отдельных людей :)

🟢 9. Роль конкретной личности резко возросла.

Прямое следствие №8 - разница между людьми, которые ИИ только трогают и теми, кто активно внедряет его в рабочие процессы, стала разительной, и продолжает усиливаться (вы посмотрите на Валеру Ковальского, к примеру :))

Всё как и писал один из фаундеров Anthropic:

к лету [2026-го] я ожидаю, что многие люди, работающие с передовыми ИИ-системами, будут чувствовать, будто живут в параллельном мире по сравнению с теми, кто с ними не работает. И, думаю, это будет больше, чем просто ощущение.

Это, кстати, ещё и сильно меняет рамку того, как таких людей вписывать в процессы.
Сама по себе ситуация нестандартная - ну представьте, что у вас сотрудник внезапно начал выдавать результат как целая команда :)

🟡 10. Фичи могут реализовываться по времени так же, но при этом успевают пройти больше итераций улучшения, что, как правило, дает большее качество.

Наполовину угадал. Скорость на отдельных этапах SDLC явно выросла, и да, стали больше смотреть на глобальные метрики, но системно пока что не придумали, как быть с этой скоростью на локальном участке, если пока что весь пайплайн не получается ускорить.

Ответ "простой" - работа над качеством и микроитерации на отдельно ускорившемся этапе.

🟢 11. Разработка смещается в сторону спеков на вход и верификации на выходе, а код генерит ИИ, отбирая кайф у тех, кто любит писать код - надо искать другие источники кайфа для них, нужен рефрейминг и т.п.

Ох, тут половина индустрии в состояниях от легкой грусти до ПТСР, потому что поменялся характер самой работы. И отнятый кайф - это один из главных вкладов в то самое выгорание из пункта №2.

Что делать - искать инженерную красоту в других вещах (про это, кстати, есть в докладе).

🟢 12. Внедрение ИИ в оргах = структурные изменения = рефакторинг организаций, что тянет за собой целый спектр технически-культурно-психологических вызовов, надо сразу над всем этим спектром думать для успеха

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

А учитывая компоненту того, что у нас не было прецедентов внедрения ИИ в прошлом, это даже в терминах управления изменениями не всегда получается точно выразить, приходится разбираться по месту и да, думать.

—

В целом удивительно, что тогдашние наблюдения не просто сохранились, а стали куда заметнее, несмотря на темпы прогресса в области.

За прошедшее время, конечно, очень много произошло - успели появиться и исчезнуть подходы к ИИ-разработке, оформились интересные тренды и всё ещё сильнее ускорилось.

Появилась и куча новых наблюдений и интересных исследований, на несколько серий постов хватит :)

#ai #sdlc #конфа

В программировании всегда были такие задачи, за которые часто брались новички.
Некоторые из них оказывались крайне ценными для становления специалиста, а где-то это был весёлый бег по граблям и изобретение велосипедов.

Для вайбкодинга тоже накопилось некоторое количество подобных мемных задач, мимо которых сложно пройти.

Давайте попробуем собрать статистику.

P.S.
Ну и напишите, может есть ещё что-то такое, что должен сделать начинающий вайбкодер / ии-инженер / ai-native developer / etc :)

P.P.S.
В комменты скину свои ответы

P.P.P.S.
Если интересно - распишу, что тут может быть ценным для начинашек, и почему ✍️

Вопросы "в глубину" к стартовым задачкам (1/2)

На самом деле, если вы занимались вышеперечисленными задачами, вы знаете, что они практически все с подвохами :)
И это делает их хорошими для того, чтобы копать вглубь на, к примеру, собеседовании на AI-assisted SWE.

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

Ключевое для меня, пожалуй, в том, чтобы задача заставляла видеть границы между моделью, инструментами, контекстом, инфраструктурой и измерением качества.

⭐️ Рядом с каждой задачей - оценка "полезности" (5 звезд - максимум).


Транскрибатор звонков (+ диктовка)
⭐️⭐️⭐️⭐️

Лень - двигатель прогресса, ну и плюс ко всему, как бы сумбурно вы ни изъяснялись, голосом вы все равно больше контекста передадите, и современная нейронка вас всё-таки поймет :)
А чем больше вы дадите детализированного контекста - тем лучше у вас будет итоговое решение.

В этой задаче, несмотря на то, что она на изи ваншотится, есть куча подводных граблей и сопутствующих вопросов:

● разные модели дают сильно разное качество и тут бы мы поговорили по крайней мере про WER/CER как метрики
● хватит ли метрик и при чём тут предметная область?
● как боретесь с плохо распознанными словами?
● что делать, если у вас какой-то особенный сленг используется?
● случалось ли вам распознавать интенсивные беседы финна и русского (которые отлично друг друга понимают)?
● как насчёт стримингового распознавания? а стримингового перевода?
● как вы боретесь с Димой Торжком?
● ASR-модель - это LLM? Вы уверены?
● чем в этой задаче может помочь LLM?
● диаризация / VAD / speaker recognition - на сдачу :)


Суммаризатор каналов телеги
⭐️⭐️⭐️

Задача не столько про нейронки, сколько про обычную инженерию.

● основная проблема, которую нужно решить - это как вы, собственно, вытаскиваете контент каналов
● MTProto-юзербот vs Bot API
● каким образом вы выделяете темы, заслуживающие внимания?
● дедупликация и кластеризация при сборе новостей
● как не оказаться в эхо-камере, настроив "важные" темы?
● почему все пилят свои суммаризаторы?

Ну и мне наверняка было бы интересно, как вы хостите это решение, насколько оно независимо от вас может работать, и как долго :)


Счетчик токенов/лимитов подписок
⭐️⭐️⭐️

Задача интересная и довольно просто реализуемая в том числе очень простой адаптацией готового (тысячи их на гитхабе).

Так что тут бы был +1 за "ручную" имплементацию - там пришлось бы влезть в логи агентов, а это в целом довольно полезно для понимания того, как там оно под капотом.

● что если нужно переключаться между разными подписками одного вендора и считать подписки по отдельности?
● а если между разными вендорами?
● а если у вендора нет API для того, чтобы узнать лимиты?
● почему у разных считалок могут быть в 10 раз отличающиеся числа?
● приходилось ли делать слежку за урезаниями лимитов со стороны вендора?
● можно ли посчитать токены перед отправкой?
● (со звездочкой) переносили ли когда-то сессию между разными вендорами / агентами?


Лендинг для AI-проекта, которого еще нет
⭐️⭐️

"Фу таким быть!" - сказал бы я раньше уверенно.
Сейчас бы, может, уже и не так уверенно, потому что навайбкодить проект под заинтересовавший людей лендинг стало куда проще.

Нооо достаточно сюда добавить "лист ожидания" или "мы вам перезвоним" - и я точно уже никогда не вернусь. Фу!

Я бы обязательно спросил: почему, мистер Андерсон? Почему вы это делаете?

Ладно-ладно:
● какая была гипотеза?
● откуда трафик?
● была ли заранее продумана метрика "ну не шмогла я, не шмогла", чтобы не попасть в ловушку невозвратных потерь? Как она выглядела?

Ну и обязательно бы попросил показать результат - ну чисто заценить, сколько там визуального слопа осталось, заморочился ли кандидат с тем, чтобы от него избавиться, есть ли у него вкус и способность дожимать мелочи


Уникальное приложение для задач / фитнеса / финансов
⭐️⭐️⭐️

Несмотря на то, что их уже и так тьма, само по себе создание подобных приложений это не плохо: ведь в случае с AI у нас открывается возможность бесконечной кастомизации функционала под себя (особенно если не питать иллюзий насчёт монетизации :)).

Поэтому мне скорее был бы интересен путь ваших мыслей относительно того как вы подходили к самой задаче кастомизации:
● насколько сильно отличался конечный результат от первого ваншота?
● что пришлось допиливать под себя?
● сколько времени ушло на допиливание?
● сколько раз стартовали заново? :)
● какие вещи оказались неожиданно сложнее, чем казались?

На таких задачах хорошо раскрывается способность человека рулить агентом и добиваться результата, который может сильно отклоняться от внутреннего дженерик-представления нейронки о стандартном туду-листе, к примеру


RAG для чата с кучкой markdown
⭐️⭐️⭐️⭐️⭐️

Ну предположим, что кто-то именно на векторах решил эту задачу сделать :)

В 2023м это было по дефолту: чанки, эмбеддинги, векторная база, вот это вот всё.
Сейчас первый вопрос скорее "а нужен ли вам вообще векторный RAG"?

Для кучки markdown длинный контекст или простой агент с grep'ом по файлам часто даёт результаты лучше наивного эмбеддинг-поиска.

● почему вы вообще решили, что вам нужны эмбеддинги?
● как нарезали чанки?
● как боролись с потерей мелких фактов?
● dense / BM25 / гибрид?
● верили ли ранжированию выдачи векторного поиска?
● как душили галлюцинации, особенно на мелких моделях?

Ну и контрольный: где всё ещё оправдан векторный RAG?

#aiswe #hr #junior

Вопросы "в глубину" к стартовым задачкам (2/2)

Прокся для доступа к нейронкам (типа OpenRouter)
⭐️⭐️⭐️

Хорошая задача, и опять же почти целиком инженерная.
Сам я тут обходился готовым, так что вдвойне было бы интересно послушать тех, кто полез делать своё - что именно не закрыл OpenRouter/LiteLLM.

● как справлялись с зоопарком вендорских API?
● что делали, когда вендор отвечает 429?
● по какому признаку роутили между моделями, если роутили вообще?
● а стриминг проксировали?
● приходилось ли решать проблему дрейфа API вендоров?
● как устроена система статистики?
● что изменится, если нагрузка возрастёт в 10 раз? А в 100?


MCP/CLI для какого-то сервиса
⭐️⭐️⭐️⭐️

Ухх, холиварная задача :)
Тут в первую очередь захотелось бы разобрать плюсы и минусы MCP как протокола - а заодно понять, нащупал ли человек границы применимости инструмента.

● в какой задаче возьмёте MCP, а в какой CLI?
● как тот и другой способ влияет на контекст?
● что и в каком формате класть в ответ для модели?
● нужен ли скилл под CLI? Как его сделать? А без него можно?
● REST -> MCP - как подошли к решению?
● автоконверсия MCP <-> CLI - насколько хорошая практика?
● смогли бы написать инъекцию для своего MCP/CLI?


Агент с нуля, голого JSON и while
⭐️⭐️⭐️⭐️⭐️

На мой вкус - лучшая стартовая задача для всех, кто лезет в агентов.
Неважно, пишете вы самих агентов или агентами пишете: понимать, как оно крутится внутри, всё равно нужно.

А крутится там, если убрать обёртки харнесса / агента / фреймворков, довольно простой цикл:
● собрать JSON
● послать на API-endpoint
● разобрать ответ
● выполнить вызов тула
● положить результат обратно
● повторить

Даже такая наивная реализация даст вам много инфы о том, как устроены агенты.

Ну а дальше начинается куча всего интересного:
● что остановит агента, решившего поработать вечно?
● пришёл ответ с парой тулов разом - исполняете подряд или параллельно?
● вызов тула упал - что увидит модель?
● предложите несколько вариантов того, что можно делать для экономии контекста
● как "договариваетесь" с моделью о структуре её ответа?
● пробовали сами создать и дёрнуть субагента?
● что делать, чтобы повысить cache hit rate?
● как мониторите работу агента?
● как будете подходить к задаче сэндбоксинга?


Мультиагентный флоу для кодинга
⭐️⭐️⭐️⭐️

Этим, кажется, вообще все занимаются - каждый строит какой-то свой, со своим уникальным набором блоков.
Но если приглядеться, то сами блоки более-менее универсальны, и вот про них бы мы предметно пообщались.

А по дороге выяснили бы, не оказалось ли в итоге, что один крепкий агент с хорошими тулами сделал бы то же самое без всей этой оркестрации :)

● зачем в флоу каждый конкретный блок?
● сколько будет 0.9⁵ и при чём тут это?
● как передаётся контекст между агентами?
● как замеряете "хорошесть" результата и его повторяемость?
● как находите, где процесс свернул не туда?
● на каких шагах требуется участие человека (HITL)?
● где берёте одного агента, а где всё-таки мультиагентный сетап?
● а что можно было бы обычным детерминированным скриптом сделать?


Бенчмарк/эвал под свои задачи
⭐️⭐️⭐️⭐️⭐️

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

Тут бы мы с вами поговорили об ограниченности нейронок в плане знания конкретных предметных областей, о загрязненности бенчмарков, об их сатурации и о том, насколько нестандартные задачи вам приходится решать, что даже собственный бенчмарк или эвал пришлось собирать.

● какова цель эвала или бенча?
● как собирали задачи для golden set?
● есть ли уверенность в том, что он отражает реальное распределение задач?
● какие метрики вывели для оценок?
● метрики автоматические или "ручные"?
● если есть LLM-as-a-judge - как убеждались в том, что он работает как надо?
● как сохраняете результаты между разными запусками и как сравниваете между собой?


"Opus дома" на ~27B-Q3_K_M.gguf модели
⭐️⭐️⭐️⭐️

Если у вас были какие-то мечты о том, чтобы получить Opus дома, мне было бы любопытно узнать, как вы к этому пришли и как от этого ушли - сама вот эта траектория взлётов и падений всегда интересна :)

● что по железу: сколько GPU, сколько нод, баланс VRAM/RAM
● где для вас находятся границы применимости локальных моделей и какой спектр задач вы ими решаете?
● поговорили бы про квантизацию, её виды, связь с железом
● какие inference-движки вы используете, с какими параметрами и почему?
● веса модели заняли 20/24гб VRAM - насколько хорошо она будет работать?
● сталкивались ли с задачей многопользовательского доступа к нейронкам и какие были сложности?
● TTFT, TPOT/TPS, latency, KV-cache utilization - на что обращали внимание?

И обязательно была бы секция про то, каким видится будущее локальных моделей :)


Послесловие

Каждая из этих задач когда-то могла быть фильтром на рынке труда: ну типа "запилил RAG" - строчка в резюме, "написанный с нуля агент хоть как-то шевелится" - повод позвать на разговор.

Сейчас generic-вариант любой из них навайбкодит кто угодно за вечер, и такой артефакт обесценился практически до нуля, его уже не поставить строчкой в резюме.

А вот способность дожать задачу до "идеального" состояния, побегав по граблям и получив знания по дороге, - ну, это не ваншотится.
Этим и ценно.

#aiswe #hr #junior