Ну вы уже поняли тенденцию, да?

Я изучил ещё десяток задач, где Opus зачли решение, а GPT-5 — нет. Они почти все сводятся к одной вещи: Opus заранее пишет тесты к своим правкам, а GPT-5 — нет. В результате Opus вносит правки до посинения, пока все тесты не пройдут (иногда упираясь в лимит, настрочив сотни строк кода). GPT-5 же идёт, засучивает рукава, сразу делает фикс и сабмитит ответ. То есть на всех этих задачах банальная инструкция в промпте — «сначала напиши хороший тест, который покрывает разные случаи, убедись, что он запускается и ловит все ошибки из issue; затем вноси правки в код до тех пор, пока твои тесты и все существующие не проходят» — перетасовала бы результаты с ног на голову.

И теперь на десерт: знаете, сколько среди 500 задач таких, на которых результаты Opus и GPT-5 отличаются, и при этом GPT-5 не упёрся в лимит по токенам? 36. Тридцать шесть, Карл! Вся «точность» датасета, которая определяет, какая модель лучше, а какая хуже, оказалась заперта внутри 36 задач — это 7% набора. Все остальные задачи либо настолько простые, что их решают обе модели, либо настолько корявые/специфичные, что их не решает никто.

Какие выводы? Проверять знания — крайне сложная задача. Точно так же, как ЕГЭ не измеряет глубину понимания, как собеседование не гарантирует успешность в работе, как Канеман в израильской армии не смог по психотестам определять пригодность к службе, так и бенчмарки являются сомнительным способом измерять «интеллект» модели. Те, кто хоть раз обучал сложные ML-модели, это знают. Но то, что бенчмарк, на который опираются крупные компании, продавая модели пользователям и инвесторам, окажется настолько мусорным, — такого я не ожидал 🤯. Честно, я не уверен, что встретил в нём хотя бы одну задачу, где реально видно качественное превосходство одной модели над другой.

tl;dr
Не смотрите на SWE-bench-verified. Он ничего не проверяет и не говорит, какая модель лучше, а какая хуже. ✅❌

#llm #agents #petproject

Я доделываю небольшую демку, которая показывает, как сделать планируюшего бизнес-ассистента с доступом к инструментам, на базе Schema-Guided Reasoning и недорогой модели.

Код я потом выложу в статье.

На скриншоте - пример запуска агента. Тут я попросил переделать последний инвойс Маску, там нужно сделать скидку в три раза больше, чем та, что была у Sama.

Вопрос. Как вы думаете, сколько строчек кода в этой демке?

Подсказка:
- Система не использует GPT-5. Модель под капотом даже не из TOP-20 моего SGR бенчмарка, ибо для такой простоты ничего мощного не нужно.
- Никаких сторонних фреймворков не используется. Tool Use тоже самописный (tools интегрированы с планировщиком и работают на одном-единственном SGR-промпте). Только openai и pydantic.
- Реализована простая in-memory CRM система с инвойсами, продуктами, памятью, отправкой писем.

Итак, сколько строчек кода может быть в такой демке? Каждая строчка не более 80 символов, и это не code golf, естественно.

Ваш, @llm_under_hood 🤗

PS: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))

Три типа объектов в Питоне

В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны C.

PyObject

Все мы знаем, что в питоне все объект или PyObject *, который упрощенно выглядит так (в FT сборке он посложнее):

struct _object {
    Py_ssize_t ob_refcnt;
    PyTypeObject *ob_type;
}

То есть: у нас есть только счетчик ссылок на объект и указатель на его тип. Первое меняется очень часто, если объект не immortal. Второе тоже можно менять в некоторых случаях:

>>> class A:
...     __slots__ = ()

>>> class B:
...     __slots__ = ()

>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> a.__class__ = B
>>> type(a)
<class '__main__.B'>

Получается, что большинство объектов мутабельные уже на данном уровне.

Но, в целом есть три типа объектов, разные по уровню мутабельности:
1. Такие как None: ob_refcnt не меняется (immortal), тип менять нельзя, ведь Py_TPFLAGS_IMMUTABLETYPE установлен (static type), размер неизменный 0 для всех потенциальных значений
2. Такие как int: ob_refcnt может меняться для больших чисел (маленькие инты - immortal), тип менять нельзя, размер нельзя менять, но он будет разный для разных чисел:

>>> sys.getsizeof(1)
28
>>> sys.getsizeof(10000000000000)
32

3. Такие как list: ob_refcnt всегда меняется, тип менять нельзя, размер меняется

Отдельно нужно отметить, что пользовательские классы обычно еще более мутабельны, потому что их тип менять можно.
Но, вопрос в другом: а где вообще хранится размер объекта и его внутренности? Раз в PyObject ничего такого нет.

C-API

В C-API питона есть два полезных макроса: PyObject_HEAD для объектов фиксированного размера и PyObject_VAR_HEAD для объектов, которые могут менять размер.

struct PyVarObject {
    PyObject ob_base;
    Py_ssize_t ob_size; /* Number of items in variable part */
};

#define PyObject_HEAD  PyObject ob_base;
#define PyObject_VAR_HEAD  PyVarObject ob_base;

Хотим поменять размер объекта? Увеличиваем ob_size, аллоцируем новую память (если нужно) под новые объекты внутри.

Итоговые объекты используют примерно такую логику:

typedef struct {
    PyObject_VAR_HEAD
    /* Vector of pointers to list elements.  list[0] is ob_item[0], etc. */
    PyObject **ob_item;

    /* ob_item contains space for 'allocated' elements.  The number
     * currently in use is ob_size.
     */
    Py_ssize_t allocated;
} PyListObject;

То есть: на самом деле все объекты list (и многие другие) не просто PyObject, они:
- Имеют свой собственный тип: PyListObject
- Имеют общую абстракцию для размерности: PyVarObject
- Имеют общую абстракцию для типа и счетчика ссылок: PyObject

Я сделал небольшой очень упрощенный пример. Там я показываю в том числе, как происходит каст одного типа поинтера в другой в C.

Итог

1. None не имеет внутреннего состояния вообще (не использует ничего)
2. int может иметь разный размер, но не может изменяться, потому использует PyObject_HEAD (раньше был PyObject_VAR_HEAD, там сложная история):

typedef struct _PyLongValue {
    uintptr_t lv_tag; /* Number of digits, sign and flags */
    digit ob_digit[1];
} _PyLongValue;

struct _longobject {
    PyObject_HEAD
    _PyLongValue long_value;
};

3. list может иметь разный размер и может изменятся, потому использует PyObject_VAR_HEAD, как я показывал выше

Обсуждение: как вы думаете, как работает len() для list?

| Поддержать | YouTube | GitHub | Чат |

#rag #petproject

LLM/RAG Мониторинг с первого дня - это не роскошь, а необходимость!

Когда я запускал @neuraldeepbot 8 месяцев назад, думал "сделаю MVP, а потом посмотрю"

Результат? Система работала, потом, когда-то, запущу в докере и улучшу
Но с развитием кодовых агентов и IDE таких как Cursor у меня чуть сильнее развязались руки

Сейчас подход кардинально другой — с первого запроса у меня есть:

Детализация реакций по дням (видно на графике)
Процент лайков по каждому этапу развития
Классификация сложности запросов через LLM
Трекинг используемых навыков в ReAct цепочке

И знаете что? Это реально работает!
За 6 дней метрики выросли с 48.8% до 96.0% положительных реакций

ReAct архитектура когда LLM сама решает как искать

Вместо жестко заданного пайплайна "вектора → реранкер → ответ" внедрил ReAct подход:

User Query → 

1) LLM классификатор навыка
Защита
Уточнение
Мета вопросы
RAG поиск
→ 
2) LLM классификатор сложности
 
ReAct агент выбирает навыки:
   - FTS поиск по ключевым словам
   - Векторный поиск (bge embedding)  
   - Комбинированный поиск
   - Временная фильтрация
   - Поиск по коментам vs постам
→ Синтез финального ответа

Еще одним полем отечает последовательность запуска (ему так же прописаны связи и возможности)
gpt-5-mini показала себя прям очень хорошо 

Кстати все взаимодействия с навыками я построил через SO никакого tool call

Конкретные цифры улучшений:

12.08: Запуск наивного RAG бота — 48.8% лайков
13.08: Анализ первых 200 запросов — 76.0% лайков
14.08: Добавил 4 навыка и классификатор — 78.3% лайков
16.08: Переход на GPT-4o-mini — 95.0% лайков
18.08: Финальные улучшения — 96.0% лайков

Аналитика запросов ваш компас в темноте это проблема почти 90% инициатив которые я встречаю

Самые болезненные инсайты пришли из анализа реальных пользовательских запросов:
Проблема №1: "Какой последний пост был?"

Система отвечала защитой из промпта
Фикс: Добавил навык временного поиска

Проблема №2: "Лучшая локальная LLM?"

Тащила посты 2024 года вместо свежих
Фикс: Приоритизация по датам через ReAct

Проблема №3: Нехватка контекста из разных каналов

Добавил данные из @llm_under_hood и @denissexy, @seeallochnaya
Сразу видно улучшение по реакциям!

Мой чек-лист для каждой итерации Q&A системы
Неделя 1: Базовый MVP + мониторинг реакций
Неделя 2: Анализ первых 100-200 запросов глазами (далее зовем LLM что бы сверится)
Неделя 3: Добавление недостающих навыков поиска
Неделя 3: Оптимизация промптов под реальные кейсы

Далее: Еженедельные итерации по метрикам
Техническая кухня что реально двигает метрики
Стек убийца:

ReAct агент для выбора стратегии поиска
gpt-5-mini как основной LLM (переход дал +19% к лайкам!)
SO на всех этапах вызова навыков
FTS + векторный поиск в зависимости от запроса
bge реранкер для финальной фильтрации
Qdrant для хранения эмбеддингов
PGSQL как основная база
teleton
fastapi
python

Система оценок:

Лайк/дизлайк после каждого ответа
Дизлайк = я лично смотрю кейс и думаю что пошло не так
Никаких A/B тестов — итерируем по общим метрикам(но только на старте)

Главные ошибки, которые убивают Q&A системы

"Сделаю идеальную архитектуру, а потом запущу" — НЕТ!
Запускай MVP и итерируй по реальным запросам
Игнорирование мониторинга без метрик ты летишь вслепую
Жесткий пайплайн вместо адаптивного ReAct дает LLM выбирать стратегию поиска
Недооценка важности промптов 80% успеха Q&A системы в правильных промптах

Ребята реально общались со мной через запросы и давали детальные советы по улучшению промптов

Честно говоря, RAG как RPG нужно быстро лечиться (хотфиксы),
крафтить экипировку (промпты), управлять инвентарем (данные)
и качать скиллы через квесты (Cursor). Каждый день фармишь опыт и лут для апгрейда системы

Но с правильным мониторингом и планом итераций
можно довести систему до production-ready за несколько недель вместо месяцев блужданий

Кто строил похожие Q&A системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?

#llm #papers

Вышел огромный обзор "Speed Always Wins: A Survey on Efficient Architectures for Large Language Models": https://t.me/gonzo_ML_podcasts/699

В каком-то смысле это продолжение старой доброй “Efficient Transformers: A Survey” 2020 года (https://arxiv.org/abs/2009.06732).

#competition #problem

Вот задачи обоих дней олимпиады

#geo #analytics #ml #courses

#analytics #vizualisation

#llm #systemdesign

У Ленни вышла статья где рассказывается про то, почему AI продукты должны иметь другой цикл разработки. Авторы показали фреймворк CC/CD.

TLDR: как писал много раз ранее, rolling updates с эскалацией сложности системы и evals для оценки технического качества.

Две фундаментальные проблемы AI-продуктов:

1. Недетерминированность - пользователи пишут что угодно вместо нажатия строго определенных заранее кнопок, система отвечает по-разному на одинаковые запросы. Классический QA тут не работает.
2. Компромисс между агентностью и контролем - чем больше автономии даешь ИИ, тем меньше контроля остается у людей.

Что такое CC/CD:

Continuous Development:
- Разбиваем большую цель на версии с растущей автономией (v1: AI-раб → v3: AI-коллега)
- Настраиваем простейшее приложение с логированием всего подряд и возможностью передачи контроля человеку
- Проектируем evals для измерения качества

Continuous Calibration:
- Запускаем на небольшой группе пользователей
- Анализируем реальные данные и паттерны фейлов
- Итеративно фиксим на основе данных

Пример из жизни - автоматизация саппорта:
- v1: Только роутинг тикетов по отделам
- v2: Предложение решений на основе инструкций и/или базы знаний
- v3: Автономное решение с эскалацией сложных кейсов до человека

Главный принцип - не давать ИИ полную автономию сразу. Система должна заслужить доверие через постепенное увеличение ответственности и доказательство надежности на каждом этапе. Это как онбординг нового сотрудника. Сначала простые задачи, потом постепенное расширение полномочий по мере накопления доверия.

По факту, это формализация того, что мы и так делаем в команде с нашими ассистентами и другими ИИ продуктами. Начинаем с простых сценариев, постепенно расширяем полномочия, мониторим каждый чих через evals, много бенчмаркинга.

Современные LLM, даже рассуждающие, всё равно очень плохи в алгоритмических задачах. И вот, кажется, намечается прогресс: Hierarchical Reasoning Model (HRM), в которой друг с другом взаимодействуют две рекуррентные сети на двух уровнях, с жалкими 27 миллионами параметров обошла системы в тысячи раз больше на задачах, требующих глубокого логического мышления. Как у неё это получилось, и может ли это совершить новую мини-революцию в AI? Давайте разберёмся...

Hierarchical Reasoning Model: как 27М параметров решают судоку и ARC-AGI

(Пост довольно большой, так что приведу тут только введение, дальше читайте по ссылке.)

Возможности современных LLM слегка парадоксальны: модели, которые пишут симфонии и объясняют квантовую хромодинамику, не могут решить судоку уровня "эксперт". На подобного рода алгоритмических головоломках точность даже лучших LLM в мире стремится к нулю.

Это не баг, а фундаментальное ограничение архитектуры. Вспомните базовый курс алгоритмов (или менее базовый курс теории сложности, если у вас такой был): есть задачи класса P (решаемые за полиномиальное время), а есть задачи, решаемые схемами постоянной глубины (AC⁰). Трансформеры, при всей их мощи, застряли во втором классе, ведь у них фиксированная и не слишком большая глубина.

Представьте это так: вам дают лабиринт и просят найти выход. Это несложно, но есть нюанс: смотреть на лабиринт можно ровно три секунды, вне зависимости от того, это лабиринт 5×5 или 500×500. Именно так работают современные LLM — у них фиксированное число слоёв (обычно несколько десятков), через которые проходит информация. Миллиарды и триллионы параметров относятся к ширине обработки (числу весов в каждом слое), а не к глубине мышления (числу слоёв).

Да, начиная с семейства OpenAI o1 у нас есть “рассуждающие” модели, которые могут думать долго. Но это ведь на самом деле “костыль”: они порождают промежуточные токены, эмулируя цикл через текст. Честно говоря, подозреваю, что для самой LLM это как программировать на Brainfuck — технически возможно, но мучительно неэффективно. Представьте, например, что вам нужно решить судоку с такими ограничениями:

— смотреть на картинку можно две секунды,

— потом нужно записать обычными словами на русском языке то, что вы хотите запомнить,

— и потом вы уходите и возвращаетесь через пару дней (полностью “очистив контекст”), получая только свои предыдущие записи на естественном языке плюс ещё две секунды на анализ самой задачи.

Примерно так современные LLM должны решать алгоритмические задачи — так что кажется неудивительным, что они это очень плохо делают!

И вот Wang et al. (2025) предлагают архитектуру Hierarchical Reasoning Model (HRM), которая, кажется, умеет думать нужное время естественным образом... Как у них это получилось?