Forwarded from Ars Poetica Numeralis
Набрел сегодня на лонгрид из 2024 г. на тему того, как выбирать задачи для оценки прогресса по ходу обучения LM:
https://huggingface.co/spaces/HuggingFaceFW/blogpost-fine-tasks
Две идеи показались мне интересными - они могут пригодиться вне контекста претрейна. Не то, чтобы они были каким-то откровеннием или ноу-хау авторов. Просто полезно напоминать себе о таких полезняшках при работе с данными.
Итак, авторы описывают, как они выбирали хорошие задачи для сравнения между собой языковых моделей и датасетов для их обучения (даже свой бенчмарк LightEval сделали, кстати).
Среди важных свойств задач бенчмарка авторы выделают:
1) Monotonicity: хорошо, когда рассчитываемая метрика монотонно растет по мере сжигания компьюта. Более строго это означает, что график метрика(пройденно_шагов) должен возрастать (или не убывать) почти везде. Как авторы предлагают оценить "возрастает почти везде"? С помощью коэффициента ранговой корреляции Спирмена:
2) Model Ordering Consistency: крайне полезно, если присутствует стабильность ранжировки замеряемых сущностей (например, датасетов или моделей) с помощью метрики. По мере обучения ранжировка не должна сильно меняться: плохая модель должна оставаться плохой при сравнении с другими моделями по мере того, как идет обучение моделей и их периодический замер:
Это обеспечивает предсказуемость при масштабировании обучения.
Как авторы оценивают консистентность ранжировки? С помощью Kendall's Tau, специальной статистики для таких случаев.
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, специальной статистики для таких случаев.
huggingface.co
Scaling FineWeb to 1000+ languages: Step 1: finding signal in 100s of evaluation tasks - a Hugging Face Space by HuggingFaceFW
This application helps evaluate multilingual models across 1000+ languages using a comprehensive suite of tasks called FineTasks. Users can assess model performance in various languages and task ty...
Forwarded from что-то на инженерном
Prompt Engineering vs Context Engineering
В последнее время все чаще замечаю, что если раньше все обсуждали prompt engineering, то теперь на первый план выходит context engineering.
Так в чем же заключается разница?
Тут важно понимать базовый принцип работы LLM: предсказание следующего токена на основе контекста.
➡️ Prompt engineering:
Пользователь формулирует запрос максимально подробно, чтобы модель поняла задачу. Вся нужная информация и инструкции (т.е. весь контекст) задаются в одном сообщении.
Пример задания:
Весь контекст, схема таблиц и задача заданы уже в промпте.
➡️ Context engineering обширнее:
Информация для насыщения контекста может подаваться многими путями:
➡️ Инструкции (system prompt): правила, примеры, ограничения
➡️ История диалога: переписка, предыдущие ответы.
➡️ Примеры
➡️ Долговременная память: знания о пользователе, прошлых задачах
➡️ Внешние данные (RAG): документы, базы, API
➡️ Инструменты: функции, которые может вызывать агент
➡️ Структура вывода: формат, например JSON
В частности, можно попросить модель саму задать уточняющие вопросы для донасыщения контекста.
🟣 То, что вам в своем контексте кажется очевидным, для модели может таковым не являться, и пробелы она заполнит фантазиями.
🟣 Когда контекст достаточно насыщен, пользователь может задать короткий, естественный запрос и получить адекватный ответ.
🟣 Вся дополнительная информация (схемы, примеры, история, правила, внешние данные) уже встроена в контекст системы и подаётся модели автоматически. Это особенно удобно, когда вопросов несколько, а контекст достаточно создать однажды.
Пример задания:
В данном примере вся нужная информация (структура БД, формат вывода, даже примеры корректных SQL-запросов) уже заранее добавлена в системный контекст и не требует от пользователя повторять детали каждый раз.
Поскольку сейчас активно работаю с LLM над задачей речевой аналитики, то прихожу к мысли, что недостаточно просто написать один промпт. Хотя я максимально пытаюсь уложить в один промпт несколько текстов на вход, инструкцию, скрипт, запрос и структуру вывода. Но кажется, чтобы решить задачу качественно придется применить подход context инжиниринга 🤔.
Источники:
🟣 The New Skill in AI is Not Prompting, It's Context Engineering
🟣 Context Engineering: Going Beyond Prompts To Push AI
🟣 Context Engineering: Going Beyond Prompt Engineering and RAG
©️что-то на инженерном
В последнее время все чаще замечаю, что если раньше все обсуждали prompt engineering, то теперь на первый план выходит context engineering.
Так в чем же заключается разница?
Тут важно понимать базовый принцип работы LLM: предсказание следующего токена на основе контекста.
Пользователь формулирует запрос максимально подробно, чтобы модель поняла задачу. Вся нужная информация и инструкции (т.е. весь контекст) задаются в одном сообщении.
Пример задания:
Напиши SQL-запрос, который выберет имена и идентификаторы всех студентов из таблицы students, обучающихся на факультете Computer Science. Таблицы: departments (DepartmentId, DepartmentName), students (DepartmentId, StudentId, StudentName).
Весь контекст, схема таблиц и задача заданы уже в промпте.
Информация для насыщения контекста может подаваться многими путями:
В частности, можно попросить модель саму задать уточняющие вопросы для донасыщения контекста.
Пример задания:
Покажи студентов факультета Computer Science.
В данном примере вся нужная информация (структура БД, формат вывода, даже примеры корректных SQL-запросов) уже заранее добавлена в системный контекст и не требует от пользователя повторять детали каждый раз.
Поскольку сейчас активно работаю с LLM над задачей речевой аналитики, то прихожу к мысли, что недостаточно просто написать один промпт. Хотя я максимально пытаюсь уложить в один промпт несколько текстов на вход, инструкцию, скрипт, запрос и структуру вывода. Но кажется, чтобы решить задачу качественно придется применить подход context инжиниринга 🤔.
Источники:
©️что-то на инженерном
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from .ml
Как и обещали, рассказываем про архитектуры для задачи Restoration 👾
В области компьютерного зрения чаще всего используют:
📌 UNet
📌 NAFNet
На сегодняшний день в задачах restoration чаще всего применяют:
📝 Классические трансформеры (адаптированные для компьютерного зрения) — позволяют обрабатывать изображения, как последовательность токенов.
📝 GAN (генеративно-дискриминативные сети) — подходят для задач ресторейшена, так как способны восстанавливать текстуры и структуры объектов с высокой степенью точности.
📝 Диффузию — восстанавливает переход между распределениями изображений при работе с шумными или неполными данными.
💜Этот пост написал Никита Алутис, ML-разработчик в Точке
В области компьютерного зрения чаще всего используют:
📌 UNet
Изначально модель была разработана для обработки медицинских снимков. Она представляет пирамидальную структуру: сначала сеть последовательно уменьшает размер изображения, извлекая важные признаки, а затем восстанавливает его, прокидывая остаточные данные между ветвями. Это помогает сохранить градиенты и улучшить качество.
📌 NAFNet
Более современный вариант, представленный в 2022 году. Адаптирует подходы обучения трансформеров для свёрточных сетей. Авторы NAFNet показали, что убирая активации и нелинейности, можно достичь результатов, сопоставимых с трансформерами, но с существенно меньшими вычислительными затратами — до 1/8 от обычных ресурсов.
На сегодняшний день в задачах restoration чаще всего применяют:
📝 Классические трансформеры (адаптированные для компьютерного зрения) — позволяют обрабатывать изображения, как последовательность токенов.
📝 GAN (генеративно-дискриминативные сети) — подходят для задач ресторейшена, так как способны восстанавливать текстуры и структуры объектов с высокой степенью точности.
📝 Диффузию — восстанавливает переход между распределениями изображений при работе с шумными или неполными данными.
💜
Forwarded from Персонализация неизбежна
В России нашли способ ускорить и разнообразить сетевые рекомендации — Известия.
Давно не писал, но вот наконец-то появился повод: мы вместе с коллегами приехали на 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 расскажу позже и отдельно)
Давно не писал, но вот наконец-то появился повод: мы вместе с коллегами приехали на 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 расскажу позже и отдельно)
Forwarded from Всеволод Викулин | AI разбор
В опенсорс вышла T5 Gemma
Ну вышла и вышла, что бухтеть то?
Самое интересное - Gemma T5 это не decoder model, как GPT, R1 и прочие. Это EncoderDecoder модель.
Сначала весь входной текст пропускается через encoder, затем поверх этого представления запускается авторегрессия на декодере. В энкодере стоит двусторонний аттеншион, как в обычном Берте.
Почему это важно?
В некоторых задачах намного важнее очень хорошо подумать над входными данными, а когда разобрался - декодинг уже довольно тривиальный. Например, задача суммаризации - сначала все прочитал, потом переписал главные мысли. Тоже самое может отнести и к RAG.
И как раз EncoderDecoder позволяет такое делать. Делаем большой по параметрам энкодер и относительно маленький декодер. На задачах вроде суммаризации будет работать лучше, чем сопоставимого размера DecoderOnly модель. И сильно быстрее, потому что вы делаете авторегрессию более маленькой моделью.
Выложили сразу несколько моделей с разной размерностью Encoder и Decoder. Можно использовать нужный размер под вашу задачу.
Так что по метрикам?
На MMLU работает не хуже. На бенчах с сложным входом работает даже чуть лучше, например, на математике типа GSM8K.
Что еще важно: модель очень хорошо файнтюнится. При одинаковых размерах с DecoderOnly качество файнтюна значимо выше.
Что мы имеем в итоге
Более гибкая архитектура. На отдельном классе задач работает лучше и быстрее. Файнтюнится проще.
Очень рекомендую попробовать.
Блогпост
Модели на HF
Ну вышла и вышла, что бухтеть то?
Самое интересное - Gemma T5 это не decoder model, как GPT, R1 и прочие. Это EncoderDecoder модель.
Сначала весь входной текст пропускается через encoder, затем поверх этого представления запускается авторегрессия на декодере. В энкодере стоит двусторонний аттеншион, как в обычном Берте.
Почему это важно?
В некоторых задачах намного важнее очень хорошо подумать над входными данными, а когда разобрался - декодинг уже довольно тривиальный. Например, задача суммаризации - сначала все прочитал, потом переписал главные мысли. Тоже самое может отнести и к RAG.
И как раз EncoderDecoder позволяет такое делать. Делаем большой по параметрам энкодер и относительно маленький декодер. На задачах вроде суммаризации будет работать лучше, чем сопоставимого размера DecoderOnly модель. И сильно быстрее, потому что вы делаете авторегрессию более маленькой моделью.
Выложили сразу несколько моделей с разной размерностью Encoder и Decoder. Можно использовать нужный размер под вашу задачу.
Так что по метрикам?
На MMLU работает не хуже. На бенчах с сложным входом работает даже чуть лучше, например, на математике типа GSM8K.
Что еще важно: модель очень хорошо файнтюнится. При одинаковых размерах с DecoderOnly качество файнтюна значимо выше.
Что мы имеем в итоге
Более гибкая архитектура. На отдельном классе задач работает лучше и быстрее. Файнтюнится проще.
Очень рекомендую попробовать.
Блогпост
Модели на HF
Googleblog
Google for Developers Blog - News about Web, Mobile, AI and Cloud
Explore T5Gemma – a new collection of encoder-decoder LLMs offering superior performance and efficiency – especially for tasks requiring deep input understanding, like summarization and translation, built on Gemma 2 models.
Forwarded from Всеволод Викулин | AI разбор
Мы тут иногда архитектуру 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
Паттерн 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
Forwarded from Всеволод Викулин | AI разбор
Нашел небольшую и чудесную методичку по инференсу LLM.
Понятно, наглядно, без сложных подробностей. Читается легко за пару вечеров.
Что там есть
- Как работает инференс LLM (Prefill стадия, декодинг стадия)
- Как посчитать, сколько нужно VRAM у GPU
- Какие есть надежные фреймворки
- Метрики для инференса
- Методы ускорения LLM
и много всего еще
Чего там нет
Нет технических кишок, как устроена модель памяти в GPU, что такое арифметическая интенсивность, Kernel Fusion и тому подобное. Это может пригодиться, если вам не хватит готовых фреймворков и захотите залезть поглубже в кроличью нору.
Тогда вам поможет зубодробительная статья тут и немного менее тут.
Теперь вы знаете, что делать вечером в воскресенье, не благодарите :)
Понятно, наглядно, без сложных подробностей. Читается легко за пару вечеров.
Что там есть
- Как работает инференс LLM (Prefill стадия, декодинг стадия)
- Как посчитать, сколько нужно VRAM у GPU
- Какие есть надежные фреймворки
- Метрики для инференса
- Методы ускорения LLM
и много всего еще
Чего там нет
Нет технических кишок, как устроена модель памяти в GPU, что такое арифметическая интенсивность, Kernel Fusion и тому подобное. Это может пригодиться, если вам не хватит готовых фреймворков и захотите залезть поглубже в кроличью нору.
Тогда вам поможет зубодробительная статья тут и немного менее тут.
Теперь вы знаете, что делать вечером в воскресенье, не благодарите :)
Bentoml
LLM Inference Handbook
A practical handbook for engineers building, optimizing, scaling and operating LLM inference systems in production.
Forwarded from Всеволод Викулин | AI разбор
Обсуждать абстрактно "как правильно делать LLM" очень тупо. Поэтому мы будем разбирать архитектуру на реальных примерах.
Раз мы недавно обсуждали RAG, начнем с примера поисковой архитектуры.
Архитектура Поиска по контенту LinkedIn
В соцсети много контента, надо по нему искать. Для RAGа, да и просто для души.
Метрики
Time Spent просмотра постов
Если пользователь листает выдачу поиска и ничего не читает, то скорее всего мы нашли фигню.
Релевантность
Часто просто крутить Time Spent плохая идея, сигнал шумный. Хорошая идея мешать его с чем-то более легко измеримым, например, релевантностью поста. Мерят с помощью GPT.
Архитектура
Индекс из миллиардов постов. Два метода генерации кандидатов:
1) Текстовое совпадение по словам
Вечная классика — обратный индекс, нашли посты со словами из запроса, никакой семантики.
2) Эмбеддинги и быстрый поиск ближайших соседей
Для эмбеддеров используется хорошая мультиязычная моделька.
Дальше тысячи кандидатов отправляются в ранкер.
Ранкер из 2-х этапов. Сначала тысячи ранжируются одной моделькой. Дальше сотни ранжируются моделькой побольше. Архитектура моделей одинаковая.
Модель ранкера это две FC сети. Первая предсказывает релевантность. У нее есть только эмбеддинги запроса и документа. Вторая предсказывает Time Spent. Туда помимо эмбеддингов подаются и обычные фичи (популярность поста, дружит ли пользователь с автором и тд).
Учатся модели на взвешенную сумму Time Spent + Релевантность.
Учатся на кучи исторических сессиях поиска.
Что тут важно почерпнуть
- Несколько таргетов. Часто хорошая идея. Особенно связка онлайн + оффлайн
- Классическая архитектура поиска. Несколько генераций кандидатов + несколько ранкеров.
- Разметка с помощью GPT. Если не очень сложная задача, работает быстро и хорошо
Что я бы поменял
Очень странный выбор ранкера. Две FC-сети, при чем с готовыми эмбеддингами на входе и еще в лаваше с обычными фичами. Такое делать можно, ну только если у вас совсем нет железа.
Мне нравится что-то из:
1) Трансформеры-кроссэнкодеры на текстах, которые вы файнтюните
2) Бустинг над деревьями с обычными фичами
А лучше когда выход 1) пихаете в 2)
Если исторических данных много, то можно учить очень крутые и сложные ранкеры.
Итог
Базовая статья, как обычно делают поиск, но со странным выбором моделей. Можете на нее опираться, когда у вас в базе RAG что-то больше, чем 1000 документов.
Что думаете по этой архитектуре поиска? Слабовато или наоборот перекрутили?
Если есть пример, который надо разобрать, присылайте в личку.
#llm_cases
Раз мы недавно обсуждали RAG, начнем с примера поисковой архитектуры.
Архитектура Поиска по контенту LinkedIn
В соцсети много контента, надо по нему искать. Для RAGа, да и просто для души.
Метрики
Time Spent просмотра постов
Если пользователь листает выдачу поиска и ничего не читает, то скорее всего мы нашли фигню.
Релевантность
Часто просто крутить Time Spent плохая идея, сигнал шумный. Хорошая идея мешать его с чем-то более легко измеримым, например, релевантностью поста. Мерят с помощью GPT.
Архитектура
Индекс из миллиардов постов. Два метода генерации кандидатов:
1) Текстовое совпадение по словам
Вечная классика — обратный индекс, нашли посты со словами из запроса, никакой семантики.
2) Эмбеддинги и быстрый поиск ближайших соседей
Для эмбеддеров используется хорошая мультиязычная моделька.
Дальше тысячи кандидатов отправляются в ранкер.
Ранкер из 2-х этапов. Сначала тысячи ранжируются одной моделькой. Дальше сотни ранжируются моделькой побольше. Архитектура моделей одинаковая.
Модель ранкера это две FC сети. Первая предсказывает релевантность. У нее есть только эмбеддинги запроса и документа. Вторая предсказывает Time Spent. Туда помимо эмбеддингов подаются и обычные фичи (популярность поста, дружит ли пользователь с автором и тд).
Учатся модели на взвешенную сумму Time Spent + Релевантность.
Учатся на кучи исторических сессиях поиска.
Что тут важно почерпнуть
- Несколько таргетов. Часто хорошая идея. Особенно связка онлайн + оффлайн
- Классическая архитектура поиска. Несколько генераций кандидатов + несколько ранкеров.
- Разметка с помощью GPT. Если не очень сложная задача, работает быстро и хорошо
Что я бы поменял
Очень странный выбор ранкера. Две FC-сети, при чем с готовыми эмбеддингами на входе и еще в лаваше с обычными фичами. Такое делать можно, ну только если у вас совсем нет железа.
Мне нравится что-то из:
1) Трансформеры-кроссэнкодеры на текстах, которые вы файнтюните
2) Бустинг над деревьями с обычными фичами
А лучше когда выход 1) пихаете в 2)
Если исторических данных много, то можно учить очень крутые и сложные ранкеры.
Итог
Базовая статья, как обычно делают поиск, но со странным выбором моделей. Можете на нее опираться, когда у вас в базе RAG что-то больше, чем 1000 документов.
Что думаете по этой архитектуре поиска? Слабовато или наоборот перекрутили?
Если есть пример, который надо разобрать, присылайте в личку.
#llm_cases
Forwarded from ML for Value / Ваня Максимов
Хранить нельзя списать: Юнит экономика, ч2
Начнем разбирать издержки с той самой статьи расходов, которая часто и рушит бизнес: хранение товара. Просто следите за руками
Спрос = f(price)
Ст-ть хранения = g(спрос) = g(f(price)) =
= Средний обьем в мес, м2 * ставка аренды
+ Средний обьем в мес, руб * ставка депозита (связка с оборачиваемостью?)
+ max(Средний срок хранения, дни - Срок годности; 0) * себестоимость товара
Прибыль = Спрос * (цена продажи - цена закупки) - Стоимость хранения --> max(price)
Мало того, что нужно получить зависимость g(f(price)). Так этаж* g() еще и очень сложно устроена!
Вот есть у нас прогноз спроса = f(price). Он в штуках, а не в м2. Он - это не обьем хранения. Он не знает о текущих остатках на складах и сколько нужно закупить товара до некоторого оптимального обьема хранения. Он еще не знает, что закупать товар можно только коробками по 12-20 штук
Если спрос маленький (до 10 штук), то его колбасит по полноценному Пуассону. И любая ошибка прогноза (очень вероятная) приводит к покупке не 1 коробки, а 2ух коробок - здравствуйте х2 издержки хранения (списания)
😈О как..
Какое-то "хранение" превратилось в нелинейную комбинаторную невыпуклую и черт еще знает какую заадчу математической оптимизации
Допустим, мы знаем текущий сток(обьем хранения) на складе. И у нас есть прогноз спроса. Казалось бы, закупаем c учетом округлени до коробки round(Спрос - Сток) и все дела?
Типичная ошибка навичка. Мы ведь не решаем задачу продать весь сток поскорее, а хотим побольше прибыли заработать. Если товар на складе закончился, а заказы поступают - мы недополучаем прибыль от этих заказов.
Поэтому появился термин Старховые запасы. Из приятного - можно решать задачи прогноза спроса и определения страховых запасов почти независимо!
Обьем закупки = round(Спрос + Страховой запас - Сток)
Средний обьем хранения = (Сток + Спрос + 2 * Страховой запас + доп хранение из-за округления) / период между поставками
А дальше есть 2 пути
- Зубодробительно решать задачу математически, например, вот так
- Делать симуляции типа Монте-Карло, тк округления "по коробкам" все равно здорово ломают математику
Как бы я ни любил красивую математику, порекомендую заняться симуляцией
💡 Несколько интересных выводов из опыта таких симуляций :
- При маленьком обьеме спроса (до 10 штук товара за период между закупками) ловить нечего - нужно продавать много и вкладываться в рекламу
- Чем меньше размер "коробки" вы можете закупить, тем лучше
- Следите за сроками годности товаров. Фрэш со сроком годности 4 дня и меньше - кровавый океан
- Редкие поставки с большим лагом во времени очень круто растят стоимость хранения
- Если не считать, сколько товара закупать, то можно легко погореть только на хранении)) Хотя казалось бы, это просто фикс ставка за склад в месяц
- Вы удивитесь, но с маржинальностью товара = (цена - закупка) / цена менее 100% у небольшого продавца шансов на прибыль нет. Гораздо эффективнее будет положить деньги на закупку товара на депозит под 16-18%
Это была аналитика дляселлеров ml-щиков бесплатно, без регистрации и смс
Подготовлено каналом @ml4value
Начнем разбирать издержки с той самой статьи расходов, которая часто и рушит бизнес: хранение товара. Просто следите за руками
Спрос = f(price)
Ст-ть хранения = g(спрос) = g(f(price)) =
= Средний обьем в мес, м2 * ставка аренды
+ Средний обьем в мес, руб * ставка депозита (связка с оборачиваемостью?)
+ max(Средний срок хранения, дни - Срок годности; 0) * себестоимость товара
Прибыль = Спрос * (цена продажи - цена закупки) - Стоимость хранения --> max(price)
Мало того, что нужно получить зависимость g(f(price)). Так эта
Вот есть у нас прогноз спроса = f(price). Он в штуках, а не в м2. Он - это не обьем хранения. Он не знает о текущих остатках на складах и сколько нужно закупить товара до некоторого оптимального обьема хранения. Он еще не знает, что закупать товар можно только коробками по 12-20 штук
Если спрос маленький (до 10 штук), то его колбасит по полноценному Пуассону. И любая ошибка прогноза (очень вероятная) приводит к покупке не 1 коробки, а 2ух коробок - здравствуйте х2 издержки хранения (списания)
😈О как..
Какое-то "хранение" превратилось в нелинейную комбинаторную невыпуклую и черт еще знает какую заадчу математической оптимизации
Допустим, мы знаем текущий сток(обьем хранения) на складе. И у нас есть прогноз спроса. Казалось бы, закупаем c учетом округлени до коробки round(Спрос - Сток) и все дела?
Типичная ошибка навичка. Мы ведь не решаем задачу продать весь сток поскорее, а хотим побольше прибыли заработать. Если товар на складе закончился, а заказы поступают - мы недополучаем прибыль от этих заказов.
Поэтому появился термин Старховые запасы. Из приятного - можно решать задачи прогноза спроса и определения страховых запасов почти независимо!
Обьем закупки = round(Спрос + Страховой запас - Сток)
Средний обьем хранения = (Сток + Спрос + 2 * Страховой запас + доп хранение из-за округления) / период между поставками
А дальше есть 2 пути
- Зубодробительно решать задачу математически, например, вот так
- Делать симуляции типа Монте-Карло, тк округления "по коробкам" все равно здорово ломают математику
Как бы я ни любил красивую математику, порекомендую заняться симуляцией
- При маленьком обьеме спроса (до 10 штук товара за период между закупками) ловить нечего - нужно продавать много и вкладываться в рекламу
- Чем меньше размер "коробки" вы можете закупить, тем лучше
- Следите за сроками годности товаров. Фрэш со сроком годности 4 дня и меньше - кровавый океан
- Редкие поставки с большим лагом во времени очень круто растят стоимость хранения
- Если не считать, сколько товара закупать, то можно легко погореть только на хранении)) Хотя казалось бы, это просто фикс ставка за склад в месяц
- Вы удивитесь, но с маржинальностью товара = (цена - закупка) / цена менее 100% у небольшого продавца шансов на прибыль нет. Гораздо эффективнее будет положить деньги на закупку товара на депозит под 16-18%
Это была аналитика для
Подготовлено каналом @ml4value
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. How to become a more effective engineer
Сегодня статья на английском https://newsletter.pragmaticengineer.com/p/how-to-become-a-more-effective-engineer
Читается она более-менее легко и понятно, но если вам будет сложно, то нынче браузеры умеют довольно неплохо переводить такие лонгриды.
Несмотря на то, что в названии есть слово engineer, речь пойдет не об инженерии, а о том, как работает жизнь и система, в которой вы работаете.
На мой взгляд, эту статью на точно обязательно читать менеджерам и тимлидам. Мидл-менеджмент чаще всего уже достаточно прожженный, чтобы это всё знать 🙂 Но даже и линейным сотрудникам я бы советовал ознакомиться, чтобы снять розовые очки и не испытывать типовые страдания от того, что всё, якобы, неправильно, что работать должно не так, а эдак, в руководстве делают глупости, никто не понимает очевидных вещей и всё в таком духе.
Основной посыл статьи – хорошенько порефлексировать и понять, как работает система, в которой вы работаете. Понять её ограничения (с которыми вы вряд ли что-то сделаете, и не надо тратить время, силы, нервы и выгорать в этой борьбе с ветряными мельницами), культуру, принципы, несовершенства, неформальную иерархию.
А после этого станет намного более понятно, что вам нужно принять, с чем можно бороться, а где бесполезно жечь нервы и вообще забить/дистанцироваться/уйти.
После 18 лет в ИТ мне эта статья кажется довольно мудрой и жизненной. В начале карьеры я бы её, скорее всего, захейтил, сказал бы, что это «политика», приспособленчество и надо жестко бороться абсолютно за всё «правильное», против абсолютно всего «неправильного».
Сегодня статья на английском https://newsletter.pragmaticengineer.com/p/how-to-become-a-more-effective-engineer
Читается она более-менее легко и понятно, но если вам будет сложно, то нынче браузеры умеют довольно неплохо переводить такие лонгриды.
Несмотря на то, что в названии есть слово engineer, речь пойдет не об инженерии, а о том, как работает жизнь и система, в которой вы работаете.
На мой взгляд, эту статью на точно обязательно читать менеджерам и тимлидам. Мидл-менеджмент чаще всего уже достаточно прожженный, чтобы это всё знать 🙂 Но даже и линейным сотрудникам я бы советовал ознакомиться, чтобы снять розовые очки и не испытывать типовые страдания от того, что всё, якобы, неправильно, что работать должно не так, а эдак, в руководстве делают глупости, никто не понимает очевидных вещей и всё в таком духе.
Основной посыл статьи – хорошенько порефлексировать и понять, как работает система, в которой вы работаете. Понять её ограничения (с которыми вы вряд ли что-то сделаете, и не надо тратить время, силы, нервы и выгорать в этой борьбе с ветряными мельницами), культуру, принципы, несовершенства, неформальную иерархию.
А после этого станет намного более понятно, что вам нужно принять, с чем можно бороться, а где бесполезно жечь нервы и вообще забить/дистанцироваться/уйти.
После 18 лет в ИТ мне эта статья кажется довольно мудрой и жизненной. В начале карьеры я бы её, скорее всего, захейтил, сказал бы, что это «политика», приспособленчество и надо жестко бороться абсолютно за всё «правильное», против абсолютно всего «неправильного».
Pragmaticengineer
How to become a more effective engineer
The importance of soft skills, implicit hierarchies, getting to “small wins”, understanding promotion processes and more. A guest post from software engineer Cindy Sridharan.
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. Контакты… конфликты…
Игры вам приносил, сериалы и фильмы приносил, а вот мультики еще нет. Вот вам для затравки 4 отрывка из старого мультика 1984 года «Контакты… Конфликты…». Сняли 40 лет назад, а актуально всё и по сей день 🙂
https://www.youtube.com/watch?v=edha3Krhick – про то, как «помогает» совещание и почему работягу не мотивирует прибавка.
https://www.youtube.com/watch?v=EH_3ukkNuwg – про то, как у нас выстроилась очередь СРОЧНОЙ РАБОТЫ уже вплоть до пенсии, а она всё продолжает прибывать.
https://www.youtube.com/watch?v=Ovs5LSl1yOk – встречал граждан, у которых был такой же режим планирования и приоритизации 🙂
https://www.youtube.com/watch?v=3LqSbUdz1sY – а это когда слова и аргументы слушать не хотят, но объясниться и договориться о дальнейшем надо.
Если у вас есть еще любимые серии, заносите в комментарии. Ну а если ситуации знакомы вам, то ставьте 💯
Игры вам приносил, сериалы и фильмы приносил, а вот мультики еще нет. Вот вам для затравки 4 отрывка из старого мультика 1984 года «Контакты… Конфликты…». Сняли 40 лет назад, а актуально всё и по сей день 🙂
https://www.youtube.com/watch?v=edha3Krhick – про то, как «помогает» совещание и почему работягу не мотивирует прибавка.
https://www.youtube.com/watch?v=EH_3ukkNuwg – про то, как у нас выстроилась очередь СРОЧНОЙ РАБОТЫ уже вплоть до пенсии, а она всё продолжает прибывать.
https://www.youtube.com/watch?v=Ovs5LSl1yOk – встречал граждан, у которых был такой же режим планирования и приоритизации 🙂
https://www.youtube.com/watch?v=3LqSbUdz1sY – а это когда слова и аргументы слушать не хотят, но объясниться и договориться о дальнейшем надо.
Если у вас есть еще любимые серии, заносите в комментарии. Ну а если ситуации знакомы вам, то ставьте 💯
YouTube
Контакты и конфликты — совещание помогло
Контакты и конфликты 4 выпуск — совещание ещё никому не помогло