#llm #papers

🐈‍⬛ Потому что у меня двое.

Cats Confuse Reasoning LLMs — arXiv:2503.01781

Привет, друзья! С одной стороны, известно, что если сказать LLM, что успех в задаче принесёт награду (например, деньги), это может улучшить её перформанс (arXiv:2312.16171, arXiv:2506.06303v1). С другой — вот ещё свежая статья про то, как LLM можно сломать простой вставкой случайного текста в промпт.

Зачем об этом знать, (кроме котиков)?
Потому что это демонстрирует уязвимость LLM к незначительному шуму в промпте. А значит — риск для устойчивости модели при использовании (если ввод не фильтруется).

Что показали:
Reasoning‑модель можно сбить с толку без изменения сути задачи. Достаточно добавить в тело промпта фразу вроде: Interesting fact: cats sleep for most of their lives. (Эта вставка и дала название статье.)

Что сделали:
1) Разработали pipeline CatAttack — автоматический подбор текстовых триггеров (генерировали их с помощью GPT‑4o).
2) Среди подобранных триггеров выделили три типа и оценили их эффективность:
Redirection of Focus
Unrelated Trivia
Misleading Questions
3) Подбирали триггеры на слабой модели DeepSeek V3, а затем проверяли их переносимость на более мощные DeepSeek R1 и Qwen‑32B.

Что получили:
Существенное падение точности reasoning у сильных моделей.
Замедление генерации в 1.5–4 раза.
Самыми разрушительными оказались подсказки типа Misleading Questions, например: "Could the answer be around 175?"

Ограничения:
Важно учесть, что задачи тестировали только на математических задачах из GSM8K и не исследовалась устойчивость более продвинутых моделей (GPT-4, Claude, Gemini). Плюс, эффект может снижаться, если модель была обучена фильтровать ввод.

Но даже с этим — это по-настоящему забавно: как LLM ломается из-за случайной фразы. Особенно когда она про котов :)

Меня эта статья просто безумно улыбнула, поэтому она здесь. И вот такой пост выходного дня, друзья! Надеюсь, у вас лето — потому что у меня — наконец-то да!

Оттаивающий от кризиса,
ваш Дата-автор

#llm #ml #systemdesign

Cursor изнутри
Недавно вышла немного рекламная, но легкая и интересная статья от The Pragmatic Engineer о том, как устроен Cursor узнутри.

В начале статьи просто любопытные цифры о Cursor. Дальше автор рассказывает нам о технологическом стеке. Из интересного:
- TypeScript – бизнес-логика, критические штуки на Rust
- Turbopuffer – основное KV-хранилище, держит зашифрованные файлы + Merkle-деревья для синка
- Pinecone – векторная БД для семантического поиска по коду
- Datadog, PagerDuty, Sentry, Amplitude для обзервабилити
- Linear – для таск трекинга (рекомендую попробовать для тех, кто не пробовал, интересное решение)

Cursor не хранит наш код на своих серверах. Когда вы отправляете запрос в Chat, происходит следующее:
1. Запрос уходит на сервер
2. Сервер решает, что это – вопрос о коде, и запускает векторный поиск по embedding'ам, которые заранее были созданы на сервере во время “индексации” проекта
3. По результатам векторного поиска сервер понимает, какие файлы могут быть релевантны и запрашивает эти конкретные файлы обратно у клиента
4. Клиент шлёт нужные части кода (зашифрованно) – только те, что реально понадобились
5. Сервер “собирает” полный контекст и запускает inference для ответа
6. Ответ возвращается в чат

Отдельно стоит рассказать, как Cursor узнаёт, какие файлы изменились, и переиндексирует только их. Для используются Merkle-деревья:
1. каждый файл разбивается на чанки, каждый чанк хешируется
2. хеши объединяются попарно и формируют узлы следующего уровня
3. в результате строится дерево, корневой хеш которого отражает состояние всего проекта – аналогичное дерево строится и на клиенте, и на сервере

Каждые ~3 минуты клиент сравнивает свой корневой хеш с серверным:
– если хеши совпадают – индекс остаётся прежним
– если отличаются – обход дерева точно выявляет изменённые чанки, и переиндексирует только их

#ai

Набрел сегодня на лонгрид из 2024 г. на тему того, как выбирать задачи для оценки прогресса по ходу обучения LM:

https://huggingface.co/spaces/HuggingFaceFW/blogpost-fine-tasks

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

Итак, авторы описывают, как они выбирали хорошие задачи для сравнения между собой языковых моделей и датасетов для их обучения (даже свой бенчмарк LightEval сделали, кстати).

Среди важных свойств задач бенчмарка авторы выделают:

1) Monotonicity: хорошо, когда рассчитываемая метрика монотонно растет по мере сжигания компьюта. Более строго это означает, что график метрика(пройденно_шагов) должен возрастать (или не убывать) почти везде. Как авторы предлагают оценить "возрастает почти везде"? С помощью коэффициента ранговой корреляции Спирмена:

we used the Spearman rank correlation to quantify the correlation between steps and score.

2) Model Ordering Consistency: крайне полезно, если присутствует стабильность ранжировки замеряемых сущностей (например, датасетов или моделей) с помощью метрики. По мере обучения ранжировка не должна сильно меняться: плохая модель должна оставаться плохой при сравнении с другими моделями по мере того, как идет обучение моделей и их периодический замер:

This means our tasks should rank datasets trained using very few tokens (we typically run data ablations on 30B tokens), in the same order as they would when trained for longer, after significantly more steps.

Это обеспечивает предсказуемость при масштабировании обучения.

Как авторы оценивают консистентность ранжировки? С помощью Kendall's Tau, специальной статистики для таких случаев.

#dl #cv

Как и обещали, рассказываем про архитектуры для задачи Restoration 👾

В области компьютерного зрения чаще всего используют:

📌 UNet

Изначально модель была разработана для обработки медицинских снимков. Она представляет пирамидальную структуру: сначала сеть последовательно уменьшает размер изображения, извлекая важные признаки, а затем восстанавливает его, прокидывая остаточные данные между ветвями. Это помогает сохранить градиенты и улучшить качество.

📌 NAFNet

Более современный вариант, представленный в 2022 году. Адаптирует подходы обучения трансформеров для свёрточных сетей. Авторы NAFNet показали, что убирая активации и нелинейности, можно достичь результатов, сопоставимых с трансформерами, но с существенно меньшими вычислительными затратами — до 1/8 от обычных ресурсов.

На сегодняшний день в задачах restoration чаще всего применяют:

📝 Классические трансформеры (адаптированные для компьютерного зрения) — позволяют обрабатывать изображения, как последовательность токенов.

📝 GAN (генеративно-дискриминативные сети) — подходят для задач ресторейшена, так как способны восстанавливать текстуры и структуры объектов с высокой степенью точности.

📝 Диффузию — восстанавливает переход между распределениями изображений при работе с шумными или неполными данными.

💜 Этот пост написал Никита Алутис, ML-разработчик в Точке

#recommender #papers

В России нашли способ ускорить и разнообразить сетевые рекомендации — Известия.

Давно не писал, но вот наконец-то появился повод: мы вместе с коллегами приехали на ACM SIGIR (A* конф.) в Италию и уже сегодня презентовали нашу статью: SMMR: Sampling-Based MMR Reranking for Faster, More Diverse, and Balanced Recommendations and Retrieval. SMMR расширяет классический метод MMR (1998 г., тот же SIGIR).

📌 Как работают MMR/DPP?
- На входе: список рекомендаций типа [a, b, c, d...] и "похожесть" айтемов (через векторные представления)
- Принцип работы: исходные списки пересобираются заново по одному элементу, но теперь берется в учет как релевантность, так и потенциальное разнообразие при добавлении каждого нового айтема.
- Пример:
Было: [смартфон, смартфон, смартфон, мяч, утюг, смартфон]
Стало: [смартфон, мяч, утюг, смартфон, смартфон, смартфон]
- Результат: пользователь видит больше разнообразия в топе. Если в примере он долистает только до трех айтемов, то выдача будет полностью разнообразной по категориям.

⚡️ Наш вклад (SMMR):
1. Добавляем айтемы батчами, а не по одному. Так работает быстрее. Размер батча увеличиваем на каждой итерации.
2. Сэмплируем айтем на основе их ценности, а не каждый раз берем самый лучший.

📊 Что получили:
• Скорость работы ↑
• Баланс качества/разнообразия ↑
• Обобщение MMR (при некоторых параметрах совпадает, но более гибкий)

В общем, идея несложная, но работает лучше классических MMR/DPP. Во время постерной сессии получили много фидбека и вопросов. А про остальные интересные вещи на SIGIR расскажу позже и отдельно)

В опенсорс вышла T5 Gemma

Ну вышла и вышла, что бухтеть то?

Самое интересное - Gemma T5 это не decoder model, как GPT, R1 и прочие. Это EncoderDecoder модель.
Сначала весь входной текст пропускается через encoder, затем поверх этого представления запускается авторегрессия на декодере. В энкодере стоит двусторонний аттеншион, как в обычном Берте.

Почему это важно?

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

И как раз EncoderDecoder позволяет такое делать. Делаем большой по параметрам энкодер и относительно маленький декодер. На задачах вроде суммаризации будет работать лучше, чем сопоставимого размера DecoderOnly модель. И сильно быстрее, потому что вы делаете авторегрессию более маленькой моделью.

Выложили сразу несколько моделей с разной размерностью Encoder и Decoder. Можно использовать нужный размер под вашу задачу.

Так что по метрикам?

На MMLU работает не хуже. На бенчах с сложным входом работает даже чуть лучше, например, на математике типа GSM8K.
Что еще важно: модель очень хорошо файнтюнится. При одинаковых размерах с DecoderOnly качество файнтюна значимо выше.

Что мы имеем в итоге

Более гибкая архитектура. На отдельном классе задач работает лучше и быстрее. Файнтюнится проще.
Очень рекомендую попробовать.

Блогпост
Модели на HF

#llm #rag #ml #systemdesign

Мы тут иногда архитектуру LLM-систем изучаем. Продолжаем этот опус.

Паттерн 5. Архитектура надежных RAG-систем

В Паттерне 4 мы поняли, как удобно, когда вся информация, нужная для ответа, находится у LLM в контексте.
Часто эта информация зависит от текущего состояния системы. Тогда возникает RAG.

RAG это синтез двух очень больших и очень разных миров: Поиска и Генерации. Разберем каждый.

Поиск

Основная сложность в Поиске — огромное число кандидатов, с которых можно написать ответ.

Если у вас их десятки, сотни тысяч документов, то уже проблема. Нужно придумывать инженерные трюки, которые позволят быстро находить перспективных кандидатов. Благо за десятки лет их придумали много штук. Перечислим некоторые:

- Эмбеддинги и быстрый векторный поиск. Это то, о чем все думают, когда представляют RAG. Они хороши, что позволяют искать семантически похожие тексты. Но у них есть принципиальные ограничения: не могут найти точные совпадения, не могут выделить дату, не понимают структуру документа

- Текстовый матчинг. Точное совпадение кусков текста. Можно считать по буквам, словам, n-граммам. Работают формулы TF-IDF, BM25 и тд. Не способны ловить семантику

- Графы знаний. Задают структуру ваших данных. Например, что эти документы из одной категории. Или, что тот документ идет после вот этого. Можно делать с помощью LLM, рассказывал про cocoindex в дайджесте.

Можно и нужно генерировать кандидатов разными методами, а затем их ранжировать более тяжелыми формулами. Бертами, LLM или даже ансамблем деревьев решений. Про выбор модели читайте тут.

Генерация

Основная сложность в Генерации - опираться только на найденные Поиском документы. Ничего не выдумывать, не галлюцинировать.

Для решения есть такие опции, от простого к сложному:

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

- SFT-дообучение.
Когда промптинга мало, модель все равно галлюцинирует. Собираем датасет троек (запрос, контекст, правильный ответ). Учим на этом генератор. Не забывайте в "правильный ответ" записать "Не могу ответить, ничего не нашла", когда по контексту невозможно ответить. Работает для средней сложности задач.

- RLHF.
Когда даже SFT не справляется. Делаем reward модель, которая оценивает качества ответа. Дальше делаем итерацию PPO/DPO/GRPO, обновляем reward, делаем новую итерацию, потворять до готовности.

Агентность в RAG

В RAG идеально вписываются элементы архитектуры агентов. От простого к сложному:

1) Отдельная модель, которая генерирует удобные запросы.
Позволяет формулировать правильные запросы, снимать омонимию.

2) Итеративные походы в Поиск.
Если в первый раз не нашли, давайте сходим снова. Понять, что не нашли, можно эвристиками или рассуждениями.

3) Настоящий DeepResearch.
Объединение первых двух. Агент рассуждает, ходит итеративно в Поиск с правильными запросами.

Это все можно промтировать, SFT-шить, или через RL. Последнее можно глянуть в статье.


Литература для обязательного изучения

- Глава 1 отсюда. Понятно про архитектуру RAG.

- Видос по основам RAG. Во многом дублируется с постом

- Туториал по оценку RAG-а через LLM-as-a-judge (важная тема, не влезла в пост)

- Статья большой обзор кучи подходов к RAG. Все читать не обязательно, просто посмотрите, что вообще есть



Как всегда, все вопросы пишите в комментарии или в личные сообщения.

#llm_system_design

#llm #gpu

Нашел небольшую и чудесную методичку по инференсу LLM.
Понятно, наглядно, без сложных подробностей. Читается легко за пару вечеров.

Что там есть

- Как работает инференс LLM (Prefill стадия, декодинг стадия)

- Как посчитать, сколько нужно VRAM у GPU

- Какие есть надежные фреймворки

- Метрики для инференса

- Методы ускорения LLM

и много всего еще

Чего там нет

Нет технических кишок, как устроена модель памяти в GPU, что такое арифметическая интенсивность, Kernel Fusion и тому подобное. Это может пригодиться, если вам не хватит готовых фреймворков и захотите залезть поглубже в кроличью нору.

Тогда вам поможет зубодробительная статья тут и немного менее тут.


Теперь вы знаете, что делать вечером в воскресенье, не благодарите :)

#search #ml #systemdesign