В примере с перцептроном я бы, наверное, чуть подробнее остановился на масштабе входов. Не как критика. Просто это место часто стреляет в практике. В Yario мы разбирали обращения из 2 каналов, WhatsApp и Telegram, и даже простая классификация начинает вести себя странно, если рядом живут минуты ожидания, счетчики сообщений и признаки из текста. Модель легко цепляется за размерность. Нормализацию вы сознательно оставили за рамками статьи?
Узнаваемо до боли, особенно про калькуляторы. У нас то же расхождение, и корень обычно один. Reasoning-токены. На один видимый токен модель льёт 2-3 скрытых, калькулятор считает по видимым, отсюда и кратная ошибка. Мы теперь и клиенту в SLA пишем ёмкость в видимых токенах плюс отдельным множителем накладные на рассуждение, иначе обещание не бьётся с тем, за что реально потеет GPU.
Ещё при сайзинге смотреть стоит на p95 под целевой конкуренцией, средний TPS тут обманывает. Throughput под нагрузкой даже растёт за счёт батчинга, а вот хвост задержек первым ломает ощущение «тормозит». Гарантию давать по p95 на нужном числе диалогов.
Про prefix caching добавлю грабли. Он спасает только если общий префикс байт в байт одинаковый. Любое шаблонное поле в начале промпта, время, имя юзера, id сессии, тихо убивает попадание в кэш. Волатильное в хвост, системный префикс в начало стабильным блоком. Это бесплатные 40 процентов, которые легко потерять.
Сильный разбор, особенно про разрыв между «граф визуально убедителен» и реальной топологией. Глаз тут врёт всегда. Честный сигнал это распределение степеней и доля вершин со степенью <=1, мы как раз гейтим сборку графа по этой доле, до того как доверять поиску.
Про автоматизацию дедупа подтверждаю вашу боль. Двуязычное расщепление и сокращения рвут связность тише всего, а чисто символьный матч (Левенштейн, rapidfuzz) их пропускает, потому что алиас семантический. У нас лучше зашло так. Кластеризация по эмбеддингам, а LLM зовём только на спорные пары у границы. Ручной MAPPING_DICT не тянет тысячи актов, но и полный обучаемый NER с дорогой разметкой нужен не сразу.
Про маршрутизатор в планах. Мы это гоняем, и вывод ровно ваш. Вопросы про цепочку связей уходят в граф, точечный лукап в вектор. Дешёвый классификатор на входе решает куда, а честный отказ при пустом поиске на практике важнее идеального выбора хранилища.
Подход хороший, особенно бинарный pass/fail вместо шкалы. У шкалы в проде слишком много шума, и калибровка руками на сотне кейсов это только подтверждает. Чего мне не хватило в статье, так это разговора про self-preference. Когда судья и генератор из одного семейства моделей, его оценка почти линейно ползёт вверх вместе с тем, насколько он узнаёт собственный стиль, и он постепенно начинает путать «свой» текст с «хорошим». Позиционный сдвиг вы уже лечите сменой порядка, но эта проблема так не уходит. У нас помогло развести генератор и судью на разные семейства и в каждый прогон подмешивать контрольные пары с заранее размеченным руками ответом: если судья на них валится, остальным его оценкам мы уже не верим. Если захочется покопать глубже, на эту тему есть толковый разбор у Eugene Yan.
Самое ценное тут это привязка таксономии ошибок к цене для пользователя. Recoverable против убивающих доверие. У нас на распознавании картинок так же, считаем по стоимости ошибки, а не по голой accuracy. Одна и та же цифра точности может значить и норм продукт, и провал, всё решает, какие именно промахи попали в неисправимые.
Про судью на той же модели соглашусь, но риск не в случайном шуме. Он в скоррелированной слепоте. Судья делит провалы с распознавателем и штампует ровно те ошибки, которые распознаватель и делает. Дешёвая страховка, подсыпать в прогон заранее известные злые пары, гречка против пельменей. Если судья их не ловит, его «всё correct» ничего не значит. Ручной проход по подвыборке у вас как раз это и закрыл.
Калибровку confidence стоит проверять об вердикты. Реально ли низкая уверенность коррелирует с wrong. Сырое число от модели обычно не калибровано, и порог 0.85 легко висит для красоты, пока не сверишь его с фактами.
Аналогия с AF447 точная, и в работе с Claude Code это ощущается. Навык не исчезает. Он смещается. Раньше ценился набор кода. Теперь умение поставить задачу и проверить результат. Пассивный наблюдатель за автопилотом деградирует. Тот, кто остаётся пилотом, нет.
От complacency у нас помогает одна привычка. Перед запуском агента вслух сформулировать, что должно получиться и по каким признакам поймём, что вышло верно. Тогда ты сверяешь вывод модели со своим ожиданием, а не принимаешь диктовку, и внимание не уплывает. Код, который не можешь объяснить и проверить, в коммит не идёт.
Вы скилл-атрофию замеряете хоть как-то, или это пока ощущение? Любопытно, отличается ли деградация у джунов и сеньоров на одном инструменте.
Та же стена у нас в AI-разборе звонков. Сводка готова, менеджер открыл её и закрыл, а решение принял как всегда. Просмотр и правда не равен действию, ровно ваша мысль про график и закрытую вкладку.
Помогло вот что. Любой наш артефакт теперь кончается назначенным следующим шагом с ответственным и сроком, без этого он просто украшение. И меряем мы не открытия дашборда, а сдвинулся ли сам этот шаг в CRM. Сам факт что открыли ничего не говорит, важно поменялось ли поведение после.
У вас в конце вопрос, как отличить посмотрел от изменил поведение. Мы привязываем артефакт к одному решению, которое он должен улучшить, и потом смотрим на это решение в системе, а не на просмотр. И встречный вопрос. На уровнях 1-2 вашей шкалы есть ли вообще смысл городить дашборд, или сперва надо встроить само решение в управленческий ритм, а инструмент подключать уже к 3?
Знакомая боль, и подход правильный. Локальные модели на своей видяхе тут и есть разблокировка, и по деньгам, и по приватности.
Мы недавно крутили похожее, только под коммерцию. Надо было собрать базу фоток БУ-устройств и телефонов для интернет-магазина. Картинки тянули из публичных источников через Serper, закинули около 50 долларов и получили тысячи запросов, этого хватило на приличную базу. Дальше всё перемалывали локально на одной 4070Ti, несколько разных моделей под свои шаги. Вышло на удивление бодро.
Что совпало с вашим опытом. Самой моделью дело не решается, узкое место это дедуп и матчинг грязных входов. У вас EXIF врёт и имена IMG_4348, у нас почти то же на товарных фото. Соберу отдельную статью про этот пайплайн, там интереснее всего как раз матчинг. А дубликаты вы как ловили, по хешу, по эмбеддингам или смешанно?
Полезное сравнение, спасибо. У нас на проде вывод такой же. Мы давно перестали искать одну лучшую модель и роутим по типу задачи. Найти узкое место это recall, тут Qwen и другие дешёвые отрабатывают нормально. Глубокий разбор с тонкой правкой это precision, там фронтир пока стабильнее.
Но главное вы поймали точно. Небезопасный фикс в быстрых победах. Дешёвая модель увереннее ошибается на краях, и применишь её совет вслепую, экономия на токенах вылезет багом в проде. Поэтому у нас всё, что пишет код, идёт через проверку. Компиляция, тесты, ревью. А дорогая модель или человек подключаются только к тому, что проверка завернула. Дёшево и не страшно.
Получается, роутить полезнее по цене ошибки, а не по абстрактному качеству. Триаж дешёвой, необратимое действие дорогой с проверкой. Вы цену ошибки в оценку закладывали, или считали чистое качество против цены прогона?
Спасибо за честный замер. У нас на проде похожая картина. Для большинства задач один сильный агент с нормальным контекстом бьёт команду и по точности, и по деньгам. Цена в разы это ровно наш опыт, каждый лишний вызов умножает токены.
А где мультиагент окупается, по нашим наблюдениям дело не в топологии. Решает другое. Есть ли у шага объективная проверка. Критик как вторая модель со своим мнением на субъективной задаче просто усредняет шум и проигрывает. Другое дело, когда у подзадачи есть внешний верификатор. Тесты, схема, ответ из поиска, компиляция. Тогда критик опирается на факт, и связка генератор плюс проверка выигрывает. То есть тянут шаги с заземлением, а не сами команды.
И авто-выбор паттерна поэтому тяжёлый. Роутеру надо угадать сложность задачи, а это почти сама задача. Не пробовали роутить тупо по наличию внешнего верификатора у шага, вместо предсказанной сложности?
Спасибо, по делу. Собрал у себя почти то же. База знаний в Obsidian, лежит в гите, надиктовываю через macWhisper, дополняю и спрашиваю её через свой телеграм-бот с агентом, правлю из VS Code. Лучше связки Obsidian плюс гит пока не нашёл, всё под рукой и версионируется.
По главному выводу плюсую и добавлю грабли. Засада даже не в том, что агент не дочитал часть записей, а в том, что генерация это гладко прячет и дыру в тексте не видно. Чем сильнее модель, тем убедительнее она достраивает пропуск, и сводка выглядит настоящей. У себя я сначала кодом собираю все нужные заметки, и только потом генерю строго по ним, без додумывания. Ещё прошу агента писать, сколько заметок из скольких он реально взял, и цитировать их. Тогда непрочитанное сразу вылезает.
Цитирование исходников в сводке форсить пробовали, или хватает сырого текста с коммитом?
Приятная статья, забрал себе на вооружение. Когда можно запустить аналитику с минимальными вложениями по разработке, это очень круто.
Очень близкая боль метание между OLTP и OLAP, и по моему опыту если данных достаточно за вчера и мы не говорим о сложной Oracle (RMS) based системе, то пользователям, не аналитикам, а именно C-Level, достаточно решений типа Metabase на базе OLTP. Зависит от того, какими агрегатами мы оперируем, на сколько сложные срезы и зависимости нужно анализировать.
С OLAP можно настраивать непрерывный процесс сбора данных пакетами, если для каких то целей требуются актуальные данные. Но обычно таких запросов у аналитиков не много.
Могут быть аналитические запросы у клиентов, которые можно запускать только на read реплике, но случаев, когда мы их уводили в OLAP я не припомню.
В примере с перцептроном я бы, наверное, чуть подробнее остановился на масштабе входов. Не как критика. Просто это место часто стреляет в практике. В Yario мы разбирали обращения из 2 каналов, WhatsApp и Telegram, и даже простая классификация начинает вести себя странно, если рядом живут минуты ожидания, счетчики сообщений и признаки из текста. Модель легко цепляется за размерность. Нормализацию вы сознательно оставили за рамками статьи?
Узнаваемо до боли, особенно про калькуляторы. У нас то же расхождение, и корень обычно один. Reasoning-токены. На один видимый токен модель льёт 2-3 скрытых, калькулятор считает по видимым, отсюда и кратная ошибка. Мы теперь и клиенту в SLA пишем ёмкость в видимых токенах плюс отдельным множителем накладные на рассуждение, иначе обещание не бьётся с тем, за что реально потеет GPU.
Ещё при сайзинге смотреть стоит на p95 под целевой конкуренцией, средний TPS тут обманывает. Throughput под нагрузкой даже растёт за счёт батчинга, а вот хвост задержек первым ломает ощущение «тормозит». Гарантию давать по p95 на нужном числе диалогов.
Про prefix caching добавлю грабли. Он спасает только если общий префикс байт в байт одинаковый. Любое шаблонное поле в начале промпта, время, имя юзера, id сессии, тихо убивает попадание в кэш. Волатильное в хвост, системный префикс в начало стабильным блоком. Это бесплатные 40 процентов, которые легко потерять.
Сильный разбор, особенно про разрыв между «граф визуально убедителен» и реальной топологией. Глаз тут врёт всегда. Честный сигнал это распределение степеней и доля вершин со степенью <=1, мы как раз гейтим сборку графа по этой доле, до того как доверять поиску.
Про автоматизацию дедупа подтверждаю вашу боль. Двуязычное расщепление и сокращения рвут связность тише всего, а чисто символьный матч (Левенштейн, rapidfuzz) их пропускает, потому что алиас семантический. У нас лучше зашло так. Кластеризация по эмбеддингам, а LLM зовём только на спорные пары у границы. Ручной MAPPING_DICT не тянет тысячи актов, но и полный обучаемый NER с дорогой разметкой нужен не сразу.
Про маршрутизатор в планах. Мы это гоняем, и вывод ровно ваш. Вопросы про цепочку связей уходят в граф, точечный лукап в вектор. Дешёвый классификатор на входе решает куда, а честный отказ при пустом поиске на практике важнее идеального выбора хранилища.
Подход хороший, особенно бинарный pass/fail вместо шкалы. У шкалы в проде слишком много шума, и калибровка руками на сотне кейсов это только подтверждает. Чего мне не хватило в статье, так это разговора про self-preference. Когда судья и генератор из одного семейства моделей, его оценка почти линейно ползёт вверх вместе с тем, насколько он узнаёт собственный стиль, и он постепенно начинает путать «свой» текст с «хорошим». Позиционный сдвиг вы уже лечите сменой порядка, но эта проблема так не уходит. У нас помогло развести генератор и судью на разные семейства и в каждый прогон подмешивать контрольные пары с заранее размеченным руками ответом: если судья на них валится, остальным его оценкам мы уже не верим. Если захочется покопать глубже, на эту тему есть толковый разбор у Eugene Yan.
Самое ценное тут это привязка таксономии ошибок к цене для пользователя. Recoverable против убивающих доверие. У нас на распознавании картинок так же, считаем по стоимости ошибки, а не по голой accuracy. Одна и та же цифра точности может значить и норм продукт, и провал, всё решает, какие именно промахи попали в неисправимые.
Про судью на той же модели соглашусь, но риск не в случайном шуме. Он в скоррелированной слепоте. Судья делит провалы с распознавателем и штампует ровно те ошибки, которые распознаватель и делает. Дешёвая страховка, подсыпать в прогон заранее известные злые пары, гречка против пельменей. Если судья их не ловит, его «всё correct» ничего не значит. Ручной проход по подвыборке у вас как раз это и закрыл.
Калибровку confidence стоит проверять об вердикты. Реально ли низкая уверенность коррелирует с wrong. Сырое число от модели обычно не калибровано, и порог 0.85 легко висит для красоты, пока не сверишь его с фактами.
Аналогия с AF447 точная, и в работе с Claude Code это ощущается. Навык не исчезает. Он смещается. Раньше ценился набор кода. Теперь умение поставить задачу и проверить результат. Пассивный наблюдатель за автопилотом деградирует. Тот, кто остаётся пилотом, нет.
От complacency у нас помогает одна привычка. Перед запуском агента вслух сформулировать, что должно получиться и по каким признакам поймём, что вышло верно. Тогда ты сверяешь вывод модели со своим ожиданием, а не принимаешь диктовку, и внимание не уплывает. Код, который не можешь объяснить и проверить, в коммит не идёт.
Вы скилл-атрофию замеряете хоть как-то, или это пока ощущение? Любопытно, отличается ли деградация у джунов и сеньоров на одном инструменте.
Та же стена у нас в AI-разборе звонков. Сводка готова, менеджер открыл её и закрыл, а решение принял как всегда. Просмотр и правда не равен действию, ровно ваша мысль про график и закрытую вкладку.
Помогло вот что. Любой наш артефакт теперь кончается назначенным следующим шагом с ответственным и сроком, без этого он просто украшение. И меряем мы не открытия дашборда, а сдвинулся ли сам этот шаг в CRM. Сам факт что открыли ничего не говорит, важно поменялось ли поведение после.
У вас в конце вопрос, как отличить посмотрел от изменил поведение. Мы привязываем артефакт к одному решению, которое он должен улучшить, и потом смотрим на это решение в системе, а не на просмотр. И встречный вопрос. На уровнях 1-2 вашей шкалы есть ли вообще смысл городить дашборд, или сперва надо встроить само решение в управленческий ритм, а инструмент подключать уже к 3?
Знакомая боль, и подход правильный. Локальные модели на своей видяхе тут и есть разблокировка, и по деньгам, и по приватности.
Мы недавно крутили похожее, только под коммерцию. Надо было собрать базу фоток БУ-устройств и телефонов для интернет-магазина. Картинки тянули из публичных источников через Serper, закинули около 50 долларов и получили тысячи запросов, этого хватило на приличную базу. Дальше всё перемалывали локально на одной 4070Ti, несколько разных моделей под свои шаги. Вышло на удивление бодро.
Что совпало с вашим опытом. Самой моделью дело не решается, узкое место это дедуп и матчинг грязных входов. У вас EXIF врёт и имена IMG_4348, у нас почти то же на товарных фото. Соберу отдельную статью про этот пайплайн, там интереснее всего как раз матчинг. А дубликаты вы как ловили, по хешу, по эмбеддингам или смешанно?
Полезное сравнение, спасибо. У нас на проде вывод такой же. Мы давно перестали искать одну лучшую модель и роутим по типу задачи. Найти узкое место это recall, тут Qwen и другие дешёвые отрабатывают нормально. Глубокий разбор с тонкой правкой это precision, там фронтир пока стабильнее.
Но главное вы поймали точно. Небезопасный фикс в быстрых победах. Дешёвая модель увереннее ошибается на краях, и применишь её совет вслепую, экономия на токенах вылезет багом в проде. Поэтому у нас всё, что пишет код, идёт через проверку. Компиляция, тесты, ревью. А дорогая модель или человек подключаются только к тому, что проверка завернула. Дёшево и не страшно.
Получается, роутить полезнее по цене ошибки, а не по абстрактному качеству. Триаж дешёвой, необратимое действие дорогой с проверкой. Вы цену ошибки в оценку закладывали, или считали чистое качество против цены прогона?
Спасибо за честный замер. У нас на проде похожая картина. Для большинства задач один сильный агент с нормальным контекстом бьёт команду и по точности, и по деньгам. Цена в разы это ровно наш опыт, каждый лишний вызов умножает токены.
А где мультиагент окупается, по нашим наблюдениям дело не в топологии. Решает другое. Есть ли у шага объективная проверка. Критик как вторая модель со своим мнением на субъективной задаче просто усредняет шум и проигрывает. Другое дело, когда у подзадачи есть внешний верификатор. Тесты, схема, ответ из поиска, компиляция. Тогда критик опирается на факт, и связка генератор плюс проверка выигрывает. То есть тянут шаги с заземлением, а не сами команды.
И авто-выбор паттерна поэтому тяжёлый. Роутеру надо угадать сложность задачи, а это почти сама задача. Не пробовали роутить тупо по наличию внешнего верификатора у шага, вместо предсказанной сложности?
Спасибо, по делу. Собрал у себя почти то же. База знаний в Obsidian, лежит в гите, надиктовываю через macWhisper, дополняю и спрашиваю её через свой телеграм-бот с агентом, правлю из VS Code. Лучше связки Obsidian плюс гит пока не нашёл, всё под рукой и версионируется.
По главному выводу плюсую и добавлю грабли. Засада даже не в том, что агент не дочитал часть записей, а в том, что генерация это гладко прячет и дыру в тексте не видно. Чем сильнее модель, тем убедительнее она достраивает пропуск, и сводка выглядит настоящей. У себя я сначала кодом собираю все нужные заметки, и только потом генерю строго по ним, без додумывания. Ещё прошу агента писать, сколько заметок из скольких он реально взял, и цитировать их. Тогда непрочитанное сразу вылезает.
Цитирование исходников в сводке форсить пробовали, или хватает сырого текста с коммитом?
Приятная статья, забрал себе на вооружение. Когда можно запустить аналитику с минимальными вложениями по разработке, это очень круто.
Очень близкая боль метание между OLTP и OLAP, и по моему опыту если данных достаточно за вчера и мы не говорим о сложной Oracle (RMS) based системе, то пользователям, не аналитикам, а именно C-Level, достаточно решений типа Metabase на базе OLTP. Зависит от того, какими агрегатами мы оперируем, на сколько сложные срезы и зависимости нужно анализировать.
С OLAP можно настраивать непрерывный процесс сбора данных пакетами, если для каких то целей требуются актуальные данные. Но обычно таких запросов у аналитиков не много.
Могут быть аналитические запросы у клиентов, которые можно запускать только на read реплике, но случаев, когда мы их уводили в OLAP я не припомню.