DeepSchool / underthehood

На этом моя неделя заканчивается Пытался показать агентскую разработку не со стороны хайпа, а со стороны реальных приколов: — tool оказался backend-friendly, а не LLM-friendly — ReAct-промпт превратился в монолит — модели не дали места, где можно безопасно подумать — часть ошибок оказалось проще чинить кодом, а не промптом Главная мысль недели: Если вы не можете дообучить модель, вас ждёт захватывающий и удивительный мир жонглирований, переворотов и фокусов с контекстом В таком сетапе оказывается, что качество системы во много зависит не только от модели, но и от интерфейсов, декомпозиции и проверок вокруг неё Спасибо всем, кто читал ❤️ P.S. Дальше мои мысли возвращаются в @yet_another_mle

Tool call — это просто текст. Его можно модифицировать Когда LLM вызывает инструмент, это не какой-то магический вызов функции напрямую. Сначала модель генерирует структуру в JSON, примерно такую: { "name": "search_cruises", "args": { "departure_cities": ["москва"], "departure_date_from": "2026-08-10", "arrival_date_to": "2026-08-30" }, "type": "tool_call" } А уже потом наш код берет name, берет args и выполняет нужный инструмент И вот между этими двумя шагами можно вклиниться У меня это всплыло на датах Было два кейса: 1. Пользователь говорит: “хочу круиз в мае” Если сейчас сентябрь, то логично искать май следующего года. Но LLM иногда ставила май текущего года - то есть прошедшую дату 2. У gpt-4.1-mini были проблемы с февралем 2026 Она периодически считала, что там 29 дней В итоге я починил это не промптом, а исправлением аргументов функцией перед вызовом инструмента 1. LLM сгенерировала, что хочет tool call 2. Если это "search_cruises" - Проверяем даты. Исправляем год, если месяц уже прошел - Проверяем количество дней в месяце, исправляем 3. Возвращаем исправленный tool call обратно в пайплайн — как будто это и был ответ LLM Для остального пайплайна это выглядит так, будто модель сама сразу вызвала инструмент с правильными аргументами Работает безотказно

Пока писал пост про перегрузку LLM-промпта, понял, что упустил важное ограничение: ответ агента сразу стримился пользователю. Нельзя, чтобы промежуточные размышления модели не должны были быть видны пользователю, поэтому reasoning вслух я фактически запретил. Получился странный сетап: модель должна следовать сложной логике промпта, но не может размышлять. Ей нужно сразу понять задачу, выбрать нужные инструменты, удержать ограничения, не нарушить формат и начать писать user-facing ответ. То есть сложную логику надо было “проризонить” внутри, без размышлений. В таком режиме complex instruction following деградирует сильнее. И тогда разбиение на planner + executor выглядит уже не просто как способ разгрузить промпт. Это попытка жестко задать архитектуру рассуждения модели на уровне графа выполнения. Planner думает, определяет состояние по бизнес логике и даёт план. Он размышляет вслух. Executor вызывает инструменты и пишет ответ пользователю. Это происхожит все ещё молча, но уже работает лучше, потому что задача упрощена. По сути, это schema-guided reasoning, но вынесенный из промпта в алгоритм. Не “модель, пожалуйста, рассуждай вот так”, а сам порядок промптов и их цель добавляет рассуждение каждый раз. Возможно, если бы я мог позволить модели свободно рассуждать перед ответом, проблема была бы не такой критичной. Но если reasoning нельзя показывать пользователю, то им все равно нужно как-то управлять. Вывод для меня такой: complex instruction following ломается не только из-за длинных промптов. Иногда проблема в том, что модели не дали безопасного места, где она может подумать. А если такого места нет, его приходится создавать архитектурно. P.S. интересно услышать ваши подходы к тому, как добиться от LLM следования сложной логике!

ReAct-промпт стал монолитом Это был узел в агенте, который искал круизы и вел пользователя по процессу бронирования. Тот самый, который упоминался в посте выше. В этом агентском цикле модель должна была делать tool calls по инструкциям, а затем отвечать пользователю. Пока бронирований не было, всё работало нормально: агент искал круизы, уточнял параметры и показывал варианты. Алгоритм был достаточно простым. Потом добавилась booking-логика. Причем уже заметно сложнее: с явными состояниями, переходами и запретами. И в одном промпте оказалось сразу три ответственности: — определить бизнес-сценарий — выбрать и вызвать нужные инструменты — отформатировать ответ пользователю Сценариев становилось больше. Появлялись исключения, запреты, новые шаги логики. При этом дообучать модель мы не могли. Пошли ошибки: — неправильно определялись сценарии — пропускались шаги — игнорировались важные запреты — да, те самые, которые написаны капсом и с восклицательными знаками Проблема была в том, что один промпт пытался быть сразу planner’ом, tool executor’ом и formatter’ом. Для LLM это превращается в complex instruction following: много ограничений разного типа внутри одного вызова. Формально — один промпт. По факту — несколько задач в одном forward pass. Решение было не в том, чтобы еще раз “лучше написать промпт”. Мы разделили узел на два этапа: — planning: определить сценарий и план действий — tool execution: выполнить нужные вызовы После этого стало проще понимать, где ломается логика: на выборе сценария или на исполнении. Следующий шаг — отдельно вынести presentation logic. Главный вывод: когда промпт начинает содержать бизнес-логику, он становится кодом. А код нужно декомпозировать. Благо, на моем любимчике LangGraph это легко провернуть

Агенту нельзя просто дать backend API и ждать магии Делали простой сценарий: — есть LLM-агент — есть API сервиса поиска круизов — есть клиент, который пишет: “хочу круиз из Казани в июле на 5 дней” Задача агента — вызвать поиск и вернуть подходящие варианты. Казалось бы, всё просто: берем метод API, заворачиваем в MCP tool, описываем параметры и даем агенту. Формально работает. Но на практике быстро выяснилось, что tool получился не “LLM-friendly”, а “backend-friendly”. То есть удобный для кода, но хрупкий для модели. И в какой-то момент стало понятно: проблема не в агенте, а в интерфейсе, который мы ему дали. Антипаттерн 1 — цепочка вызовов вместо одного Проблема: инструмент поиска принимал не человеческие сущности, а внутренние id: города, теплоходы, направления, стоянки. Поэтому агенту приходилось сначала вызывать tool-маппинг “название → id”, а потом уже search_cruises. Что ломалось: — модель забывала вызвать маппинг — вызывала его не для всех сущностей — путала полученные id между параметрами: cityStart, cityEnd, cities Короткий вывод: если пользователь говорит названиями, а инструмент требует id, мы заставляем LLM быть не ассистентом, а glue-code между UI и базой данных. Фикс: принимать в LLM-facing tool названия: — город отправления: Москва — теплоход: Беда — направление: Волга А id-резолвинг делать внутри инструмента. Антипаттерн 2 — непопулярные типы аргументов Проблема: некоторые параметры API были типизированы странно. Например, одиночное значение передавалось как массив: не durationFrom = 7, а durationFrom = [7]. Что ломалось: — модель передавала скаляр вместо массива — массив не там — не тот shape — параметр вообще пропускался Короткий вывод: LLM лучше работает с boring-типами: string, number, boolean, простые объекты вроде min/max. Необычная форма данных — это не нейтральная backend-деталь, а дополнительная когнитивная нагрузка. Фикс: Было: — durationFrom: [7] — durationTo: [10] Стало: — duration_days_min: 7 — duration_days_max: 10 Или один понятный объект: duration_days: от 7 до 10 Антипаттерн 3 — плохие имена параметров Проблема: параметры назывались как поля backend API, а не как понятия из пользовательского запроса: cities, dateTo, costFrom, category_id, motorships. Что ломалось: модель путала семантику. Например, cities может значить город отправления, город прибытия, стоянки, города маршрута или просто направление. dateTo тоже неочевиден: это дата отправления “до” или дата прибытия “до”? Короткий вывод: имя параметра — это часть prompt’а. Если имя требует знания внутренней модели данных, LLM начинает угадывать. Фикс: Было: cities, dateTo, costFrom Стало: must_visit_cities_or_landmarks, departure_before, price_min_rub Да, имена становятся длиннее. Но для LLM это плюс: название параметра одновременно работает как мини-инструкция. Главный вывод Хороший tool для агента — это не thin wrapper над backend API. Backend API проектируется под код: id, внутренние типы, короткие поля, цепочки методов. LLM-facing tool лучше проектировать под модель и пользовательскую задачу: — одно пользовательское действие = один tool — человеческие названия вместо внутренних id — простые boring-типы вместо legacy-форматов — говорящие имена параметров — минимум промежуточного состояния Иначе получается странная ситуация: модель вроде умная, MCP вроде подключили, API вроде рабочий — а агент всё равно хрупкий. Потому что для LLM tool — это не endpoint. Это UX.

Всем привет! Меня зовут Егор, на этой неделе канал веду я Я эдакий фулстак мл - начинал с CV в медицине, а потом в банке, а затем делал агентов и обучал VLM (и даже чуть-чуть рексис). Веду канал @yet_another_mle Я, как и многие, тоже подвержен LLM-ой лихорадке, поэтому на этой неделе хочу поразбирать случаи из практики разработки агентов. Должно быть интересно!

Неделя авторства тут пересеклась с организацией хакатона, поэтому не успел написать побольше постов. Надеюсь, было интересно! Напоследок поделюсь тем, каково делать PhD в Германии (точнее в Мюнхене, так как Германия довольно разная). Офигенно. Если послушать людей или почитать чаты, многие жалуются на переработки – это, конечно, не 40 часов в неделю – и низкие зарплаты. Если сравнивать с индустрией, то это так, но низкой я бы зарплату не назвал. Мне её хватило, чтобы посетить три десятка стран (ох и запарился я их перечислять при недавней подаче на визу в США). И это я ещё по должности не иишник – у них зп на треть выше. Ну и да, на пхд надо идти с готовностью работать много Сама пхд-программа порой подкидывает невероятный опыт. Недавно был на ретрите по написанию статей в Альпах с отдельной комнатой и ресторанной едой всю неделю. Для меня – бесплатно. До этого ездил на конференцию в официально самое красивое место Европы, на другую в Сингапур и на летнюю школу в Оксфорд. Полезно для работы и невероятно круто В общем, PhD – это сложно, но кайфово. При определённом складе ума и щепотке удачи

Другое важное направление – диагностика болезней и стратификация пациентов. На языке машинного обучения это классификация и кластеризация. Вам дают какие-нибудь данные и нужно понять, что за болезнь у человека или есть ли там какие-то интересные кластеры, которые врачи не видят. Например, не все пациенты реагируют на лечение. Что-то в них отличается, но что? Есть надежда, что это поможет понять машинное обучение Особенно это важно в исследованиях рака, где у каждого пациента по сути уникальная болезнь, а лекарства работающие у одних не срабатывают у других. В этой области на слуху стартап Noetik. Они используют данные пространственной транскриптомики. Это как картинки из под микроскопа, только вместо 3 цветовых каналов есть тысячи каналов, каждый из которых показывает активность определённого гена. Дальше компания тренирует masked автоэнкодер – прячет часть. картинки и просит нейросеть восстановить спрятанное по окружению. Пример на видео Так компания надеется, что нейросеть во-первых выучит биологию и ей можно будет задавать counterfactual вопросы – что изменится, если активность вот этого гена будет вот такой? А также, хочется верить, можно будет кластеризовать (мы называем это «стратифицировать») пациентов и понять, кому нужно какое лекарство

Примерно каждый первый стартап по машинному обучению в медицине занимается разработкой лекарств. Что это означает? В идеальном мире – вы запихиваете в алгоритм данные пациента (например, медицинскую карту, результаты анализов или снимок из микроскопа), а он говорит вам какое лекарство нужно применить, чтобы пациент выздоровел. А если такого лекарства ещё не придумали, генерирует химическую формулу новой молекулы. Она работает так как надо без побочных эффектов, а ещё легко и дёшево синтезируется. Мы от этого идеального мира ещё ох как далеко Здесь есть несколько сложностей. Одна из них – representation learning. Пока не существует хороших способов представления молекул, а их пространство ведёт себя очень непредсказуемо. Есть такой термин как «activity cliff» – небольшое изменение в составе молекулы может приводить к огромному изменению её активности. Пример на картинке, голубые числа снизу – активность на логарифмической шкале (pK) Пока страются отработать методы на более простых задачах, таких как классификация лекарств по данным. К примеру, капают на клетки разными лекарствами, смотрят на фото из микроскопа как изменяется их внешний вид и тренируют нейросетку распознать по этим снимкам лекарства. Именно таким занимается компания Recursion из поста повыше. Так можно обкатать методы, собрать данные и возможно однажды решить обратную задачу – задать, какие мы хотим получить клетки, и попросить алгоритм выдать формулу нужного лекарства

Как вообще применяется машинное обучение в биологии? Со стороны инструментов – примерно так же, как везде. Если вы анализируете картинки, применяемые инструменты те же самые, что и в других областях. Например, визуальный трансформер DINO, который мета презентует на картинках собак и сендвичей, также успешно применяется для сегментации опухолей. А если вы работаете с естественным языком, никто не помешает натравить трансформеры на ДНК вместо текста из интернетов (здесь хорошим примером будет AlphaGenome). Не всегда это работает напрямую, но в любом случае пересечение методов с другими областями очень сильное Что отличается – специфика данных, их количество (как в большую, так и в меньшую сторону) и зачем эти методы применяются. Основными задачами по важности и количеству влитых в них денег являются разработка лекарств и диагностика болезней. Первым занимается, например, Isomorphic Labs – дочка Дипмайнда, развивающая успех моделей для предсказания структуры белка. Их цель – «решить все болезни». Амбициозно, но если у кого-то это и получится, то у Дипмайнда Вторая задача – диагностика или на языке машинного обучения – классификация по каким-либо данным. Например, предсказание диагноза по картинкам с микроскопа. Здесь есть поучительная история для машинного обучения в целом. Глядя на успех свёрточных нейросетей для работы с изображениями, Хинтон в 2016 году предсказал, что радиологи – врачи, смотрящие на картинки и делающие по ним вывод – будут не нужны через 5 лет. Через 10 лет после этой фразы радиологов больше, чем когда-либо (прикрепил мем в тему). Почитать, почему так вышло, можно вот тут. Оказалось, что работа радиологов чуть сложнее, чем классификация картинок, а внедрение нейросеток в медицину – тяжелее, чем максимизация F-скора Ещё, конечно, есть фундаментальная наука, где приложения машинного обучения ограничиваются только фантазией исследователей: от расшифровки языка китов до изучения иммунной системы бактерий. Но так как я из прикладных областей, буду рассказывать о них

Идеальный пример приложения машинного обучения к биологии. Компания Recursion разрабатывает лекарства, тестируя огромное количество химических веществ на клеточных линиях и наблюдая как клетки меняют вид под воздействием разных молекул. Раньше учёные полагались на окрашивание клеток – безумно красивый биологический метод, позволяющий по-разному окрасить органеллы: ядро, элементы клеточного скелета и другие. Однако с развитием машинного обучения оказалось, что это не обязательно. Нейросетевая модель может распознать элементы клеток по обычному изображению со светового микроскопа! Результат неотличим от применения более дорогого и сложного окрашивания клеток Помимо экономии времени и денег на красители, это ещё и позволяет смотреть на динамику. Раньше это было невозможно: красители повреждают элементы клетки и она ведёт себя по-другому, а протокол окрашивания требует убийства и фиксации клеток Быть может, и другие методы можно упростить #биология@chelovek_nauk#програмирование@chelovek_nauk

Начну со своего любимого примера приложения ML к биологии. Если вы когда-нибудь смотрели в микроскоп на биологические препараты, то знаете, что без окраски там сложно что-то увидеть. Понятно, что какие-то структуры есть, но чтобы из различить, человеческому глазу нужна окраска препаратов. А вот компьютерам, оказывается, не нужна! И это хорошие новости для разработки лекарств