Forwarded from Neural Kovalskii
SGR Deep Research бенчмарк?
В предыдущем посте я рассказал, как мы выкатили наконец стабильную версию sgr deep research системы, что бы начать прогонять разных SGR/non SGR агентов по бенчам и задачам
Времени конечно у команды open-source на это не очень много, но то, что я успеваю руками делать, то делается через "Курсор"😈
Что я себе навайбокдил
1) Логи, очень и очень подробные логи
2) Интерфейс, что бы эти логи не читать в терминале или в IDE
3) Разные виды промптов (для gpt-4o-mini/qwen)
Нашел топ SealQA бенчмарк как я считаю, для Deep Research.
Почему? Я дал вопросы от туда паре человек, так они искали ответ 30 минут (считаю что бенч, отличный)
Далее нашел топ агента ROMA, который выбивает SOTA под этот бенчмарк, и о ужас, что я увидел в промптах, примерно 15к токенов разных оверфитов и трюков для прохождения бенча, бям
Я же решил таким не заниматся и прогнал на 111 вопросов, и глазками просмотрел(больно) что имеем gpt-4o-mini выбила 0.25 точности (не густо?)
Зайдите в бенч сами, увидите, сколько модели выбивают на нем, а выбивают они 0
SealQA is a new challenge benchmark for evaluating SEarch- Augmented Language models on fact-seeking questions where web search yields conflicting, noisy, or unhelpful results
За сим я откланяюсь дальше творить добро и знания в мире LLM, где все покрыто тайной и мистификацией
Кстати поглядеть кусочек логов и трейса можно тут
Репо: https://github.com/vakovalskii/sgr-deep-research
В предыдущем посте я рассказал, как мы выкатили наконец стабильную версию sgr deep research системы, что бы начать прогонять разных SGR/non SGR агентов по бенчам и задачам
Времени конечно у команды open-source на это не очень много, но то, что я успеваю руками делать, то делается через "Курсор"
Что я себе навайбокдил
1) Логи, очень и очень подробные логи
2) Интерфейс, что бы эти логи не читать в терминале или в IDE
3) Разные виды промптов (для gpt-4o-mini/qwen)
Нашел топ SealQA бенчмарк как я считаю, для Deep Research.
Почему? Я дал вопросы от туда паре человек, так они искали ответ 30 минут (считаю что бенч, отличный)
Далее нашел топ агента ROMA, который выбивает SOTA под этот бенчмарк, и о ужас, что я увидел в промптах, примерно 15к токенов разных оверфитов и трюков для прохождения бенча, бям
Я же решил таким не заниматся и прогнал на 111 вопросов, и глазками просмотрел(больно) что имеем gpt-4o-mini выбила 0.25 точности (не густо?)
Зайдите в бенч сами, увидите, сколько модели выбивают на нем, а выбивают они 0
SealQA is a new challenge benchmark for evaluating SEarch- Augmented Language models on fact-seeking questions where web search yields conflicting, noisy, or unhelpful results
За сим я откланяюсь дальше творить добро и знания в мире LLM, где все покрыто тайной и мистификацией
Кстати поглядеть кусочек логов и трейса можно тут
Репо: https://github.com/vakovalskii/sgr-deep-research
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Red RecSys
Генеративные рекомендации III. Хайп и хаос
Меняя компанию, я успела походить по собесам в области RecSys DL, и в одной из секций всегда всплывали генеративные рекомендации. Тема сейчас настолько хайповая, что в терминологии полный хаос, который идёт к нам ещё из научных статей. Пара примеров понимания "генеративных рекомендаций" из статей 23-25 годов:
“The first generative recommendation system in the literature” – хочет назвать известная компания свою же прошлую архитектуру из “Actions…” (ICML'24). Сподвигает их к этому предложение "Generative Recommender", но их парадигма по сути только заменяет концепцию обучения с impression-based на авторегрессивную, не меняя ни задачи модели, ни способ инференса.
"In the paradigm of generative recommendation, the primary objective is to predict the next item a user is likely to interact with" - хочет написать Huawei в препринте этого года. И приписывает таким образом пальму первенства генеративных рекомендаций ванильному SASRec из 2019 года (а то и BERT4Rec из 2018). Мотивация Huawei понятна: они обновляют архитектуру трансформера для простой Shifted Sequence модели (как это делают FuX-α, HSTU, eSASRec и пр.), не меняя концепцию обучения или задачи инференса. Но подчеркнуть актуальность статьи нужно, “Generative” в название статьи добавить хочется, и потому возникает такой вот финт, причём применяется он сейчас в статьях часто. Под "Generative" в заголовке статьи 2024-25 года часто будет скрываться именно авторегрессивная постановка обучения, без концептуальных нововведений на уровне моделирования. Разве что каузальная маска внимания может быть чуть видоизменена под конкретную задачу, как в "Generative Rankers" из моего прошлого поста.
“We propose a generative Next-K strategy, where recommendations are generated item-by-item” – пишет Саша Петров с соавтором в "Generative Sequential Recommendation..." (SIGIR’23). Тут реализуется простая идея: айтем, сгенерированный авторегрессивной моделью, можно подставить в последовательность и продолжить генерировать рекомендации дальше. Помимо жадной генерации есть и другие стратегии. Интуитивно очень понятный подход, и тут он «генеративный» уже в прямом смысле слова, без оговорок. Но хайпует сейчас другое.
“We propose a new paradigm ... Instead of traditional query-candidate matching approaches, our method uses an end-to-end generative model that predicts the candidate IDs directly.” – пишет Google в статье про TIGER (NeurIPS’23). TIGER использует полноценную энкодер-декодер архитектуру и обучается генерировать один следующий айтем (состоящий из набора иерархических semantic ids) для пользователя с заданной историей (в которой также каждый айтем представлен как набор semantic ids). Результаты на публичных датасетах у этой модели легко бьются простым SASRec с gBCE или SS лоссом, но важно далеко не это. Открывается целое направление в RecSys ресёрче:
“We propose OneRec, which replaces the cascaded learning framework with a unified generative model. This is the first end-to-end generative model” - пишут KuaiShou в препринте OneRec (2025). В данном случае одна модель заменяет собой все стадии индустриальных рекомендательных пайплайнов от кандидато-генерации до ранжирования. Прямая генерация айтемов по семантическим айди повторяет идею TIGER, так что в первом приближении модель относится к кандидато-генерации ("Generative Retrieval"). Но использование RL подходов в серии статей “One…” от KuaiShou
позволяет моделям дообучаться на максимизацию приносимого ими профита. По сути, это инкорпорация сразу и ранжирующего сигнала (конверсии в целевые действия - на которые учатся ранжирующие модели), и даже более общего экономического сигнала сразу в единую модель. Что в идеальном мире позволяет ей быть end-to-end генеративным рекомендательным движком, затюненным на полезность в сервисе. Так что законно задаёмся вопросом – не это ли RecSys будущего?
Про серию “One…” можно почитать хардовые разборы у Коли Савушкина из Яндекса и поучаствовать в ближайших ридинг группах VK.
Меняя компанию, я успела походить по собесам в области RecSys DL, и в одной из секций всегда всплывали генеративные рекомендации. Тема сейчас настолько хайповая, что в терминологии полный хаос, который идёт к нам ещё из научных статей. Пара примеров понимания "генеративных рекомендаций" из статей 23-25 годов:
“The first generative recommendation system in the literature” – хочет назвать известная компания свою же прошлую архитектуру из “Actions…” (ICML'24). Сподвигает их к этому предложение "Generative Recommender", но их парадигма по сути только заменяет концепцию обучения с impression-based на авторегрессивную, не меняя ни задачи модели, ни способ инференса.
"In the paradigm of generative recommendation, the primary objective is to predict the next item a user is likely to interact with" - хочет написать Huawei в препринте этого года. И приписывает таким образом пальму первенства генеративных рекомендаций ванильному SASRec из 2019 года (а то и BERT4Rec из 2018). Мотивация Huawei понятна: они обновляют архитектуру трансформера для простой Shifted Sequence модели (как это делают FuX-α, HSTU, eSASRec и пр.), не меняя концепцию обучения или задачи инференса. Но подчеркнуть актуальность статьи нужно, “Generative” в название статьи добавить хочется, и потому возникает такой вот финт, причём применяется он сейчас в статьях часто. Под "Generative" в заголовке статьи 2024-25 года часто будет скрываться именно авторегрессивная постановка обучения, без концептуальных нововведений на уровне моделирования. Разве что каузальная маска внимания может быть чуть видоизменена под конкретную задачу, как в "Generative Rankers" из моего прошлого поста.
“We propose a generative Next-K strategy, where recommendations are generated item-by-item” – пишет Саша Петров с соавтором в "Generative Sequential Recommendation..." (SIGIR’23). Тут реализуется простая идея: айтем, сгенерированный авторегрессивной моделью, можно подставить в последовательность и продолжить генерировать рекомендации дальше. Помимо жадной генерации есть и другие стратегии. Интуитивно очень понятный подход, и тут он «генеративный» уже в прямом смысле слова, без оговорок. Но хайпует сейчас другое.
“We propose a new paradigm ... Instead of traditional query-candidate matching approaches, our method uses an end-to-end generative model that predicts the candidate IDs directly.” – пишет Google в статье про TIGER (NeurIPS’23). TIGER использует полноценную энкодер-декодер архитектуру и обучается генерировать один следующий айтем (состоящий из набора иерархических semantic ids) для пользователя с заданной историей (в которой также каждый айтем представлен как набор semantic ids). Результаты на публичных датасетах у этой модели легко бьются простым SASRec с gBCE или SS лоссом, но важно далеко не это. Открывается целое направление в RecSys ресёрче:
“We propose OneRec, which replaces the cascaded learning framework with a unified generative model. This is the first end-to-end generative model” - пишут KuaiShou в препринте OneRec (2025). В данном случае одна модель заменяет собой все стадии индустриальных рекомендательных пайплайнов от кандидато-генерации до ранжирования. Прямая генерация айтемов по семантическим айди повторяет идею TIGER, так что в первом приближении модель относится к кандидато-генерации ("Generative Retrieval"). Но использование RL подходов в серии статей “One…” от KuaiShou
позволяет моделям дообучаться на максимизацию приносимого ими профита. По сути, это инкорпорация сразу и ранжирующего сигнала (конверсии в целевые действия - на которые учатся ранжирующие модели), и даже более общего экономического сигнала сразу в единую модель. Что в идеальном мире позволяет ей быть end-to-end генеративным рекомендательным движком, затюненным на полезность в сервисе. Так что законно задаёмся вопросом – не это ли RecSys будущего?
Про серию “One…” можно почитать хардовые разборы у Коли Савушкина из Яндекса и поучаствовать в ближайших ридинг группах VK.
arXiv.org
Realizing Scaling Laws in Recommender Systems: A Foundation-Expert...
While scaling laws promise significant performance gains for recommender systems, efficiently deploying hyperscale models remains a major unsolved challenge. In contrast to fields where FMs are...
Forwarded from Pavel Zloi
Глубокое исследование Deep Research
Уже несколько дней думаю над архитектурой sgr-deep-research: в целом проект мне нравится, но в нём не хватает модульности, да и непонятно, как добавить поддержку моих любимых MCP-серверов или, скажем, агента, который будет сам тулы писать.
Моё жизненное кредо: если какого-то функционала в программе нет, значит, я его напишу сам.
Первой мыслью было сразу сесть за код и пилить фичи, но каждый раз, прикасаясь к кодовой базе, ощущал себя как Мидас, но наоборот: вместо золота получалось что-то сомнительное, и результатом я оставался недоволен. Поэтому усилием воли притормозил свои юношеские порывы и решил сесть да "покурить манускрипты древних", посмотреть схемы и, прежде чем садиться за код, разобраться, как в принципе работают системы класса Deep Research: как они устроены, что делают и почему делают именно то, что делают.
Итак, классические Deep Research-системы работают следующим образом (рис. 1):
1️⃣ Пользователь делает запрос.
2️⃣ Система пытается понять, достаточно ли ей данных для дальнейших шагов, или требуется уточнение.
3️⃣ Если нужно уточнение, система приглашает пользователя это сделать и затем возвращается на 2-й шаг — и так по циклу, пока системе не будет достаточно данных.
4️⃣ Если уточнение больше не требуется, система передаёт полученный контекст планировщику.
5️⃣ Планировщик составляет план задач без явного указания того, каким образом решать каждую из них. Представьте что-то вроде чек-листа со списком дел — это оно и есть.
6️⃣ В цикле каждая задача обрабатывается: если необходимо запросить данные через тул — система это делает; если нужно перегенерировать результат — пробует выполнить задачу ещё раз. И так, пока все пункты плана не будут выполнены (рис. 2).
7️⃣ После того, как план завершён, система делает финальную проверку: пытается понять, корректен ли результат и соответствует ли он поставленной задаче.
8️⃣ Если нет — система возвращается к 5-му пункту и просит планировщика доработать план.
9️⃣ Если всё окей, формируется отчёт, который возвращается пользователю.
Такой вот простой и изящный алгоритм, в котором первую скрипку играет большая языковая модель.
Если у вас есть уточнения или советы — не стесняйтесь принять участие в обсуждении под данной публикацией.
PS. Занятный факт, ещё пять лет назад подобные системы казались мне фантастикой, сегодня это уже скорее рутина.
#deepresearch #ai @evilfreelancer
Уже несколько дней думаю над архитектурой sgr-deep-research: в целом проект мне нравится, но в нём не хватает модульности, да и непонятно, как добавить поддержку моих любимых MCP-серверов или, скажем, агента, который будет сам тулы писать.
Моё жизненное кредо: если какого-то функционала в программе нет, значит, я его напишу сам.
Первой мыслью было сразу сесть за код и пилить фичи, но каждый раз, прикасаясь к кодовой базе, ощущал себя как Мидас, но наоборот: вместо золота получалось что-то сомнительное, и результатом я оставался недоволен. Поэтому усилием воли притормозил свои юношеские порывы и решил сесть да "покурить манускрипты древних", посмотреть схемы и, прежде чем садиться за код, разобраться, как в принципе работают системы класса Deep Research: как они устроены, что делают и почему делают именно то, что делают.
Итак, классические Deep Research-системы работают следующим образом (рис. 1):
1️⃣ Пользователь делает запрос.
2️⃣ Система пытается понять, достаточно ли ей данных для дальнейших шагов, или требуется уточнение.
3️⃣ Если нужно уточнение, система приглашает пользователя это сделать и затем возвращается на 2-й шаг — и так по циклу, пока системе не будет достаточно данных.
4️⃣ Если уточнение больше не требуется, система передаёт полученный контекст планировщику.
5️⃣ Планировщик составляет план задач без явного указания того, каким образом решать каждую из них. Представьте что-то вроде чек-листа со списком дел — это оно и есть.
6️⃣ В цикле каждая задача обрабатывается: если необходимо запросить данные через тул — система это делает; если нужно перегенерировать результат — пробует выполнить задачу ещё раз. И так, пока все пункты плана не будут выполнены (рис. 2).
7️⃣ После того, как план завершён, система делает финальную проверку: пытается понять, корректен ли результат и соответствует ли он поставленной задаче.
8️⃣ Если нет — система возвращается к 5-му пункту и просит планировщика доработать план.
9️⃣ Если всё окей, формируется отчёт, который возвращается пользователю.
Такой вот простой и изящный алгоритм, в котором первую скрипку играет большая языковая модель.
Если у вас есть уточнения или советы — не стесняйтесь принять участие в обсуждении под данной публикацией.
PS. Занятный факт, ещё пять лет назад подобные системы казались мне фантастикой, сегодня это уже скорее рутина.
#deepresearch #ai @evilfreelancer
Forwarded from Quant Researcher
Financial Data Science Python Notebooks — большой набор Jupyter‑ноутбуков про финансы
https://terence-lim.github.io/docs/financial-data-science-notebooks/README.html
Авторы собрали практические примеры по финансовой эконометрике, временным рядам и машинному обучению.
😎 Данные, данные, данные…
Вместе с ноутбуками поставляется библиотека FinDS, которая демонстрирует, как строить пайплайн для работы с финансовыми базами. Например, с макроэкономическими данными от FRED и BEA.
🅱️ Классические вопросы: цены, факторы и регрессии
Если вас интересуют классические стратегии, здесь есть ноутбуки про свойства цен и тестирование гипотез по методике Джегадиша—Титмана (моментум на CRSP‑акциях, оценка моментов и Newey—West стандарты ошибок). Есть материалы по исследованию Фама—Френч (стоимость и размер, линейные регрессии на CRSP/Compustat), по кросс‑секционным регрессиям Фама—Макбет (CAPM, нелинейные регрессии и квадратичная оптимизация), а также разбор стратегий контртренда с учетом структурных разрывов и затрат на реализацию.
🔮 Макроэкономика и риск‑менеджмент
Более широкие темы включают анализ экономических показателей (прогнозы, занятость, выбросы), тесты регрессий для индексов потребительских и производственных цен, промышленного производства и инфляции.
Есть ноутбуки по моделям пространственных состояний (скрытые марковские модели, гауссовы смеси), по кривой доходности и моделированию структуры процентных ставок, по факторной структуре доходностей облигаций (PCA), по оценке опционов (биномиальные деревья, Black–Scholes–Merton, Монте‑Карло), по Value‑at‑Risk для криптовалют.
🪐 Текстовый анализ и NLP
В ноутбуках по NLP разбирают, как построить тематические модели для стенограмм FOMC, оценить тональность отчётов 10‑K/10‑Q на основе словарей Loughran–Macdonald, проанализировать описания бизнеса с использованием методов POS‑тэггинга и кластеризации.
Далее идут примеры классификации отраслей, прогнозов макроэкономических индикаторов и нейросетей с эмбеддингами слов, использование сверточных и рекуррентных сетей для прогнозирования макро данных, примеры reinforcement learning для планирования пенсионных расходов.
🤡 LLM‑ы
И наконец, черешенка на торте — раздел про большие языковые модели: построение языковых моделей для «Федспика», анализ SEC Edgar, fine‑tuning моделей на индустриальной классификации, prompt‑инжиниринг для новостного сентимента и даже проектирование multi‑agent LLM‑систем для оценки корпоративной благотворительности, чего только не придумают.
Крутая энциклопедия по современному количественному анализу: от классической эконометрики и факторного анализа до сетевой науки, NLP и LLM‑агентов.
Что из этого вы пробовали? Приходите к нам в чат, обсудим)
Quant Researcher
https://terence-lim.github.io/docs/financial-data-science-notebooks/README.html
Авторы собрали практические примеры по финансовой эконометрике, временным рядам и машинному обучению.
😎 Данные, данные, данные…
Вместе с ноутбуками поставляется библиотека FinDS, которая демонстрирует, как строить пайплайн для работы с финансовыми базами. Например, с макроэкономическими данными от FRED и BEA.
🅱️ Классические вопросы: цены, факторы и регрессии
Если вас интересуют классические стратегии, здесь есть ноутбуки про свойства цен и тестирование гипотез по методике Джегадиша—Титмана (моментум на CRSP‑акциях, оценка моментов и Newey—West стандарты ошибок). Есть материалы по исследованию Фама—Френч (стоимость и размер, линейные регрессии на CRSP/Compustat), по кросс‑секционным регрессиям Фама—Макбет (CAPM, нелинейные регрессии и квадратичная оптимизация), а также разбор стратегий контртренда с учетом структурных разрывов и затрат на реализацию.
🔮 Макроэкономика и риск‑менеджмент
Более широкие темы включают анализ экономических показателей (прогнозы, занятость, выбросы), тесты регрессий для индексов потребительских и производственных цен, промышленного производства и инфляции.
Есть ноутбуки по моделям пространственных состояний (скрытые марковские модели, гауссовы смеси), по кривой доходности и моделированию структуры процентных ставок, по факторной структуре доходностей облигаций (PCA), по оценке опционов (биномиальные деревья, Black–Scholes–Merton, Монте‑Карло), по Value‑at‑Risk для криптовалют.
🪐 Текстовый анализ и NLP
В ноутбуках по NLP разбирают, как построить тематические модели для стенограмм FOMC, оценить тональность отчётов 10‑K/10‑Q на основе словарей Loughran–Macdonald, проанализировать описания бизнеса с использованием методов POS‑тэггинга и кластеризации.
Далее идут примеры классификации отраслей, прогнозов макроэкономических индикаторов и нейросетей с эмбеддингами слов, использование сверточных и рекуррентных сетей для прогнозирования макро данных, примеры reinforcement learning для планирования пенсионных расходов.
🤡 LLM‑ы
И наконец, черешенка на торте — раздел про большие языковые модели: построение языковых моделей для «Федспика», анализ SEC Edgar, fine‑tuning моделей на индустриальной классификации, prompt‑инжиниринг для новостного сентимента и даже проектирование multi‑agent LLM‑систем для оценки корпоративной благотворительности, чего только не придумают.
Крутая энциклопедия по современному количественному анализу: от классической эконометрики и факторного анализа до сетевой науки, NLP и LLM‑агентов.
Что из этого вы пробовали? Приходите к нам в чат, обсудим)
Quant Researcher
Forwarded from Young&&Yandex
Самый разгар сезона Тренировок по ML — публикуем домашнее задание на выходные для участников:
🔘 ДЗ №4
https://contest.yandex.ru/contest/79892/enter/
Дедлайн: 28 сентября, 23:59
А ещё смотри подборку материалов от Радослава Нейчева:
🔘
Глава про RL в ML-хендбуке Яндекса (автор Сергей Иванов
)
🔘
Методичка на русском языке от Сергея Иванова
🔘
Книга Ричарда Саттона Reinforcement Learning: An Introduction
И присоединяйся на две последние лекции сезона, ещё можно успеть: yandex.ru/yaintern/training/ml-training
Подписывайся
@Young_and_Yandex
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Диджитализируй!
Двенадцать единственных и очевидных способов записать строку в файл в Python!
В Python можно принтануть сразу в файл!
Хрен знает, зачем это вам! Но вот знайте!
Вообще в питоне есть один очевидный способ сделать это, дзен дело говорит!
Первый очевидный способ:
Второй очевидный способ:
Третий очевидный способ:
Четвёртый очевидный способ:
Пятый очевидный способ:
Шестой очевидный способ:
Седьмой очевидный способ:
Восьмой очевидный способ:
Девятый очевидный способ:
Десятый очевидный способ:
Одиннадцатый очевидный способ:
Двенадцатый очевидный способ:
Вооот!
В Python можно принтануть сразу в файл!
with open("file.txt", "w") as f:
print("привеееет!", file=f)Хрен знает, зачем это вам! Но вот знайте!
Вообще в питоне есть один очевидный способ сделать это, дзен дело говорит!
Первый очевидный способ:
from pathlib import Path
Path("file.txt").write_text("привеееет!")
Второй очевидный способ:
from pathlib import Path
Path("file.txt").write_bytes(
"привеееет!".encode("utf-8")
)
Третий очевидный способ:
with open("file.txt", "w") as f:
print("привеееет!", file=f)Четвёртый очевидный способ:
with open("file.txt", "w") as f:
f.write("привеееет!")Пятый очевидный способ:
import os
fd = os.open(
"file.txt",
os.O_WRONLY | os.O_CREAT | os.O_TRUNC)
os.write(fd, "привеееет!".encode("utf-8"))
os.close(fd)
Шестой очевидный способ:
import io, shutil
data = io.StringIO("привеееет!")
with open("file.txt", "w") as f:
shutil.copyfileobj(data, f)
Седьмой очевидный способ:
import sys
sys.stdout = open("file.txt", "w")
print("привеееет!")
sys.stdout.close()
Восьмой очевидный способ:
from contextlib import redirect_stdout
with open("file.txt", "w") as f:
with redirect_stdout(f):
print("привеееет!")
Девятый очевидный способ:
import mmap
line = "привеееет!".encode("utf-8")
with open("file.txt", "w+b") as f:
f.write(b"\x00" * len(line))
f.flush()
with mmap.mmap(f.fileno(), 0) as mm:
mm[:len(line)] = line
mm.flush()
Десятый очевидный способ:
import tempfile, os
with tempfile.NamedTemporaryFile("w", delete=False) as f:
f.write("привеееет!")
name = f.name
os.replace(name, "file.txt")
Одиннадцатый очевидный способ:
import csv
with open("file.txt", "w", newline="", encoding="utf-8") as f:
writer = csv.writer(f)
writer.writerow(["привеееет!"])
Двенадцатый очевидный способ:
import tarfile
import io
data = io.BytesIO("привеееет!".encode("utf-8"))
with tarfile.open("archive.tar", "w") as tar:
info = tarfile.TarInfo("file.txt")
info.size = len(data.getvalue())
tar.addfile(info, data)
with tarfile.open("archive.tar", "r") as tar:
tar.extractall(
path=".",
members=[tar.getmember("file.txt")], filter="data")
Вооот!
Forwarded from Pavel Zloi
Прекурсор про курсор или как вайб-кодить большие проекты
Намедни в нашем уютном чатике состоялась дискуссия про разработку проектов с большим и сложным техническим заданием (ТЗ) используя средства вайб-кодинга, в результате которого решил собрать эту нитку в формат поста, авось кому ещё пригодится.
Проблема
Итак, предположим на горизонте маячит большой и сложный проект, его ТЗ объёмное и неоднородное - быстрое решение типа "зафигачил всё в чатик модельки и ждёшь чуда" не работает, так как модель забывает контекст, связи между логикой теряются, модель путает уровень абстракции, то переписывает архитектуру, то лезет в детали до того, как мы определили базовые кирпичи.
Как итог - имеем потерю контроля и топтание на месте вместо движения вперёд.
Как я решаю
Во-первых, декомпозиция. Для начала пусть модель изучит техническое задание, вытащит из него понятия и терминологию, ограничения, нефункциональные требования, список вопросов. Потом попрошу её расписать возможные варианты реализации с плюсами/минусами и рисками - из них выбираю ближайший по форме похожий на задумку и тюню его под себя.
Во-вторых, архитектура. На этом шаге мы просим модель создать простенький скелет проекта с заглушками, организовать структуру классов и связи между ними.
В-третьих, "класс за раз". Просим модельку начать пилить код классов, сначала первый слой, то есть те классы, у кого нет зависимостей, на каждый класс пусть модель делает минимальные unit-тесты. Затем второй слой - это классы которые зависят только от классов первого слоя и от самих себя, третий слой - классы которые зависят от классов первого, второго слоёв и от себя и так далее.
Однако, каждый раз играть в эту игру не просто, можно проиграть, и тут на помощь приходят инструменты разработчика и Cursor IDE в частности.
Намедни в нашем уютном чатике состоялась дискуссия про разработку проектов с большим и сложным техническим заданием (ТЗ) используя средства вайб-кодинга, в результате которого решил собрать эту нитку в формат поста, авось кому ещё пригодится.
Проблема
Итак, предположим на горизонте маячит большой и сложный проект, его ТЗ объёмное и неоднородное - быстрое решение типа "зафигачил всё в чатик модельки и ждёшь чуда" не работает, так как модель забывает контекст, связи между логикой теряются, модель путает уровень абстракции, то переписывает архитектуру, то лезет в детали до того, как мы определили базовые кирпичи.
Как итог - имеем потерю контроля и топтание на месте вместо движения вперёд.
Как я решаю
Во-первых, декомпозиция. Для начала пусть модель изучит техническое задание, вытащит из него понятия и терминологию, ограничения, нефункциональные требования, список вопросов. Потом попрошу её расписать возможные варианты реализации с плюсами/минусами и рисками - из них выбираю ближайший по форме похожий на задумку и тюню его под себя.
Во-вторых, архитектура. На этом шаге мы просим модель создать простенький скелет проекта с заглушками, организовать структуру классов и связи между ними.
В-третьих, "класс за раз". Просим модельку начать пилить код классов, сначала первый слой, то есть те классы, у кого нет зависимостей, на каждый класс пусть модель делает минимальные unit-тесты. Затем второй слой - это классы которые зависят только от классов первого слоя и от самих себя, третий слой - классы которые зависят от классов первого, второго слоёв и от себя и так далее.
Если подмодуль крупный, выношу в отдельную сессию и даю выжимку контекста (что готово, где границы, какие правила действуют).
Однако, каждый раз играть в эту игру не просто, можно проиграть, и тут на помощь приходят инструменты разработчика и Cursor IDE в частности.
Forwarded from Neural Kovalskii
Circuit Tracing от Anthropic: как мы в R&D by red_mad_robot решили заглянуть внутрь LLM при использовании в RAG-пайплайнах
Ищем галлюцинации под микроскопом!
29 мая Anthropic выложили в open-source свои инструменты Circuit Tracing методологию механической интерпретируемости, которую мы в R&D подразделении red_mad_robot первыми применили для решения практической задачи детекции галлюцинаций в RAG-системах!
В начале 2025 года, когда я возглавил новое R&D направление, я поставил амбициозную задачу: не просто оценивать качество ответов LLM "снаружи", а заглянуть внутрь процесса генерации и понять, откуда берутся галлюцинации.
Почему именно RAG-пайплайны и Circuit Tracing?
Проблема была очевидна: RAG-системы часто смешивают информацию из контекста с "внутренними знаниями" модели, создавая правдоподобные, но неточные ответы
Существующие методы детекции работают post-factum, а нам нужно было понять механизм принятия решений в реальном времени
Circuit Tracing от Anthropic давал именно это возможность построить атрибуционные графы и проследить, как токены входного контекста влияют на финальный ответ модели
Конкретные результаты нашего исследования
85% точность детекции галлюцинаций вот что мы получили на тестовом датасете с нашей реализацией на базе Qwen2.5-7B.
Как отмечает наш исследователь Ирина Кошкина:
"Основная идея — измерение доли влияния от токенов входа, соответствующих контексту, среди всего влияния от всех активных токенов."
Наша метрика Groundedness включает:
- Контекстную долю влияния (Gctx)
- Replacement Score — качество признаков vs ошибок
- Completeness Score — полнота объяснения через атрибуционный граф
Технические вызовы и решения
Cross-Layer Transcoders (CLT) стали ключевым компонентом системы
Вместо анализа отдельных слоев мы научились отслеживать влияние признаков между несколькими архитектурными уровнями трансформера
Основные проблемы, которые пришлось решать:
1. Вычислительная сложность процедура анализа на порядки медленнее генерации
2. Зависимость от качества обученного транскодера
3. Токен-уровневое сопоставление, приводящее к ложным срабатываниям
Но результат того стоил мы получили рабочий инструмент для анализа внутренних процессов модели во время генерации ответов в RAG-системах
Отдельное спасибо отделу маркетинга red_mad_robot за подготовку детальной статьи оформления и валидации на Хабре
Отдельное спасибо Саше (@dealerAI) за экспертную валидацию нашей гипотезы на старте проекта
Когда предлагаешь исследовать "атрибуционные графы для детекции галлюцинаций в RAG", поддержка опытных друзей по цеху критически важна для получения ресурсов и мотивации команды
Полный технический разбор с кодом, формулами и результатами экспериментов доступен в нашей статье на Хабре закидываем в закладки и ставим +
Ищем галлюцинации под микроскопом!
29 мая Anthropic выложили в open-source свои инструменты Circuit Tracing методологию механической интерпретируемости, которую мы в R&D подразделении red_mad_robot первыми применили для решения практической задачи детекции галлюцинаций в RAG-системах!
В начале 2025 года, когда я возглавил новое R&D направление, я поставил амбициозную задачу: не просто оценивать качество ответов LLM "снаружи", а заглянуть внутрь процесса генерации и понять, откуда берутся галлюцинации.
Почему именно RAG-пайплайны и Circuit Tracing?
Проблема была очевидна: RAG-системы часто смешивают информацию из контекста с "внутренними знаниями" модели, создавая правдоподобные, но неточные ответы
Существующие методы детекции работают post-factum, а нам нужно было понять механизм принятия решений в реальном времени
Circuit Tracing от Anthropic давал именно это возможность построить атрибуционные графы и проследить, как токены входного контекста влияют на финальный ответ модели
Конкретные результаты нашего исследования
85% точность детекции галлюцинаций вот что мы получили на тестовом датасете с нашей реализацией на базе Qwen2.5-7B.
Как отмечает наш исследователь Ирина Кошкина:
"Основная идея — измерение доли влияния от токенов входа, соответствующих контексту, среди всего влияния от всех активных токенов."
Наша метрика Groundedness включает:
- Контекстную долю влияния (Gctx)
- Replacement Score — качество признаков vs ошибок
- Completeness Score — полнота объяснения через атрибуционный граф
Технические вызовы и решения
Cross-Layer Transcoders (CLT) стали ключевым компонентом системы
Вместо анализа отдельных слоев мы научились отслеживать влияние признаков между несколькими архитектурными уровнями трансформера
Основные проблемы, которые пришлось решать:
1. Вычислительная сложность процедура анализа на порядки медленнее генерации
2. Зависимость от качества обученного транскодера
3. Токен-уровневое сопоставление, приводящее к ложным срабатываниям
Но результат того стоил мы получили рабочий инструмент для анализа внутренних процессов модели во время генерации ответов в RAG-системах
Отдельное спасибо отделу маркетинга red_mad_robot за подготовку детальной статьи оформления и валидации на Хабре
Отдельное спасибо Саше (@dealerAI) за экспертную валидацию нашей гипотезы на старте проекта
Когда предлагаешь исследовать "атрибуционные графы для детекции галлюцинаций в RAG", поддержка опытных друзей по цеху критически важна для получения ресурсов и мотивации команды
Полный технический разбор с кодом, формулами и результатами экспериментов доступен в нашей статье на Хабре закидываем в закладки и ставим +
Хабр
Circuit Tracing: как заглянуть в галлюцинации модели и найти там смысл
Всем привет! Меня зовут Ирина, я NLP-инженер в red_mad_robot, занимаюсь научными исследованиями интерпретируемости LLM и анализом механизмов внутренних вычислений моделей, чтобы применять полученные...
Forwarded from DeepSchool
Когда память дороже точности: приближённые структуры данных
Проблема: многие алгоритмы с линейным потреблением памяти не справляются с большим количеством данных. Решение: приближённые структуры!
В новой статье разбираем три популярные структуры данных с константным потреблением памяти, решающие ключевые задачи:
- HyperLogLog — оценка количества уникальных элементов,
- Фильтр Блума — проверка принадлежности ко множеству,
- Count-Min Sketch — подсчёт частот элементов.
Все они работают приближенно, зато позволяют работать с огромными объёмами данных. Читайте, как применять их на практике: https://blog.deepschool.ru/math/kogda-pamyat-dorozhe-tochnosti-priblizhyonnye-struktury-dannyh/
Проблема: многие алгоритмы с линейным потреблением памяти не справляются с большим количеством данных. Решение: приближённые структуры!
В новой статье разбираем три популярные структуры данных с константным потреблением памяти, решающие ключевые задачи:
- HyperLogLog — оценка количества уникальных элементов,
- Фильтр Блума — проверка принадлежности ко множеству,
- Count-Min Sketch — подсчёт частот элементов.
Все они работают приближенно, зато позволяют работать с огромными объёмами данных. Читайте, как применять их на практике: https://blog.deepschool.ru/math/kogda-pamyat-dorozhe-tochnosti-priblizhyonnye-struktury-dannyh/
DeepSchool
Когда память дороже точности: приближённые структуры данных - DeepSchool
HyperLogLog, Bloom/Cuckoo, Count-Min Sketch: что выбрать, если данные огромные, а память ограничена. Алгоритмы, точность и подбор параметров.