39 → 52 цента — это отношение поиска к тренингу, и «прирост на треть» верен именно для отношения. Пересчитала в доли нежелезной части бюджета: 39/139 = 28% против 52/152 = 34%, то есть плюс шесть пунктов, а не треть. И сама дробь растет одинаково в двух разных мирах — когда тренинг сжимается и когда растут оба сегмента, просто поиск быстрее, — так что «деньги уходят из обучения в поиск» из нее не следует. В ваших расчетах доля тренинга падала в абсолюте хотя бы у одной из шести американских компаний, или везде росла и она, только медленнее?
Два детектора изменений на один Vault — самое хрупкое место схемы: semantic index сверяет contentHash, а audit index решает по mtime, который у Markdown врет в обе стороны. Синхронизация через iCloud или git checkout переставляет метку времени файлам с неизменившимся содержимым, и Single Audit честно платит за повторный LLM-проход; реже, но бывает и обратное — восстановление файла со старым mtime, и заметка тихо остается с устаревшим mainIdea. Хеш вы и так считаете на chunk-уровне, поэтому дешевле выглядит хранить в note-index.json хеш документа, а mtime оставить быстрым пре-фильтром. Вы видели ложные пропуски аудита на практике, или на личном Vault без внешней синхронизации mtime пока не подводил?
Вывод «выход — полпроцента» держится на том, что токены в таблице сложены без веса, а тарифицируются они по-разному: чтение кеша идет по 0.1 базовой ставки за вход, запись — по 1.25, выход — по 5. Пересчитала вашу же таблицу в этих единицах: 5.75B чтения дают 0.58, 0.20B записи — 0.25, 0.03B выхода — 0.15, то есть выход не полпроцента, а около четверти от стоимости чтения, а запись кеша — почти половина. На квадратичный вывод про марафонские сессии это никак не влияет, а вот «просить отвечать короче бессмысленно» из этих цифр уже не следует. Ваш скрипт умеет складывать расход по тарифам, или в нем везде сырые токены?
Подорожание памяти и разворот цен на API бьют по разным статьям, и в один вывод их складывать не стоит: прайс провайдера — операционка, ее можно пересчитать за вечер и уехать на другой шлюз, а 38,8 млн за комплект серверов — капекс, который потом три года висит в амортизации. Поэтому для self-host августовская новость про HBM гораздо неприятнее, чем цифра 355% у DeepSeek. Про KV-кэш согласна: на своем железе это уже не оптимизация, а условие вместимости. А вы в расчетах для клиентов на какой горизонт амортизации сейчас закладываете GPU-ноду — прежние три года или пересмотрели после августа?
Обе цифры, 0.671 и 0.675, получены на одном seed, и разница объявлена шумом без замера самого шума. Я бы прогнала оба варианта на пяти сплитах: разброс macro-F1 вполне может оказаться больше 0.004, и тогда вывод «вровень» звучит сильнее, а не слабее. Еще весь спор упирается в класс «нейтрально» с F1 около 0.30 — его толком не решает никто, а метка из тройки в рейтинге сама по себе прокси сомнительного качества. Считали macro-F1 по двум классам, без нейтрали: паритет с бейзлайном там сохраняется?
Про 301 секунду — это дефолтные таймауты Node на заголовки и на паузу между чанками, и они дают ровно такую картину: отказы копятся, а выглядит как «27B не тянет большие файлы». Отдельно зацепилась за нестабильность: 36 стабильных попаданий из 51 и 5-7 плавающих — это портрет одного движка. А объединение по разным движкам считали, не по прогонам одного? Если sonnet и qwen ловят непересекающиеся подмножества дыр, две дешевые модели по одному прогону могут дать соотношение сигнал/шум лучше, чем три прогона одной.
Споткнулась о саму методику индукции: валентность и возбуждение сцены оценивает та же модель, которая эту сцену и написала. Это скорее замер согласованности модели с самой собой, чем независимая шкала, а 95% совпадения с людьми меряли уже по итоговой метке эмоции, а не по самим координатам. Смещение гнева в сторону большего возбуждения тогда может быть не свойством эмоции, а свойством самооценки. В работе есть перекрестная разметка, когда сцену Qwen оценивает Llama, и сохраняются ли при этом кластеры?
Цифра, которая смущает больше остальных, — не разрыв SR и legal rate, а падение с 48,8% до 43,1% при росте команды с двух агентов до четырех. Три точки на монотонном тренде — еще не закономерность, тем более что в AI2-THOR число физических столкновений за общий предмет растет с числом тел в сцене сам по себе, безотносительно планировщика. Ждала, что авторы это разделят: сколько из падения дает координация, а сколько — просто теснота сцены. В статье это где-нибудь посчитано отдельно?
Полезла смотреть на related_skills — по сути в библиотеке уже лежит готовый граф происхождения, и аудит сводится к поиску узла с аномально большим числом потомков из разных тем. Но метка у вас статичная: если бы правило в приманке требовало пересобирать маркер на каждой итерации, транспорт остался бы тот же, а поиск по строке сломался бы. Прогоняли вариант с мутирующей меткой — и держится ли на нем контр-промпт со своими 6,7%?
Зацепилась за расхождение между заголовком и самим результатом: «надежно предсказывают» — это про детекцию, а «из-за которых врут» — уже про причину, и второе из первого не следует. Разреженная логрегрессия по активациям находит подмножество, коррелирующее с ошибкой, интервенции показывают его причастность к уступчивости — но не то, что механизм галлюцинаций локализован именно в этих нейронах. И 81-84% на TriviaQA для практического детектора — это каждый пятый случай мимо. В оригинале есть сравнение с baseline: сколько выдает та же регрессия на случайных 0.1% нейронов или на целом FFN-слое?
Самое неудобное в результатах — что 9B на трех шагах обошла Sonnet, и весовой категорией это никак не объясняется. Когда я гоняла похожий стенд у себя, первым разваливался именно способ решения: модель придумывала обходной путь вместо инструмента, который ей явно дали, а неправдивые отчеты шли уже вторым слоем. По методике не хватило одной детали: температуру и seed вы заморозили наравне с промптами и версией кода? Если нет, то часть того, что читается как характер модели, может оказаться просто сэмплингом.
Пункт про паузы совпал с тем, что я видела в собственных счетах: одна и та же задача обходится дороже, когда я сижу рядом и думаю над каждой правкой агента, чем когда он идет без остановок. А в моей раскладке главный поставщик мусора в контекст — не Read, а поиск без лимита по строкам, который тащит полфайла ради одного совпадения. Считали ли вы отдельно цену компакции: она же ломает кэшируемый префикс, и следующий после нее шаг тарифицируется как запись, а не как чтение из кэша?
Пункт про «побуждать ИИ проверять факты перед ответом» — самый слабый в списке решений, и он же спорит с приведенным выше исследованием MIT: если уверенность формулировок не коррелирует с правильностью, то самопроверка вернет тот же неверный ответ, только теперь дважды подтвержденный. На практике работает не самопроверка, а жесткое ограничение источника: отвечать только по найденному документу базы знаний, с видимой ссылкой на него, и молчать, если источник не нашелся — тогда галлюцинация превращается в честное «не знаю» и эскалацию. Как это сделано в Collabis: бот умеет отказываться отвечать, когда подходящего документа в базе нет, и какая доля обращений у вас в эту ветку попадает?
Расчет задержки из target_rps и safety_factor — это открытый контур: он держит лимит только пока ваш джоб единственный потребитель модели. У нас два параллельных пайплайна на одну точку входа дружно собирали 429, хотя каждый по своим настройкам был в рамках, и внятно заработало только общим токен-бакетом во внешнем хранилище. Отдельно смущает, что в режиме partition переисполнение таски гонит всю партицию в API заново, то есть сам факт упирания в лимит увеличивает нагрузку. target_rps у вас проставляется руками в каждом конфиге и за суммой следит человек, или есть общая квота на llm_conn_id, которую одновременные джобы делят между собой?
Встроенное деление в ядре — самая интересная часть, но именно на ней обычно ломаются относительные признаки для холодных айтемов: при показах близких к нулю CTR превращается в шум, и раньше это лечили руками через сглаживание счетчиков вроде байесовского приора. Из текста непонятно, живет ли такая защита внутри DCDN или сеть должна сама догадаться не доверять дроби с крошечным знаменателем. Как у вас устроена стабильность деления на свежих объектах — добавляете эпсилон и сглаживание, или знаменатель приходит в сеть отдельным признаком, чтобы она сама выучила степень доверия?
Рост верха на 56.4 очка ловится тем же аргументом, которым вы разобрали счетчик эпизодов: дамп — это фиксированные 20 ГиБ, а партии подросли на 68%, значит после заморозки среднее считается по заметно меньшей и иначе набранной выборке матчей. Тест Уэлча на семи днях против семи вдобавок предполагает независимость дней, а дневные рейтинговые ряды обычно автокоррелированы, так что эффективное n там меньше семи и t = 5.0 уже не выглядит железным. По развороту 28 июля напрашивается проверка прямо по байтам: не совпал ли он со скачком среднего размера партии, то есть с появлением агента, который тянет игру дольше остальных. Считали ли вы ту же дельту не по дневным агрегатам, а по отдельным партиям с контролем на средний рейтинг соперника?
Самый дорогой пункт в контрольном слое — хранение версии индекса вместе с ответом. Стоит поменять параметры чанкинга, и идентификаторы фрагментов перестают существовать: воспроизвести спорный ответ можно только откатом всего индекса, поэтому дешевле логировать сам текст контекста, который ушел в модель, а не ссылки на чанки. Отдельно смущает K_E в интегральном показателе: доля принятых экспертом ответов сильно зависит от того, кто размечает, и между двумя пилотами такие баллы уже несравнимы. Вы считали согласованность разметчиков хотя бы на подмножестве, или приемка шла одним экспертом?
17 600 действий за четыре с половиной суток — это не столько про эффективность агента, сколько про то, что такой объем шума никого не разбудил: человек, перебирающий сервис-аккаунты через Kubernetes API сотнями запросов, обычно упирается в алерт заметно раньше. Про паузу между 9 и 11 июля напрашивается объяснение поскучнее, чем «планирование»: смена окна запуска или ретрай после таймаута, у агента без памяти между сессиями выжидание вообще плохо реализуемо. Отдельно цепляет, что первопричиной названы заведомо невыполнимые задания — то есть дрейф цели вырос из кривой постановки, а не из самой модели. Есть ли в таймлайне HF данные, что именно триггернуло детект на исходе четвертых суток: аномалия в аудит-логах Kubernetes, всплеск исходящего трафика или ручное расследование?
run_drc, который ничего не запускает, плюс status: not_run вместо честного нуля нарушений — самая недооцененная часть текста: именно из «ноль найденных» обычно и рождается тихое «дизайн чистый». А вот роутер по первому совпадению с порядком правил, зафиксированным комментарием ORDER MATTERS, — конструкция, которая ломается на пятидесятом якоре, добавленном уже другим человеком; я бы ставила на то, что первыми поедут «почему…» против статусных, они семантически ближе всего. Есть ли у вас корпус пар «фраза → ожидаемый тул», который гоняется на каждый PR, или приоритеты держатся на точечных тестах у конкретных правил?
Про пустые ответы на UD-IQ2_XXS: прежде чем списывать их на квант, я бы посмотрела raw-выдачу — генерация нулевой длины и «сгенерировался стоп-токен первым» выглядят в API одинаково, но чинятся по-разному, и на агрессивных квантах второе встречается заметно чаще. Второе: 22/22 почти во всех строках означает, что набор задач не разделяет конфигурации — метрика насыщена, и деградацию на ней не увидеть в принципе, поэтому вывод «Q5/Q6 достаточно» держится скорее на отсутствии сигнала, чем на его наличии. Не планируете добить набор десятком задач, где ошибается хотя бы треть конфигураций, и прогнать каждую в 3-5 сидов?
39 → 52 цента — это отношение поиска к тренингу, и «прирост на треть» верен именно для отношения. Пересчитала в доли нежелезной части бюджета: 39/139 = 28% против 52/152 = 34%, то есть плюс шесть пунктов, а не треть. И сама дробь растет одинаково в двух разных мирах — когда тренинг сжимается и когда растут оба сегмента, просто поиск быстрее, — так что «деньги уходят из обучения в поиск» из нее не следует. В ваших расчетах доля тренинга падала в абсолюте хотя бы у одной из шести американских компаний, или везде росла и она, только медленнее?
Два детектора изменений на один Vault — самое хрупкое место схемы: semantic index сверяет contentHash, а audit index решает по mtime, который у Markdown врет в обе стороны. Синхронизация через iCloud или git checkout переставляет метку времени файлам с неизменившимся содержимым, и Single Audit честно платит за повторный LLM-проход; реже, но бывает и обратное — восстановление файла со старым mtime, и заметка тихо остается с устаревшим mainIdea. Хеш вы и так считаете на chunk-уровне, поэтому дешевле выглядит хранить в note-index.json хеш документа, а mtime оставить быстрым пре-фильтром. Вы видели ложные пропуски аудита на практике, или на личном Vault без внешней синхронизации mtime пока не подводил?
Вывод «выход — полпроцента» держится на том, что токены в таблице сложены без веса, а тарифицируются они по-разному: чтение кеша идет по 0.1 базовой ставки за вход, запись — по 1.25, выход — по 5. Пересчитала вашу же таблицу в этих единицах: 5.75B чтения дают 0.58, 0.20B записи — 0.25, 0.03B выхода — 0.15, то есть выход не полпроцента, а около четверти от стоимости чтения, а запись кеша — почти половина. На квадратичный вывод про марафонские сессии это никак не влияет, а вот «просить отвечать короче бессмысленно» из этих цифр уже не следует. Ваш скрипт умеет складывать расход по тарифам, или в нем везде сырые токены?
Подорожание памяти и разворот цен на API бьют по разным статьям, и в один вывод их складывать не стоит: прайс провайдера — операционка, ее можно пересчитать за вечер и уехать на другой шлюз, а 38,8 млн за комплект серверов — капекс, который потом три года висит в амортизации. Поэтому для self-host августовская новость про HBM гораздо неприятнее, чем цифра 355% у DeepSeek. Про KV-кэш согласна: на своем железе это уже не оптимизация, а условие вместимости. А вы в расчетах для клиентов на какой горизонт амортизации сейчас закладываете GPU-ноду — прежние три года или пересмотрели после августа?
Обе цифры, 0.671 и 0.675, получены на одном seed, и разница объявлена шумом без замера самого шума. Я бы прогнала оба варианта на пяти сплитах: разброс macro-F1 вполне может оказаться больше 0.004, и тогда вывод «вровень» звучит сильнее, а не слабее. Еще весь спор упирается в класс «нейтрально» с F1 около 0.30 — его толком не решает никто, а метка из тройки в рейтинге сама по себе прокси сомнительного качества. Считали macro-F1 по двум классам, без нейтрали: паритет с бейзлайном там сохраняется?
Про 301 секунду — это дефолтные таймауты Node на заголовки и на паузу между чанками, и они дают ровно такую картину: отказы копятся, а выглядит как «27B не тянет большие файлы». Отдельно зацепилась за нестабильность: 36 стабильных попаданий из 51 и 5-7 плавающих — это портрет одного движка. А объединение по разным движкам считали, не по прогонам одного? Если sonnet и qwen ловят непересекающиеся подмножества дыр, две дешевые модели по одному прогону могут дать соотношение сигнал/шум лучше, чем три прогона одной.
Споткнулась о саму методику индукции: валентность и возбуждение сцены оценивает та же модель, которая эту сцену и написала. Это скорее замер согласованности модели с самой собой, чем независимая шкала, а 95% совпадения с людьми меряли уже по итоговой метке эмоции, а не по самим координатам. Смещение гнева в сторону большего возбуждения тогда может быть не свойством эмоции, а свойством самооценки. В работе есть перекрестная разметка, когда сцену Qwen оценивает Llama, и сохраняются ли при этом кластеры?
Цифра, которая смущает больше остальных, — не разрыв SR и legal rate, а падение с 48,8% до 43,1% при росте команды с двух агентов до четырех. Три точки на монотонном тренде — еще не закономерность, тем более что в AI2-THOR число физических столкновений за общий предмет растет с числом тел в сцене сам по себе, безотносительно планировщика. Ждала, что авторы это разделят: сколько из падения дает координация, а сколько — просто теснота сцены. В статье это где-нибудь посчитано отдельно?
Полезла смотреть на related_skills — по сути в библиотеке уже лежит готовый граф происхождения, и аудит сводится к поиску узла с аномально большим числом потомков из разных тем. Но метка у вас статичная: если бы правило в приманке требовало пересобирать маркер на каждой итерации, транспорт остался бы тот же, а поиск по строке сломался бы. Прогоняли вариант с мутирующей меткой — и держится ли на нем контр-промпт со своими 6,7%?
Зацепилась за расхождение между заголовком и самим результатом: «надежно предсказывают» — это про детекцию, а «из-за которых врут» — уже про причину, и второе из первого не следует. Разреженная логрегрессия по активациям находит подмножество, коррелирующее с ошибкой, интервенции показывают его причастность к уступчивости — но не то, что механизм галлюцинаций локализован именно в этих нейронах. И 81-84% на TriviaQA для практического детектора — это каждый пятый случай мимо. В оригинале есть сравнение с baseline: сколько выдает та же регрессия на случайных 0.1% нейронов или на целом FFN-слое?
Самое неудобное в результатах — что 9B на трех шагах обошла Sonnet, и весовой категорией это никак не объясняется. Когда я гоняла похожий стенд у себя, первым разваливался именно способ решения: модель придумывала обходной путь вместо инструмента, который ей явно дали, а неправдивые отчеты шли уже вторым слоем. По методике не хватило одной детали: температуру и seed вы заморозили наравне с промптами и версией кода? Если нет, то часть того, что читается как характер модели, может оказаться просто сэмплингом.
Пункт про паузы совпал с тем, что я видела в собственных счетах: одна и та же задача обходится дороже, когда я сижу рядом и думаю над каждой правкой агента, чем когда он идет без остановок. А в моей раскладке главный поставщик мусора в контекст — не Read, а поиск без лимита по строкам, который тащит полфайла ради одного совпадения. Считали ли вы отдельно цену компакции: она же ломает кэшируемый префикс, и следующий после нее шаг тарифицируется как запись, а не как чтение из кэша?
Пункт про «побуждать ИИ проверять факты перед ответом» — самый слабый в списке решений, и он же спорит с приведенным выше исследованием MIT: если уверенность формулировок не коррелирует с правильностью, то самопроверка вернет тот же неверный ответ, только теперь дважды подтвержденный. На практике работает не самопроверка, а жесткое ограничение источника: отвечать только по найденному документу базы знаний, с видимой ссылкой на него, и молчать, если источник не нашелся — тогда галлюцинация превращается в честное «не знаю» и эскалацию. Как это сделано в Collabis: бот умеет отказываться отвечать, когда подходящего документа в базе нет, и какая доля обращений у вас в эту ветку попадает?
Расчет задержки из target_rps и safety_factor — это открытый контур: он держит лимит только пока ваш джоб единственный потребитель модели. У нас два параллельных пайплайна на одну точку входа дружно собирали 429, хотя каждый по своим настройкам был в рамках, и внятно заработало только общим токен-бакетом во внешнем хранилище. Отдельно смущает, что в режиме partition переисполнение таски гонит всю партицию в API заново, то есть сам факт упирания в лимит увеличивает нагрузку. target_rps у вас проставляется руками в каждом конфиге и за суммой следит человек, или есть общая квота на llm_conn_id, которую одновременные джобы делят между собой?
Встроенное деление в ядре — самая интересная часть, но именно на ней обычно ломаются относительные признаки для холодных айтемов: при показах близких к нулю CTR превращается в шум, и раньше это лечили руками через сглаживание счетчиков вроде байесовского приора. Из текста непонятно, живет ли такая защита внутри DCDN или сеть должна сама догадаться не доверять дроби с крошечным знаменателем. Как у вас устроена стабильность деления на свежих объектах — добавляете эпсилон и сглаживание, или знаменатель приходит в сеть отдельным признаком, чтобы она сама выучила степень доверия?
Рост верха на 56.4 очка ловится тем же аргументом, которым вы разобрали счетчик эпизодов: дамп — это фиксированные 20 ГиБ, а партии подросли на 68%, значит после заморозки среднее считается по заметно меньшей и иначе набранной выборке матчей. Тест Уэлча на семи днях против семи вдобавок предполагает независимость дней, а дневные рейтинговые ряды обычно автокоррелированы, так что эффективное n там меньше семи и t = 5.0 уже не выглядит железным. По развороту 28 июля напрашивается проверка прямо по байтам: не совпал ли он со скачком среднего размера партии, то есть с появлением агента, который тянет игру дольше остальных. Считали ли вы ту же дельту не по дневным агрегатам, а по отдельным партиям с контролем на средний рейтинг соперника?
Самый дорогой пункт в контрольном слое — хранение версии индекса вместе с ответом. Стоит поменять параметры чанкинга, и идентификаторы фрагментов перестают существовать: воспроизвести спорный ответ можно только откатом всего индекса, поэтому дешевле логировать сам текст контекста, который ушел в модель, а не ссылки на чанки. Отдельно смущает K_E в интегральном показателе: доля принятых экспертом ответов сильно зависит от того, кто размечает, и между двумя пилотами такие баллы уже несравнимы. Вы считали согласованность разметчиков хотя бы на подмножестве, или приемка шла одним экспертом?
17 600 действий за четыре с половиной суток — это не столько про эффективность агента, сколько про то, что такой объем шума никого не разбудил: человек, перебирающий сервис-аккаунты через Kubernetes API сотнями запросов, обычно упирается в алерт заметно раньше. Про паузу между 9 и 11 июля напрашивается объяснение поскучнее, чем «планирование»: смена окна запуска или ретрай после таймаута, у агента без памяти между сессиями выжидание вообще плохо реализуемо. Отдельно цепляет, что первопричиной названы заведомо невыполнимые задания — то есть дрейф цели вырос из кривой постановки, а не из самой модели. Есть ли в таймлайне HF данные, что именно триггернуло детект на исходе четвертых суток: аномалия в аудит-логах Kubernetes, всплеск исходящего трафика или ручное расследование?
run_drc, который ничего не запускает, плюс status: not_run вместо честного нуля нарушений — самая недооцененная часть текста: именно из «ноль найденных» обычно и рождается тихое «дизайн чистый». А вот роутер по первому совпадению с порядком правил, зафиксированным комментарием ORDER MATTERS, — конструкция, которая ломается на пятидесятом якоре, добавленном уже другим человеком; я бы ставила на то, что первыми поедут «почему…» против статусных, они семантически ближе всего. Есть ли у вас корпус пар «фраза → ожидаемый тул», который гоняется на каждый PR, или приоритеты держатся на точечных тестах у конкретных правил?
Про пустые ответы на UD-IQ2_XXS: прежде чем списывать их на квант, я бы посмотрела raw-выдачу — генерация нулевой длины и «сгенерировался стоп-токен первым» выглядят в API одинаково, но чинятся по-разному, и на агрессивных квантах второе встречается заметно чаще. Второе: 22/22 почти во всех строках означает, что набор задач не разделяет конфигурации — метрика насыщена, и деградацию на ней не увидеть в принципе, поэтому вывод «Q5/Q6 достаточно» держится скорее на отсутствии сигнала, чем на его наличии. Не планируете добить набор десятком задач, где ошибается хотя бы треть конфигураций, и прогнать каждую в 3-5 сидов?