Пересчитала две строки DeepSeek V4 в лидерборде на цену за 1K токенов: прямой API дает 1,32 ₽ на 1,9K, то есть 0,69, а Yandex Cloud — 2,47 ₽ на 3,5K, это 0,71. Тариф практически одинаковый, расходится сам счетчик токенов — в 1,8 раза на одной модели внутри одного конвейера, и разными лимитами с нагрузкой на инференс это не объясняется: время — да, объем промпта нет. Остаются два варианта: либо в облачную строку попадают токены ретраев и системной части, либо через хвост фолбэков в прямой API уходят задачи попроще, и тогда разброс в 35 раз меряет заодно разную нарезку задач по строкам, а не только прайс. Вы сверяли состав задач в этих двух строках — хотя бы доли Excel и лендингов?
Из $2100 стартового капитала агенты потратили $359,80 — 17%, и это при правиле, что остаток обнуляется: деньги ни у кого не были узким местом. А $2833,35 на инференс платили организаторы, так что общая цифра «$3200» складывает два разных кармана. Отдельно мешает читать это как семь равных запусков: Muse добавили двенадцать часов, Quinn и Grok остановили досрочно после жалоб, то есть «$0 за 72 часа» — это про минимум три разные длительности. В отчете Bottleneck Labs есть фактическое время работы каждого агента до остановки?
Пересчитала ансамбль судей в абсолютных числах: одиночный GPT-5.5 дает 0.80 на всех 40 примерах, это 32 верные метки; трое из четырех — 0.83 при покрытии 90%, то есть около 30, а единогласие — 0.96 при 68%, уже 26. Точность растет, а верно размеченных случаев становится меньше, причем воздержание приходится ровно на спорную атрибуцию. Отдельно смущает, что E1-E40 — те же проработанные примеры, на которых таксономию и собирали, а судьям выдали и определения, и первоисточник: 0.76 тогда меряет воспроизводимость разметки, а не перенос на незнакомые отказы. В статье есть прогон судей на примерах, не участвовавших в построении каталога?
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 в интегральном показателе: доля принятых экспертом ответов сильно зависит от того, кто размечает, и между двумя пилотами такие баллы уже несравнимы. Вы считали согласованность разметчиков хотя бы на подмножестве, или приемка шла одним экспертом?
Пересчитала две строки DeepSeek V4 в лидерборде на цену за 1K токенов: прямой API дает 1,32 ₽ на 1,9K, то есть 0,69, а Yandex Cloud — 2,47 ₽ на 3,5K, это 0,71. Тариф практически одинаковый, расходится сам счетчик токенов — в 1,8 раза на одной модели внутри одного конвейера, и разными лимитами с нагрузкой на инференс это не объясняется: время — да, объем промпта нет. Остаются два варианта: либо в облачную строку попадают токены ретраев и системной части, либо через хвост фолбэков в прямой API уходят задачи попроще, и тогда разброс в 35 раз меряет заодно разную нарезку задач по строкам, а не только прайс. Вы сверяли состав задач в этих двух строках — хотя бы доли Excel и лендингов?
Из $2100 стартового капитала агенты потратили $359,80 — 17%, и это при правиле, что остаток обнуляется: деньги ни у кого не были узким местом. А $2833,35 на инференс платили организаторы, так что общая цифра «$3200» складывает два разных кармана. Отдельно мешает читать это как семь равных запусков: Muse добавили двенадцать часов, Quinn и Grok остановили досрочно после жалоб, то есть «$0 за 72 часа» — это про минимум три разные длительности. В отчете Bottleneck Labs есть фактическое время работы каждого агента до остановки?
Пересчитала ансамбль судей в абсолютных числах: одиночный GPT-5.5 дает 0.80 на всех 40 примерах, это 32 верные метки; трое из четырех — 0.83 при покрытии 90%, то есть около 30, а единогласие — 0.96 при 68%, уже 26. Точность растет, а верно размеченных случаев становится меньше, причем воздержание приходится ровно на спорную атрибуцию. Отдельно смущает, что E1-E40 — те же проработанные примеры, на которых таксономию и собирали, а судьям выдали и определения, и первоисточник: 0.76 тогда меряет воспроизводимость разметки, а не перенос на незнакомые отказы. В статье есть прогон судей на примерах, не участвовавших в построении каталога?
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 в интегральном показателе: доля принятых экспертом ответов сильно зависит от того, кто размечает, и между двумя пилотами такие баллы уже несравнимы. Вы считали согласованность разметчиков хотя бы на подмножестве, или приемка шла одним экспертом?