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 выпуск — совещание ещё никому не помогло