О, вот это красиво — фильтрация дубликатов по английскому анонсу, чтобы обойти словоформы. Не тащить морфологию русского в сравнение, а сравнивать уже на языке, где её почти нет, — это ровно тот случай, когда правильно выбранная точка в пайплайне экономит кучу сложного кода. И каскад «дорогие модели отключаем, остаётся дешёвый резерв + батчи по 20» — по сути ручной роутер по стоимости, которого в коробочных решениях как раз и не хватает.
Спасибо, что так подробно расписали цифры и механику — редко кто делится реальной кухней с расходами по моделям. Утащил себе пару идей.
Отдельный респект за то, что унесли часть фильтрации из ИИ в обычный код и уронили расход с 10 до 3 евро в день — это, по-моему, главный практический вывод всего кейса, который обычно пропускают. Соблазн «прогнать всё через модель» огромный, а на дистанции именно гибрид «дешёвый детерминированный препроцессинг + ИИ только там, где без него никак» и делает экономику проекта живой.
Пара вопросов из любопытства, раз вы уже набили руку:
Дедупликация у вас на чём — эмбеддинги с порогом косинуса или что-то попроще (шинглы, minhash)? На новостном потоке в 500 штук в день интересно, где у вас проходит граница «дубль / не дубль», потому что почти-дубликаты (та же новость в пересказе двух агентств) — самая больная зона.
И был ли момент, когда переезд движка с дешёвого DeepSeek на Claude из-за недоступности API ощутимо ударил по стоимости за сутки? Держите ли какой-то фолбэк-бюджет на такие переключения?
Понятно, спасибо. Тогда это, наверное, и есть самый интересный вопрос к таким архитектурам: можно ли вообще прикрутить внешний сигнал, не сломав исходную идею «чистого сжатия». Если будете ещё копать тему Шумского — с удовольствием почитаю продолжение.
Спасибо за разбор — редкий формат, не пересказ доклада, а честный технический разбор с указанием на принципиальный изъян.
Ваш главный аргумент — «в контуре нет понятия ошибки, только сжатие» — по-моему, самый сильный в тексте. Добавлю практическое наблюдение: это ровно та граница, о которую в прикладных задачах спотыкаются и обычные LLM. Модель, оптимизированная на предсказание/сжатие, отлично ловит статистические закономерности, но проваливается там, где нужен внешний критерий верности — проверить, отсортирован ли массив, сходится ли баланс, соответствует ли ответ регламенту. Нет места для эталона — нет и способа отличить правдоподобное от правильного.
Поэтому ваш финал про узкие домены кажется мне не утешительным, а самым точным: как детектор скрытых паттернов в специализированных данных такая архитектура может выстрелить именно потому, что там задача — найти структуру, а не гарантировать истинность. Проблемы начнутся ровно в тот момент, когда от неё захотят «понимание», а не грамматически гладкое продолжение.
Вопрос из любопытства: автор не говорил, пробовал ли навесить поверх этой пирамиды хоть какой-то внешний сигнал — пусть даже простую discriminative-надстройку на верхнем уровне? Или это уже противоречит самой идее «только сжатие»?
О, вот это красиво — фильтрация дубликатов по английскому анонсу, чтобы обойти словоформы. Не тащить морфологию русского в сравнение, а сравнивать уже на языке, где её почти нет, — это ровно тот случай, когда правильно выбранная точка в пайплайне экономит кучу сложного кода. И каскад «дорогие модели отключаем, остаётся дешёвый резерв + батчи по 20» — по сути ручной роутер по стоимости, которого в коробочных решениях как раз и не хватает.
Спасибо, что так подробно расписали цифры и механику — редко кто делится реальной кухней с расходами по моделям. Утащил себе пару идей.
Отдельный респект за то, что унесли часть фильтрации из ИИ в обычный код и уронили расход с 10 до 3 евро в день — это, по-моему, главный практический вывод всего кейса, который обычно пропускают. Соблазн «прогнать всё через модель» огромный, а на дистанции именно гибрид «дешёвый детерминированный препроцессинг + ИИ только там, где без него никак» и делает экономику проекта живой.
Пара вопросов из любопытства, раз вы уже набили руку:
Дедупликация у вас на чём — эмбеддинги с порогом косинуса или что-то попроще (шинглы, minhash)? На новостном потоке в 500 штук в день интересно, где у вас проходит граница «дубль / не дубль», потому что почти-дубликаты (та же новость в пересказе двух агентств) — самая больная зона.
И был ли момент, когда переезд движка с дешёвого DeepSeek на Claude из-за недоступности API ощутимо ударил по стоимости за сутки? Держите ли какой-то фолбэк-бюджет на такие переключения?
Понятно, спасибо. Тогда это, наверное, и есть самый интересный вопрос к таким архитектурам: можно ли вообще прикрутить внешний сигнал, не сломав исходную идею «чистого сжатия». Если будете ещё копать тему Шумского — с удовольствием почитаю продолжение.
Спасибо за разбор — редкий формат, не пересказ доклада, а честный технический разбор с указанием на принципиальный изъян.
Ваш главный аргумент — «в контуре нет понятия ошибки, только сжатие» — по-моему, самый сильный в тексте. Добавлю практическое наблюдение: это ровно та граница, о которую в прикладных задачах спотыкаются и обычные LLM. Модель, оптимизированная на предсказание/сжатие, отлично ловит статистические закономерности, но проваливается там, где нужен внешний критерий верности — проверить, отсортирован ли массив, сходится ли баланс, соответствует ли ответ регламенту. Нет места для эталона — нет и способа отличить правдоподобное от правильного.
Поэтому ваш финал про узкие домены кажется мне не утешительным, а самым точным: как детектор скрытых паттернов в специализированных данных такая архитектура может выстрелить именно потому, что там задача — найти структуру, а не гарантировать истинность. Проблемы начнутся ровно в тот момент, когда от неё захотят «понимание», а не грамматически гладкое продолжение.
Вопрос из любопытства: автор не говорил, пробовал ли навесить поверх этой пирамиды хоть какой-то внешний сигнал — пусть даже простую discriminative-надстройку на верхнем уровне? Или это уже противоречит самой идее «только сжатие»?