Корм для моделей

Самая дорогая модель нужна реже, чем кажется

Одна сборка задач в моем конвейере разработки разворачивает 40-80 AI-агентов. Поставь на каждое место флагманскую модель, и разоришься раньше, чем доедешь до релиза.

Вечерами у меня работает команда AI-агентов: оркестратор раздает задачи, дев пишет код, остальные собирают данные, проверяют факты, готовят сводки. Конвейеров накопилось несколько: сводки, извлечение знаний из заметок, полный цикл разработки. И в каждом один и тот же вопрос: внутри агента крутится языковая модель, а модели стоят по-разному, между флагманом и самой дешевой разница в десятки раз. Вопрос «кому какую дать» из технического стал управленческим.

Самый свежий конвейер: разработка в Claude Code. Десять этапов: проверка требований, дизайн, пользовательские сценарии, план, сборка, тесты, документация, ревью, исправления, релиз. Распределял модели так же, как распределял бы людей:
🧠 Fable, самая дорогая, стоит только там, где ошибка дороже всего: планирование и ядро системы
🔍 Opus на всей критике: ревью кода, безопасность, атаки на архитектуру до старта разработки, опровержение чужих находок. Умение сомневаться здесь отдельная профессия
⚙️ Sonnet, рабочая лошадка: компоненты, тесты, документация, исправления. Основная масса работы
🏃 Haiku, самая дешевая: прогнать тесты и вернуть отчет. Думать не надо, надо не ошибиться в отчете

В конвейере сводок тот же вопрос решал перебором: гонял шесть связок «сборщик → валидатор → редактор» на одних и тех же данных и мерил результат. Победила связка DeepSeek → GPT-5.6 → DeepSeek: 90% точности, ноль выдумок, ноль пропусков. Выбор сделали цифры.

Из обоих конвейеров вывелось одно правило: на каждую роль ставится самая дешевая модель, которая проходит проверку. Ключевое слово «проверка». Правило работает, только когда контроль встроен в сам конвейер: у меня каждую находку ревью пытается опровергнуть отдельный агент, спорные решения сводит агент-судья, находка без попытки опровержения не считается подтвержденной. Без этого экономия превращается в лотерею.

Индустрия приходит туда же. liteLLM опубликовали эксперимент: роутинг моделей по фазам задачи дал то же качество и минус 46% стоимости. В свежем бенчмарке проверяемого кода средний Sonnet обошел дорогой Opus: 96.4% против 89.3%. А в рекомендациях для автономных агентов флагману отводят 5% вызовов, тогда как 70% работы отдают самым дешевым моделям.

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

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

🧠 Из чего состоит память AI-агента

Полгода назад завёл первого агента и быстро понял: память у агента не одна. Слоёв несколько, каждый решает свою задачу, и почти каждый пришлось выстрадать. Разбираю по порядку.

Слой 1 — личность. Файлы, которые агент читает при старте каждой сессии: кто он, что делает, какой у него характер, кто его человек и как с ним говорить. Это врождённая память — она вшита и не теряется никогда. Агент всегда знает, кто он. А вот всё остальное — нет.

Слой 2 — рабочая память. Сам разговор. Живёт, пока открыта сессия: темы, договорённости, ход задачи. Закрыл сессию — слой обнулился. Первые недели я каждое утро пересказывал агенту вчерашнее: что за проект, на чём остановились, что решили.

Слой 3 — дневник. Первое лекарство: агент в конце дня пишет файл — что сделано, что решили, что сломалось. Наутро читает и продолжает с того же места. В инструкцию легло правило №1: контекст, не записанный в файл, потерян навсегда. Дневники разрослись до 34 МБ, поиск по словам перестал их вытаскивать — поверх лёг поиск по смыслу: спрашиваю «что там с деплоем» — находит запись, где слова «деплой» нет. Тут же грабли: у одного агента этот поиск месяц возвращал ноль. Индекс смотрел в пустую папку, файлы лежали в соседней. Агент выглядел здоровым — просто «не помнил» целый продукт.

Слой 4 — долгосрочная память. Дневники — это хроника, а нужна выжимка: отдельный файл с действующими решениями и фактами. За размером следит cron-надзиратель с порогом 20 КБ. Однажды файл распух до 28 КБ — выводы задублировались, агент читал больше, а помнил хуже. Вылечили чисткой.

Слой 5 — сны. Ночью агент пересматривает день: важное из дневников переносит в долгосрочную память, мусор отсеивает. Схема скопирована у человеческого сна. Работает.

Слой 6 — общий граф знаний. Память команды: факты, связанные между собой, доступны всем агентам сразу. Строился с третьей попытки. Первый граф дорос до ~1200 узлов и умер: не было ни валидации против галлюцинаций, ни нормальной архитектуры работы с данными. Второй строил граф локальной моделью из сырых данных — прожил 4 дня: медленно и связи хуже. Третий развернул схему: локальная модель размечает и обезличивает данные у меня на машине, и только потом облако строит из них граф. Мощная модель работает только с обезличенными данными. Шрам остался и здесь: перезапущенный служебный скрипт пересоздал базу и стёр 18 225 поисковых индексов, которых не оказалось в бэкапе. Пересчитывали с нуля — и с тех пор бэкапится всё.

Итого шесть слоёв: личность → рабочая память → дневник → выжимка → сны → общий граф. Сейчас в графе 98 939 фактов и 88 441 связь. Ни один слой не появился из красивой архитектуры — каждый рождался, когда предыдущего переставало хватать. Зато по утрам я больше ничего не пересказываю.

К посту про скиллы — где брать готовые. Есть открытый каталог skills.sh от Vercel: больше миллиона скиллов под Claude Code, Codex, Cursor и ещё два десятка агентов.

Ходить по нему самому не обязательно: попроси агента — он сам найдёт в каталоге самые подходящие и популярные скиллы под твою задачу и установит. Ориентир внутри — счётчик установок: у каталога живая телеметрия, это честнее звёздочек на GitHub.

Одна оговорка: ревью в каталоге нет, публикуется всё подряд — отсеивают только провалившее проверки безопасности. Так что перед установкой чужой скилл стоит прочитать, благо это обычный текст.

Скилл — это как научить агента, а не написать код

В прошлых постах я выложил два архива pii-anon-service — код, который маскирует персуху и умеет её вернуть обратно. Полезная штука, но лежит мёртвым грузом: чтобы агент ей пользовался, кто-то должен объяснить ему когда и как её звать. Вот это объяснение и есть скилл.

Скилл — папка с файлом-инструкцией (SKILL.md) и парой скриптов. Внутри человеческим языком: «когда просят обезличить выгрузку — берёшь anonymizer_core, гоняешь через mapping, отдаёшь GREEN-версию». Агент читает это как рецепт. Не переписываешь код — описываешь навык.

Где брать. GitHub и ClawHub — там чужие скиллы уже готовы. Скачал, положил агенту, попросил «освой» — и он умеет то, чего вчера не умел.

Как сделать свой. Момент рождения простой: ты только что подключился к чьей-то API, разобрался с конкретной таблицей, собрал отчёт руками. Пока помнишь как — говоришь боту: «оформи это навыком». Он складывает шаги в SKILL.md. Дальше навык живёт сам, тебе не надо помнить.

Самое интересное — скилл ходит между агентами. Я собрал навык работы с pii-anon-service, скинул файл товарищу, он сказал своему боту «освой» — и его агент теперь чистит персуху так же, как мой. Никакой пересадки кода, никаких созвонов «как ты это настроил».

Получается общий язык. Код решает задачу один раз у тебя. Скилл делает решение переносимым — между твоими агентами и агентами соседей.

📦 Примеры к посту выше — забирайте и щупайте

Два рабочих примера. Не идеальные, но это то, с чем можно поработать со своими агентами.

pii-anon-service — то самое маскирование с демаскированием из поста, упакованное в сервис для команды. Загружаешь XLSX/CSV/TXT — получаешь обезличенную версию: consistent-маски [PERSON_N], [EMAIL_N], [PHONE_N], ИНН, СНИЛС, telegram-ники. mapping.json остаётся локально, обратное восстановление — через /deanonymize. Запуск: docker compose up -d → localhost:8000.

v2 — то же плюс второй проход: локальная модель через Ollama (qwen2.5:7b) долавливает имена, которые regex пропустил — редкие, иностранные, в падежах.

Всё крутится на своей машине, ПДн наружу не уходит. README внутри.

🔒 Как скормить модели данные с персухой и не спалиться

Любая задача, где в тексте ФИО, телефоны, почты, ИНН, а обрабатывать хочется облачной моделью — это вопрос: как отдать модели смысл, но не отдать людей. Отлаживал это всё лето. Три подхода, каждый под свою задачу.

Маскирование с демаскированием. Основной механизм под поток данных. Имена меняются на [PERSON_1], почты на [EMAIL_1], соответствие маска ↔ реальное значение сохраняется в таблице. Модель работает с масками, на выходе реальные данные подставляются обратно по таблице.

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

Полное удаление. Вырезаешь персуху совсем — «кто-то написал кому-то». Под узкий массив для дашборда, где нужны только цифры и структура, вполне работает.

Псевдообезличивание. Компромисс, когда текст должен остаться читаемым для человека:
Иванова Виктория Сергеевна → Иванова В.
+7 (926) 710-76-35 → +7 (XXX) XXX-XX-35
ivanova@company.ru → i***@company.ru
ИНН 7707083893 → 77•XXX•XXXX

Аналитик видит связный текст, модель различает людей, восстановить полное ФИО нельзя. Под дашборды годится, под полный поток — ограниченно: защита слабее масок.

Как устроен pipeline на масках.

Сырьё падает в RED — папку с оригиналами, chmod 700. Облако туда не заглядывает никогда. Скрипт-анонимайзер прогоняет данные и складывает маскированную версию в GREEN. В облако уходит только GREEN.

Таблица соответствий — mapping.json: на сегодня 1 245 персон, 3 483 телефона, 1 969 почт, 19 070 идентификаторов. Лежит в RED под chmod 600, машину не покидает.

На выходе — демаскирование: модель отработала на масках, финальный текст прогоняется через второй скрипт, и [PERSON_47] превращается обратно в реальное имя. Та же таблица работает в обе стороны: имя → маска на входе (например, для поиска по архиву), маска → имя на выходе.

Где маски протекают.

Самое сложное — найти все имена. Телефоны, почты, ИНН ловятся regex детерминированно, ложняков ноль. А ФИО в свободном тексте regex не берёт: склонения, производные, слитное написание — «ЕвгеньевичМиженский», «Бровкине», «Вадимовна». На корпусе из 2 505 документов после первой версии анонимайзера осталось 2 821 утечка — 11%.

Второй слой — NER через локальную qwen3:14b: модель находит имена в любом месте текста, секунды на документ. Медленное другое — LLM-проверка, безопасен ли фрагмент для отправки в облако: 10 фрагментов в минуту, на полном архиве это 160 часов.

Третий заход — компонентная маскировка ФИО: фамилия, имя, отчество отдельно, плюс падежи. Утечки 2 821 → 71. В 40 раз меньше.

Где имена утекают не из текста.

Самая незаметная дыра — метаданные. NER читает тело письма, а поля sender, recipient, organizer, attendees не видит. Имена текли именно оттуда. Решение: эти поля маскируются принудительно, по структуре, без всякого NER. Правило: каждое поле, где может быть человек — маскируется всегда.

Принцип.

513 фрагментов после всех проверок так и не прошли в GREEN — остались локальными. Если фрагмент мог протечь — не пускаем. Лучше потерять кусок данных, чем утечь. Не надеяться, что замаскировал — проверять, что не утекло.

Облако никогда не видит RED. Если видит — это не баг, это тревога.

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

🔐 Безопасность агентов — это не паранойя, а гигиена

Даёшь агенту доступ к почте, файлам, календарю — и он начинает реально работать. Ровно тут он из игрушки превращается в того, кто дотянется до лишнего. Про это забывают на радостях, что «оно само делает».

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

«Разграничь доступы по ролям». Не всё подряд, а расписать: какому агенту какие данные нужны, а какие нет. Пусть предложит схему и закроет лишнее. Как учётки у сотрудников — у каждого своё.

«Проверь обходные пути». Прямой запрет — половина дела. Пусть поищет, где утечёт в обход: через общую память, связанные записи, хитрый запрос к базе. Дыра почти всегда в неочевидном месте.

Персональные данные в облако нельзя. Не «нежелательно», а нельзя по закону: ПДн не вывозят за границу, а облачная модель — это заграница. Мелькнули имя и фамилия в запросе к ChatGPT — уже нарушение. Порядок такой: сначала пусть агент построит конвейер, который обезличивает данные локально, скриптами, без облака. Проверь на ненастоящих данных, глазами убедись, что чисто. И только когда труба готова — пускай в неё реальное. Сначала труба, потом вода.

«Сломай свою же защиту». Пусть агент прикинется другим и дотянется до закрытого, прогонит нагрузку, найдёт где протекает. У меня так набралось 60 проверок — каждая ловила на дыре.

Не нужно быть инженером. Задай агенту правильные вопросы — и он сам выстроит себе границы.

🖥 Где живёт автономный агент и куда его поселить

Автономный агент работает в фоне круглосуточно. Значит ему нужен дом — железо, которое тихо стоит и не выключается. Не рабочий ноут, который закрываешь и уносишь, а отдельное устройство.

Первая развилка — своя железка или VPS.

VPS — это арендованный сервер в чужом дата-центре. Не покупаешь железо, платишь за мощности помесячно: недорого, поднимается за минуты, ничего не гудит дома, доступ отовсюду.

Капкан — в персональных данных. По закону база с ПДн граждан России должна физически стоять в России. Значит заграничный VPS под такие данные отпадает сразу — сервер в Европе это уже нарушение локализации. Российский VPS формально закон не нарушает, но ты кладёшь чужие имена и контакты на чужие мощности, которые не контролируешь. Поэтому правило простое: персональные данные — только на железе, которое стоит у тебя. VPS оставь под задачи, где данных о людях нет вообще.

Своя железка — мини-ПК, Mac mini, старый ноутбук в углу. Холодное, бесшумное, под полным твоим контролем.

Вторая развилка — крутишь ли ты модель прямо на этой машине.

Модель локально не нужна — бери мини-ПК на Linux. Дёшево, ест мало, тянет агента, который ходит в облачные модели по API. Тяжёлая работа уходит наружу.

Модель нужна локально (обезличить данные перед облаком) — интереснее Mac mini. Фишка в унифицированной памяти: оперативка работает как видеопамять. Медленнее настоящей VRAM, но хватает крутить Qwen3 7B на 16 гигах, без видеокарты за конские деньги.

На железо ставится хост, где живёт агент со своей памятью и доступами. Из популярного — OpenClaw и Hermes.

🤖 Что такое AI-агент и чем он отличается от ChatGPT в браузере

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

ChatGPT в браузере — это собеседник. Живёт в своём окне: отвечает, ищет в сети, собирает инфу под запрос. Но за пределы чата не выходит и ничего не делает без прямого вопроса. Ты спрашиваешь — он отвечает.

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

Три типа, которые встречаешь на практике:

🗨️ Чат — просто разговор. ChatGPT, Claude, Perplexity, DeepSeek. Отвечают и ищут в сети, но за окно не выходят.

💻 Кодовые агенты — в редакторе или терминале: Cursor, Codex, Claude Code, Gemini CLI. Пишут код и гоняют тесты по твоей задаче, но в границах проекта.

⚙️ Автономные агенты — стоят на машине и работают в фоне. Свои доступы, своя память, дёргают сервисы и друг друга. Не помощник в окне, а сотрудник на твоём железе.

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

Разница в одном: чат ждёт вопроса, агент работает на задачу. В канале — вся эта кухня на практике, от чата до автономных агентов в проде. Без воды, на реальных задачах и граблях. Будем идти постепенно, от простого к сложному.

📈 Зачем вообще разбираться в AI-агентах

Недавно услышал интересную мысль — поделюсь, она важная.

Разбираться в AI стоит не потому что в 2029-м придёт Skynet, как в «Терминаторе». Причина скучнее и вернее — это обычная эволюция инструмента, и мы её уже проходили не раз.

Когда-то текст печатали на печатной машинке. Ошибся в одной букве — перепечатывай весь лист. Пришёл компьютер, и та же ошибка стала стоить не десять минут, а пару секунд. Инструмент сменился — планка нормы поднялась.

Кто застал прошлое тысячелетие, помнит: в резюме гордо писали «умение работать с Excel», «владение Office». Это было конкурентным преимуществом. Сегодня это даже не строчка — базовая гигиена, само собой разумеющееся.

С AI ровно та же кривая, только быстрее. В этом году и следующем в резюме начнут писать «уверенное владение AI-моделями и агентами» — и это будет выделять. Пройдёт пятилетка — и это станет таким же базовым уровнем, как Excel. Не преимущество, а норма входа.

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

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

Корм для моделей pinned «Корм для моделей Качество AI — это не про модель. Это про то, чем ты её кормишь. Днём я CPO с 70 цифровыми продуктами в портфеле: шесть кластеров, десятки команд, бюджеты и корпоративные ограничения. В 13 продуктах внедряем AI — часть уже в проде, часть…»

Channel photo updated

Корм для моделей

Качество AI — это не про модель. Это про то, чем ты её кормишь.

Днём я CPO с 70 цифровыми продуктами в портфеле: шесть кластеров, десятки команд, бюджеты и корпоративные ограничения. В 13 продуктах внедряем AI — часть уже в проде, часть на пилотах, часть в разработке.

Вечером вайбкожу собственные продукты. Строю The Jarvice и команду из 8 AI-агентов — у каждого своя роль, модель, память и доступы: оркестратор, copilot, разработчик, DevOps, продуктовик, стратег, финансист и агент по здоровью.

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

Что будет здесь:
🧪 Сравниваю LLM на реальных задачах — с цифрами, а не с маркетингом
🏗 Собираю пайплайны и граф знаний на 33 937 атомов
🔐 Пропускаю чувствительные данные в cloud через PII-контур — 22K файлов, 0 утечек
🤖 Проверяю, может ли команда агентов работать без ручного контроля
🎯 Разбираю продуктовые кейсы, цифры и провалы

За красивым AI-демо всегда скрывается длинная кормушка: данные, контекст, память, права доступа, инфраструктура. Показываю, чем кормлю модели — и что они после этого делают.

Channel created