#llm #ml #systemdesign

Слушай, имхо на 100% не согласен с векторной бд - у тебя в любой задаче где требуется жесть какая защита от галлюцинаций ( как например юридические документы) нужно строить графовые бд. Ну или ты просто не написал как будешь с галюнами бороться, потому что это основная проблема тут

#llm #interesting

Небольшое пост-расследование про LLM-модели 🤖

Немного контекста. Мы с моим другом Каримом часто разгоняем мысль, что мы живём в уникальное время и можем наблюдать беспрецедентное соревнование между компаниями, обучающими LLM-модели. Обычно компании соревнуются неявно, и качество их продуктов никто напрямую не оценивает (например, нет объективных метрик, показывающих, чей поиск лучше — Google, Яндекса или Bing).
А в LLM-мире есть конкретные бенчмарки, и при релизе очередной модели каждая компания публикует результаты по ним. То есть мы буквально наблюдаем за гонкой, как на скачках 🏇 (только ставки в миллионы раз выше).

Среди прочих, есть такой бенчмарк — SWE-bench-verified (https://openai.com/index/introducing-swe-bench-verified/), который проверяет, как модели в агентном режиме способны фиксить баги в реальных больших open-source репозиториях. Разумеется, и Google, и Anthropic, и OpenAI публикуют скоры своих моделей на SWE-bench. На данный момент фигурируют такие числа:
OpenAI GPT-5: 74.9%
Anthropic Opus 4.1: 74.5% 📊

Казалось бы, всё очевидно и понятно — кто лучше, кто хуже. Но твиттер кипит: OpenAI проверяют свою модель не на всех 500 задачах, а на 477! И значит, «реальный» результат GPT-5 — 71%!
Это отчасти правда: OpenAI действительно не проверяли модель на всём наборе. И это действительно обесценивает сравнение, потому что мы сопоставляем тёплое с мягким, ведь мы не знаем, как GPT-5 повела бы себя на 23 непокрытых задачах.

Я решил разобраться в вопросе и копнуть глубже, чтобы понять, какие метрики были бы «справедливыми». К счастью, мне не пришлось прогонять бенчмарк руками: есть компания Epoch.AI, которая независимо прогоняет SWE-bench-verified на всех 500 задачах и публикует скоры для каждой модели. По её замерам GPT-5 набирает 59%, а Opus 4.1 — 63%. Помимо итоговых метрик Epoch.AI выложила логи запусков каждой модели на каждой задаче, и можно глазами отследить, что происходило. Разница с официальными числами некислая, к тому же Opus вырвался вперед. Тут явно что-то нечисто, поэтому я спарсил данные с их сайта и сделал небольшой анализ.

Загибайте пальцы — сколько дичи нашлось 🕵️‍♂️:

1. Лимит в 1M токенов на задачу. Epoch.AI для каждой модели установила порог: как только модель потратила миллион токенов, её останавливают и имеющиеся в коде изменения прогоняют через автотесты. То есть даже если модель двигалась в верном направлении, в какой-то момент у неё забирают работу (как тетрадку на контрольной после звонка 😅) и проверяют то, что она успела сделать. В итоге Opus не успел закончить работу примерно в 80% задач, а GPT-5 — в ~40%.
Пример — задача astropy__astropy-13977: GPT-5 просто не успела внести нужные правки. Почему так? В SWE-bench используются кривоватые инструменты редактирования и чтения кода, которые часто приходится вызывать несколько раз, прежде чем они сработают.

2. Задача astropy__astropy-13033. GPT-5 справилась с требованием задачи и смогла сделать так, чтобы при некорректных действиях пользователя код падал с определённой ошибкой. Но тесты бенчмарка проверяют, что сообщение об ошибке содержит конкретный текст, а GPT-5 использовала другую формулировку. Селяви, задача не засчитана. Аналогично в sympy__sympy-13852: тесты проверяют исправление не только того бага, который описан в исходном issue, но и нескольких других, и в результате модели тоже получают незачёт.

3. Задача sympy__sympy-13091. Opus задачу не решил: посадил новый баг, из-за которого в одном из тестов случилось переполнение стека (бесконечная рекурсия). Но задачка засчиталась 🙂
Другой пример: scikit-learn__scikit-learn-14710 — GPT-5 задачу решил(!), но она не засчиталась, т.к. тест просто завис.

4. django__django-15127. Opus очень грамотно предложил три варианта решения и выбрал первый. Однако тесты проверяли, что решение будет строго определённым. Не угадал — не засчитали. Похоже на преподавателя, который требует от студента доказательство «как на лекции».

5. scikit-learn__scikit-learn-14629. Здесь я уже смеялся вслух. С одной стороны, кейс похож на предыдущий: в этот раз GPT-5 избрала определённый метод решения, а тесты ожидали другой, конкретный способ — такой, какой был у автора багфикса. Мне стало интересно, как же тогда эту задачу решил Opus. Оказалось, он написал код, символ-в-символ совпадающий с тем, который написали люди в 2019 году при закрытии бага (https://github.com/scikit-learn/scikit-learn/issues/14615). Неудивительно: это open-source код, и все LLM-модели на нём обучались. Спекулирую, что Opus существенно «крупнее», чем GPT-5, и просто лучше «помнит» исходный код библиотеки. В целом бенчмарк, в котором все (!) задачи взяты из open-source библиотек, на которых обучались все без исключения модели, — это не очень хорошая идея 😅

6. django__django-16642. Обе модели решили, но GPT-5 использовала современное название MIME-типа — application/brotli, а Opus — устаревшее application/x-brotli. Знаете, кто победил? Конечно, Opus! 🤷‍♂️

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

Я изучил ещё десяток задач, где 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