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 к биологии. Если вы когда-нибудь смотрели в микроскоп на биологические препараты, то знаете, что без окраски там сложно что-то увидеть. Понятно, что какие-то структуры есть, но чтобы из различить, человеческому глазу нужна окраска препаратов. А вот компьютерам, оказывается, не нужна! И это хорошие новости для разработки лекарств

Привет! Я Вова и я применяю машинное обучение к биологии, а ещё веду канал человек наук. Сейчас я заканчиваю PhD в институте вычислительной биологии в Helmholtz Munich. Буду делиться с вами интересностями из биологии в ближайшую неделю! Мы работаем с данными single-cell транскриптомики – это когда измеряют активность генов в сотнях тысяч клеток. Получаются очень большие данные – таблицы размером сотни тысяч клеток на десятки тысяч генов. Задача моего PhD – понять как связать такие данные с клиническими – табличками поменбше, содержащими информацию о пациентах. Так мы можем лучше понять развитие болезней, рано их детектировать или даже предложить возможное лечение На картинке – пример как PhD влияет на человека. На самом деле, на втором фото я невыспавшийся после хакатона и дедлайна на конференцию, обычно я всё же выгляжу получше

Продолжаем про агентскую память [PART 3] Мне ближе био-мотивированные системы памяти Markdown, конечно, нравится: просто, наглядно, редактируемо руками. Но хочется, чтобы агент не просто хранил факты, а становился лучше после взаимодействий со мной. Самый…

Ещё не забыли? Продолжаем про агентскую память [PART 2] ⬅️ Сперва прокомментирую графики из прошлого поста! На нижней половине вроде всё понятно, поясню за верхнюю. По оси X: на сколько структурированными хранятся знания. Закинули PDF в агента, на выходе…

Память для LLM агентов [PART 1] Привет... Спишь? Тема оказалась огромной, поэтому разбиваю на несколько постов. Сегодня — обзор ландшафта, общие паттерны и картинка, куда движется индустрия. Далее — разбор одного моего любимчика и сравнение с остальными.…

Память для LLM агентов [PART 1] Привет... Спишь? Тема оказалась огромной, поэтому разбиваю на несколько постов. Сегодня — обзор ландшафта, общие паттерны и картинка, куда движется индустрия. Далее — разбор одного моего любимчика и сравнение с остальными. RAG — это умный поиск, а не память! В моей голове есть образ ассистента, который реально ускоряет тебя в бытовых задачах. Но для этого он должен запоминать прошедшие интеракции — причём сам, без тычков «пожалуйста, запомни это». Как человек: в живом общении подмечает интересные факты, просьбы, требования и использует их в будущем. Без этого колонка — просто продвинутый поисковик и переключатель треков, не более. Недавно наш слоняра Андрей Карпатый написал твит, а позже разжился Gist на Github с более подробным описанием системы курирования знаний с помощью LLM. Суть: RAG — stateless, агент каждый раз «переоткрывает» знания, тратит токены впустую. Нужна постоянная, накапливаемая, «живая» память, которую курирует LLM по сути для себя, опционально под вашим контролем. Тут же полезно вспомнить как устроена память у человека. Из когнитивной психологии выделяют несколько типов: 😳 Рабочая — то что держишь в голове прямо сейчас, это ~ context window у LLM 🤠 Эпизодическая — конкретные события с контекстом: что, где, когда ~ «12 апреля посреди ночи дописывал этот пост» 🌟 Семантическая — абстрагированные факты: «юзер не любит азиатскую кухню», «в этом проекте не используем глобальные переменные» 🧠 Процедурная — паттерны действий: «как заказать такси через сервис X» Общие подходы За последние полгода я отсмотрел, наверное, с десяток проектов и статей. Если смотреть на решения, выделяются три крупные категории: 📁 File-based [1] Основа — Markdown файлы в формате вики. LLM компилирует сырые заметки в структурированные документы, при необходимости связывает их друг с другом бэклинками. Обязательно хотя бы по одному файлу для каждого из упомянутых выше типов памяти. Без БД и инфраструктуры. Карпатый описал это так: «Obsidian — IDE, LLM — программист, Wiki — кодовая база». Ровно это же активно применяется в OpenClaw с его MEMORY.md и ежедневными YYYY-MM-DD.md. + Плюсы: zero-ops, прозрачно, человекочитаемо. – Минусы: плохо масштабируется, часто требуют ручной модерации, без механизма ротации или архивирования документов базы разрастаются и превращаются в месиво, которое только путает агента и нереально отсмотреть человеку. 🤴 Graph-based [2] Основа — графовая база знаний. LLM преобразует знания в сущности и связи между ними. Примеры — Graphiti от Zep, LightRAG от HKUDS. + Плюсы: явные связи, можно делать запросы на обход графа в глубину/в ширину, хорошо для Enterprise с огромными, раскидистыми, но структурированными данными. – Минусы: нужна графовая БД, сложный setup, медленнее (vs векторный поиск). 🧠 Brain-inspired [3] Способ хранения вторичен, основа — организация данных и процедуры, вдохновлённые устройством мозга и нейронаукой: есть забывание данных (decay), укрепление при вспоминании (reinforcement), гибридные стратегии поиска. Hebbs, MemPalace, Vestige — все отсюда. + Плюсы: максимально близко к тому, как работает память человека, хороши для долгосрочного использования. – Минусы: сложнее в настройке, в понимании, некоторые идеи ещё экспериментальные. Как правило, в таких системах требуется тюнинг настроек/параметров под конкретный домен данных. И, конечно, никто не запрещает всё это миксовать! Репы про Agent Memory на GitHub штопаются сейчас не хуже JS фреймворков. Те, что на картинке просто успел посмотреть/поковырять и раскрою далее

Привет, читатель! Меня зовут Олег, ближайшие 7 дней я стою у пульта и диджею вам постики. Мне 28 лет, родом из Томска, живу в Питере, окончил бакалавриат по направлению «программная инженерия» 🆒 Сейчас у меня три основных направления деятельности: (1) Full-time ML Engineer в группе исследований компании Звук — музыкального стриминга от зелёной компании. 🔄 В работе занимаюсь задачами на стыке Аудио, LLM и семантического поиска, а в этом году активно пишем и публикуем статейки на конференции. (2) Сооснователь в бренде аксессуаров 💅 @hiacleworld. Выполняю роль CTO — отвечаю за IT инфраструктуру, и делаю ИИ-инструменты для небольшой, но эффективной команды в 5-7 человек. (3) На остаток времени и сил пилю пет-проекты. Часть из них про железо, часть про софт и модельки. Ключевой — аналог колонки типа Алисы или Sberboom, но действительно умной: мультимодальная LLM в формате агента, инструменты, и всё это офлайн на одноплатном компьютере при real-time и минимальной задержке. Короче edge + voice AI со всеми вытекающими. 😥 Помимо этого, с переменным успехом веду канал ❤️ @alisaolega, где в основном делюсь статейками, инструментами, стримлю прогресс по проектам. А ещё собираю комп с двумя RTX 3090 в форм-факторе 10 литров, кастомный NAS, спаял раздельную клавиатуру Ferris Sweep. А когда всё-таки выхожу из дома, катаюсь на шоссейном велике 🚜 О чём ждать посты? • О мультимодальных LLM — с ними много работал последнее время! Немного про RAG и память для агентов, обязательно будут подборки полезных инструментов, библиотек, сайтов. • На своём опыте расскажу в каком формате и на каких поверхностях стоит интегрировать ИИ в небольших командах. • Возможно, расскажу немного про душный инференс на edge устройствах, потому что это одно из ключевых направлений работы над колонкой. Ну и, конечно же, будут спонтанные посты по секретным заранее неизвестным темами, потому что тайм-менеджмент и подготовка постов заранее — не моё! Но ведь так даже интереснее, да? Да?! 🔫

Мем дня На днях Дарио Амодеи (ceo оранжевых) заявил: Инженеры в Anthropic говорят: «Я больше не пишу код. Я просто позволяю модели писать код, а я его редактирую» А сегодня у нас походу новый самый быстрорастущий репо в истории https://github.com/instructkr/claude-code У антропиков утек claude code из сейфа))) Че ребят еще какие нибудь гайды по вайб кодингу надо или пока сами попишете? 😄 Форков почти в два раза больше чем звезд💀 За 50 минут 13к форков vs 7к звезд, безумие...

Заключение Идея серии постов в том что разработка с Claude Code становится эффективней если есть выстроенный workflow. Я не призываю работать так как работаю я — напротив, автоматизируйте процессы так как удобно вам! Я лишь показал пример и немного рассказал об инструментах которые могут в этом помочь. Возможно что-то забыл — если вас интересуют конкретные кейсы то всегда welcome ❤️