Forwarded from GK trips (George Korepanov)
Небольшое пост-расследование про 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 вырвался вперед. Тут явно что-то нечисто, поэтому я спарсил данные с их сайта и сделал небольшой анализ.
Немного контекста. Мы с моим другом Каримом часто разгоняем мысль, что мы живём в уникальное время и можем наблюдать беспрецедентное соревнование между компаниями, обучающими 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 вырвался вперед. Тут явно что-то нечисто, поэтому я спарсил данные с их сайта и сделал небольшой анализ.
Forwarded from GK trips (George Korepanov)
Загибайте пальцы — сколько дичи нашлось 🕵️♂️:
1. Лимит в 1M токенов на задачу. Epoch.AI для каждой модели установила порог: как только модель потратила миллион токенов, её останавливают и имеющиеся в коде изменения прогоняют через автотесты. То есть даже если модель двигалась в верном направлении, в какой-то момент у неё забирают работу (как тетрадку на контрольной после звонка 😅) и проверяют то, что она успела сделать. В итоге Opus не успел закончить работу примерно в 80% задач, а GPT-5 — в ~40%.
Пример — задача
2. Задача
3. Задача
Другой пример: scikit-learn__scikit-learn-14710 — GPT-5 задачу решил(!), но она не засчиталась, т.к. тест просто завис.
4.
5.
6.
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! 🤷♂️Forwarded from GK trips (George Korepanov)
Ну вы уже поняли тенденцию, да?
Я изучил ещё десяток задач, где 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. Он ничего не проверяет и не говорит, какая модель лучше, а какая хуже. ✅❌
Я изучил ещё десяток задач, где 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. Он ничего не проверяет и не говорит, какая модель лучше, а какая хуже. ✅❌
Forwarded from LLM под капотом
Я доделываю небольшую демку, которая показывает, как сделать планируюшего бизнес-ассистента с доступом к инструментам, на базе 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: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))
Код я потом выложу в статье.
На скриншоте - пример запуска агента. Тут я попросил переделать последний инвойс Маску, там нужно сделать скидку в три раза больше, чем та, что была у Sama.
Вопрос. Как вы думаете, сколько строчек кода в этой демке?
Подсказка:
- Система не использует GPT-5. Модель под капотом даже не из TOP-20 моего SGR бенчмарка, ибо для такой простоты ничего мощного не нужно.
- Никаких сторонних фреймворков не используется. Tool Use тоже самописный (tools интегрированы с планировщиком и работают на одном-единственном SGR-промпте). Только openai и pydantic.
- Реализована простая in-memory CRM система с инвойсами, продуктами, памятью, отправкой писем.
Итак, сколько строчек кода может быть в такой демке? Каждая строчка не более 80 символов, и это не code golf, естественно.
Ваш, @llm_under_hood 🤗
PS: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))
Forwarded from Находки в опенсорсе
Три типа объектов в Питоне
В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны C.
PyObject
Все мы знаем, что в питоне все объект или
То есть: у нас есть только счетчик ссылок на объект и указатель на его тип. Первое меняется очень часто, если объект не immortal. Второе тоже можно менять в некоторых случаях:
Получается, что большинство объектов мутабельные уже на данном уровне.
Но, в целом есть три типа объектов, разные по уровню мутабельности:
1. Такие как
2. Такие как
3. Такие как
Отдельно нужно отметить, что пользовательские классы обычно еще более мутабельны, потому что их тип менять можно.
Но, вопрос в другом: а где вообще хранится размер объекта и его внутренности? Раз в
C-API
В C-API питона есть два полезных макроса: PyObject_HEAD для объектов фиксированного размера и PyObject_VAR_HEAD для объектов, которые могут менять размер.
Хотим поменять размер объекта? Увеличиваем
Итоговые объекты используют примерно такую логику:
То есть: на самом деле все объекты
- Имеют свой собственный тип:
- Имеют общую абстракцию для размерности:
- Имеют общую абстракцию для типа и счетчика ссылок:
Я сделал небольшой очень упрощенный пример. Там я показываю в том числе, как происходит каст одного типа поинтера в другой в C.
Итог
1.
2.
3.
Обсуждение: как вы думаете, как работает
| Поддержать | YouTube | GitHub | Чат |
В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны 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 | Чат |
Python documentation
Common Object Structures
There are a large number of structures which are used in the definition of object types for Python. This section describes these structures and how they are used. Base object types and macros: All ...
Forwarded from Neural Kovalskii
LLM/RAG Мониторинг с первого дня - это не роскошь, а необходимость!
Когда я запускал @neuraldeepbot 8 месяцев назад, думал "сделаю MVP, а потом посмотрю"
Результат? Система работала, потом, когда-то, запущу в докере и улучшу
Но с развитием кодовых агентов и IDE таких как Cursor у меня чуть сильнее развязались руки
Сейчас подход кардинально другой — с первого запроса у меня есть:
Детализация реакций по дням (видно на графике)
Процент лайков по каждому этапу развития
Классификация сложности запросов через LLM
Трекинг используемых навыков в ReAct цепочке
И знаете что? Это реально работает!
За 6 дней метрики выросли с 48.8% до 96.0% положительных реакций
ReAct архитектура когда LLM сама решает как искать
Вместо жестко заданного пайплайна "вектора → реранкер → ответ" внедрил ReAct подход:
Конкретные цифры улучшений:
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 системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?
Когда я запускал @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 системы без четкого понимания сценариев?
Какие метрики отслеживаете?
И главное как быстро итерируете по фидбеку пользователей?
Forwarded from gonzo-обзоры ML статей
Вышел огромный обзор "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).
В каком-то смысле это продолжение старой доброй “Efficient Transformers: A Survey” 2020 года (https://arxiv.org/abs/2009.06732).
Telegram
gonzo_ML_podcasts
Speed Always Wins: A Survey on Efficient Architectures for Large Language Models
Authors: Weigao Sun, Jiaxi Hu, Yucheng Zhou, Jusen Du, Disen Lan, Kexin Wang, Tong Zhu, Xiaoye Qu, Yu Zhang, Xiaoyu Mo, Daizong Liu, Yuxuan Liang, Wenliang Chen, Guoqi Li, Yu…
Authors: Weigao Sun, Jiaxi Hu, Yucheng Zhou, Jusen Du, Disen Lan, Kexin Wang, Tong Zhu, Xiaoye Qu, Yu Zhang, Xiaoyu Mo, Daizong Liu, Yuxuan Liang, Wenliang Chen, Guoqi Li, Yu…
Forwarded from Love. Death. Transformers.
помните nanotron? Теперь у нас есть tinytpu.com
Проект по построению мини TPU(это такие специальные тензорные процессоры от гугла) где челы зареверсиженерили и вопсроизвели архитектуру и софт.
Внутри куча нюансов про низкоуровневый софт в которых я ничего не понимаю, но считаю что стоит ознакомится.
https://github.com/tiny-tpu-v2/tiny-tpu
Проект по построению мини TPU(это такие специальные тензорные процессоры от гугла) где челы зареверсиженерили и вопсроизвели архитектуру и софт.
Внутри куча нюансов про низкоуровневый софт в которых я ничего не понимаю, но считаю что стоит ознакомится.
https://github.com/tiny-tpu-v2/tiny-tpu
GitHub
GitHub - tiny-tpu-v2/tiny-tpu: A minimal tensor processing unit (TPU), inspired by Google's TPU V2 and V1
A minimal tensor processing unit (TPU), inspired by Google's TPU V2 and V1 - tiny-tpu-v2/tiny-tpu
Forwarded from GIS AND PEACE (Bella)
Urban Data Science Course
О работе с городскими данными на Python в материалах курса Urban Data Science Калифорнийского университета в Лос-Анджелесе (UCLA)
API, Web Scraping, Data Wrangling, Spatial Relations, Machine Learning, Clustering, Parsing Text, Natural Language Processing, Big Data
К каждому модулю:
🔘 ссылки на интересные статьи
🔘 Jupyter блокноты
🔘 видео
🔘 тесты и домашние задания
И всё это в открытом доступе!
КЛАД! 💎
#geo_cities #geo_py #geo_edu
🌎🕊️ GIS_AND_PEACE
О работе с городскими данными на Python в материалах курса Urban Data Science Калифорнийского университета в Лос-Анджелесе (UCLA)
API, Web Scraping, Data Wrangling, Spatial Relations, Machine Learning, Clustering, Parsing Text, Natural Language Processing, Big Data
К каждому модулю:
И всё это в открытом доступе!
КЛАД! 💎
#geo_cities #geo_py #geo_edu
🌎🕊️ GIS_AND_PEACE
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Заскуль питона (Data Science)
Шпаргалки по визуализации в Python
✋ Всем привет! Аналитикам и другим специалистам в области анализа данных необходимо из семпла данных сделать какое-то исследование, найти закономерность в данных и презентовать это ПМ / руководству и др. Не для каждой задачи нужно строить дашборд, поскольку задача может требовать первичный анализ.
🤔 В начале не придаешь этому значения, так как таблицы для нас содержат уже достаточное количество информации + различные статистики. Но на этом этапе хочется иметь возможность визуализировать базовые или интересные штуковины, с помощью которых можно будет сгенерировать еще гипотез.
Визуализировать можно и через Matplotlib (база всех графиков в Python), Seaborn (более расширенный функционал, чем Matplotlib), Plotly (интерактивные графики).
⬇️ Ниже приведен в коде минимум, которым можно пользоваться. Это должно покрывать большое количество задач (~80%) на распределения, поведение метрики во времени. Конечно, есть и другие виды визуализации, но это базовые. Сюда еще можно отнести boxplot для визуализации.
❤️ Если вдруг, вы хотите делать более красивые графики, испытывать наслаждение при их построении, а также сделать их понятнее, вэлком ниже.
1️⃣ Matplotlib [дока]
🔗 Matplotlib CheatSheet (matplotlib.org)
🔗 Гайд на Kaggle по различным визуализациям
🔗 DataCamp Matplotlib CheatSheet
2️⃣ Seaborn [дока]
🔗 DataCamp Seaborn
🔗 Вот тут очень хорошо описано + есть по другим библиотекам
3️⃣ Plotly [дока]
🔗 Plotly Express, Colab
🔗 Plotly Cheatsheet
🙊 Сам я использую matplotlib и seaborn, потому что они быстро настраиваются, но кому-то заходит и Plotly, так как он при обычной настройке может сделать красоту. Каждому свое)
Ну и конечно же, можно использовать ChatGPT, Cursor и других ребят для отрисовки графиков, смотря какую цель преследуете
Ставьте🐳 , сохраняйте к себе, чтобы не потерять, тренируйтесь и все у вас получится!
Визуализировать можно и через Matplotlib (база всех графиков в Python), Seaborn (более расширенный функционал, чем Matplotlib), Plotly (интерактивные графики).
import matplotlib.pyplot as plt
import numpy as np
# Данные
x = np.linspace(0, 10, 100) # создаём массив от 0 до 10 из 100 точек
y = np.sin(x) # вычисляем sin(x)
data = np.random.randn(1000) # 1000 случайных значений из нормального распределения
# Фигура с 2 графиками (subplots)
fig, ax = plt.subplots(1, 2, figsize=(12, 4)) # создаём фигуру с 1 строкой и 2 графиками
# Первый subplot: гистограмма
ax[0].hist(data, bins=20, color="skyblue", edgecolor="black") # рисуем гистограмму
ax[0].set_title("Гистограмма") # заголовок графика
ax[0].set_xlabel("Значения") # подпись оси X
ax[0].set_ylabel("Частота") # подпись оси Y
ax[0].grid(True) # включаем сетку
# Второй subplot: линейный график
ax[1].plot(x, y, label="sin(x)", color="red") # рисуем линию sin(x)
ax[1].set_xlim(0, 12) # ограничение по оси X
ax[1].set_ylim(-2, 2) # ограничение по оси Y
ax[1].set_xticks([0,2,4,6,8,10]) # задаём кастомные тики по X
ax[1].set_yticks([-2,-1,0,1,2]) # задаём кастомные тики по Y
ax[1].set_xlabel("Ось X") # подпись оси X
ax[1].set_ylabel("Ось Y") # подпись оси Y
ax[1].set_title("Линейный график") # заголовок графика
ax[1].legend() # выводим легенду
ax[1].grid(True) # включаем сетку
Ставьте
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Записки C3PO
У Ленни вышла статья где рассказывается про то, почему 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, много бенчмаркинга.
TLDR: как писал много раз ранее, rolling updates с эскалацией сложности системы и evals для оценки технического качества.
Две фундаментальные проблемы AI-продуктов:
1. Недетерминированность - пользователи пишут что угодно вместо нажатия строго определенных заранее кнопок, система отвечает по-разному на одинаковые запросы. Классический QA тут не работает.
2. Компромисс между агентностью и контролем - чем больше автономии даешь ИИ, тем меньше контроля остается у людей.
Что такое CC/CD:
Continuous Development:
- Разбиваем большую цель на версии с растущей автономией (v1: AI-раб → v3: AI-коллега)
- Настраиваем простейшее приложение с логированием всего подряд и возможностью передачи контроля человеку
- Проектируем evals для измерения качества
Continuous Calibration:
- Запускаем на небольшой группе пользователей
- Анализируем реальные данные и паттерны фейлов
- Итеративно фиксим на основе данных
Пример из жизни - автоматизация саппорта:
- v1: Только роутинг тикетов по отделам
- v2: Предложение решений на основе инструкций и/или базы знаний
- v3: Автономное решение с эскалацией сложных кейсов до человека
Главный принцип - не давать ИИ полную автономию сразу. Система должна заслужить доверие через постепенное увеличение ответственности и доказательство надежности на каждом этапе. Это как онбординг нового сотрудника. Сначала простые задачи, потом постепенное расширение полномочий по мере накопления доверия.
По факту, это формализация того, что мы и так делаем в команде с нашими ассистентами и другими ИИ продуктами. Начинаем с простых сценариев, постепенно расширяем полномочия, мониторим каждый чих через evals, много бенчмаркинга.
Lennysnewsletter
Why your AI product needs a different development lifecycle
Introducing the Continuous Calibration/Continuous Development (CC/CD) framework