Хвост инженера

Автор: Екатерина Давыдова · AvitoTech

Екатерина Давыдова — программный менеджер в Авито, ведёт внутреннюю программу, которая объединяет все GenAI-команды компании. Авито — один из крупнейших классифайдов мира, и в этой связи их опыт выстраивания работу с GenAI отличается от опыта стартапов с «чистым листом».

Доклад начинается с конкретной ситуации: к продуктовой команде приходит CEO и говорит «давайте уже что-нибудь запустим на AI, иначе будет поздно» — и команда не понимает ни где брать идеи, ни какие ресурсы нужны, ни как вообще двигаться. Давыдова прошла через это с десятками команд и рассказывает, что работает на каждом из пяти этапов: от генерации идей до масштабирования.

Формат — не история успеха, а производственный разбор. Что делать на каждом шаге, какие этапы выпадают при планировании и потом больно бьют, и почему «80% компаний сказали что начали что-то внедрять, но только 10% смогли объяснить — что именно».

Кому смотреть: продуктовым лидерам, которым пришла задача «запустить что-то на GenAI» — и которые хотят понять, с чего начинать и где обычно закапываются.

Из этого можно взять в работу: WizardOfOz-эксперимент. До того как у вас есть рабочая модель, посадите человека имитировать AI в диалоге с пользователями. Вы начнёте собирать паттерны запросов, проверять первые гипотезы и снимать метрики — не написав ни строчки кода для самой модели.

Автор: Иван Ямщиков · Podlodka Podcast

Иван Ямщиков работает в Pleias — компании, которая строит открытые языковые модели. Во время записи выпуска Podlodka #468 вышла новость о партнёрстве Pleias с Nvidia в рамках проекта Nemotron. Это не случайный контекст: Ямщиков находится внутри процесса, а не смотрит на него снаружи.

Центральный вопрос выпуска — не технический, а стратегический: что произойдёт, если весь рынок AI окончательно сконцентрируется вокруг нескольких закрытых облачных провайдеров? Ямщиков формулирует это как инженерную проблему: зависимость от GPT-4 API — это зависимость от одного вендора с непрозрачной политикой изменений, ценообразования и доступа к данным. Маленькие открытые модели — это не «дешёвая альтернатива большим», это инструмент сохранения контроля над инфраструктурой. Модель на 7 миллиардов параметров, которая умещается на одной GPU и работает локально, даёт то, что никакое API не даёт: полную воспроизводимость, отсутствие утечки данных и независимость от апстрима.

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

Из этого можно взять в работу: если вы сейчас используете закрытый API для задачи, которая не требует GPT-4-уровня рассуждений (классификация, извлечение структуры, генерация по шаблону) — попробуйте запустить Mistral 7B или Phi-3 локально на той же задаче. Разрыв в качестве окажется меньше, чем вы ожидаете.

Автор: Владислав Танков · Podlodka Podcast

Владислав Танков — директор по AI в JetBrains. Это второй его выпуск на Podlodka (#452): первый (#444) был про внутреннее устройство LLM на уровне трансформеров и аттеншенов. Этот — про то, что происходит, когда модель нужно не просто запустить, а запустить в продакшне под реальной нагрузкой.

Большинство разговоров про LLM в продакшне сводятся к «берём OpenAI API и готово». Танков рассказывает про другой класс задач: когда API не подходит — из-за данных, задержки, стоимости или политики безопасности — и нужно думать об инфраструктуре самому. Локальный инференс vs облачный — это не просто вопрос цены, это вопрос контроля над latency, privacy и зависимостью от внешнего провайдера. В JetBrains этот выбор делается для каждого продукта отдельно, и критерии нетривиальны.

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

Из этого можно взять в работу: если вы сейчас используете LLM только через API — составьте список требований к задержке, приватности данных и стоимости для вашего конкретного use case. Это займёт час, но может изменить архитектурное решение.