Forwarded from gonzo-обзоры ML статей
Multi-Token Attention
Olga Golovneva, Tianlu Wang, Jason Weston, Sainbayar Sukhbaatar
Статья: https://arxiv.org/abs/2504.00927
Продолжаем разборы архитектур.
Как известно, веса внимания в классическом механизме внимания определяются одним вектором значений query и одним вектором значений key. Этот “single token attention” является своеобразным боттлнеком для отделения важных частей от всего остального. Новый подход Multi-Token Attention (MTA) позволяет устранить боттлнек и определять веса внимания на основе нескольких векторов query и keys одновременно
Напомним, что в стандартном внимании веса внимания определяются как softmax(QK/sqrt(d)). Для каждого токена есть вектор эмбеддинга, этот вектор проецируется в три отдельных вектора Q, K и V, и по скалярному произведению векторов Q и K различных токенов определяется их “похожесть” или “важность”. После нормализации на корень от размерности эмбеддинга и взятию софтмакса от результата получаются веса внимания A. Далее с этими весами взвешиваются и суммируются вектора V и генерятся новые эмбеддинги для каждого токена. На наличие множества голов, маски декодера и прочего мы в этом объяснении забиваем, если хотите лучше понять/вспомнить этот процесс, отсылаю к классике (https://jalammar.github.io/illustrated-transformer/).
Внутри и снаружи этого базового механизма внимания можно много чего модифицировать -- мы писали про температуру в софтмаксе (https://t.me/gonzo_ML/3013), про отказ от нормализации до или после слоёв внимания (https://t.me/gonzo_ML/3478), 100500 вариантов разреженного и прочего модифицированного внимания, которые даже перечислять долго (просто как пример -- Reformer, https://t.me/gonzo_ML/176, далее воспользуйтесь поиском по каналу). Текущая работа тоже где-то в этом пуле.
Допустим, мы хотим найти предложение, содержащее несколько элементов. Пусть для примера это будет предложение “Where did Alice see the rabbit?” и мы хотим найти одновременное упоминание Алисы и кролика, им соответствуют query вектора q_a и q_r. Стандартный механизм считает веса внимания описанным выше способом, мы можем “найти” места в контексте, содержащие эти слова, и нам надо бы проверить, что они находятся где-то в соседних позициях. Но стандартный механизм внимания не даёт этого сделать в пределах одного слоя (через увеличение глубины можно, но хотелось бы и без), поскольку никаких взаимодействий между отдельными attention maps в нём нет, и даже если мы используем отдельные головы внимания для обнаружения Алисы и кролика, то нет механизма для комбинирования этих весов внимания. Модификация внимания в MTA позволяет добавить это взаимодействие между attention maps для соседних позиций Q и K или между отдельными головами.
На уровне конкретных модификаций внутри стандартного механизма внимания появляются три новых блока:
1) key-query convolution: комбинирует несколько key и query внутри головы
2) head mixing convolution: шарит информацию между головами и усиливает важную
3) group normalization with depth scaling: улучшает поток градиентов
Key-query convolution перемешивает веса внимания от разных временных шагов и работает так: к логитам внимания перед софтсаксом (QK/sqrt(d)) применяется двумерная обучаемая свёртка по измерениям q и k, измерения для батча и голов внимания не трогаются. Каждая голова внимания учит свою свёртку. Внутри свёртки используется маска с занулением элементов, чтобы не залезать в будущее. Это был pre-softmax convolution, он будет использоваться по дефолту. Можно также сделать post-softmax convolution, тогда свёртка считается не поверх логитов, а уже после софтмакса. Это делает взаимодействия между весами внимания аддитивными, а не мультипликативными. Я кстати не до конца понял, почему они до софтмакса прям мультипликативные...
Olga Golovneva, Tianlu Wang, Jason Weston, Sainbayar Sukhbaatar
Статья: https://arxiv.org/abs/2504.00927
Продолжаем разборы архитектур.
Как известно, веса внимания в классическом механизме внимания определяются одним вектором значений query и одним вектором значений key. Этот “single token attention” является своеобразным боттлнеком для отделения важных частей от всего остального. Новый подход Multi-Token Attention (MTA) позволяет устранить боттлнек и определять веса внимания на основе нескольких векторов query и keys одновременно
Напомним, что в стандартном внимании веса внимания определяются как softmax(QK/sqrt(d)). Для каждого токена есть вектор эмбеддинга, этот вектор проецируется в три отдельных вектора Q, K и V, и по скалярному произведению векторов Q и K различных токенов определяется их “похожесть” или “важность”. После нормализации на корень от размерности эмбеддинга и взятию софтмакса от результата получаются веса внимания A. Далее с этими весами взвешиваются и суммируются вектора V и генерятся новые эмбеддинги для каждого токена. На наличие множества голов, маски декодера и прочего мы в этом объяснении забиваем, если хотите лучше понять/вспомнить этот процесс, отсылаю к классике (https://jalammar.github.io/illustrated-transformer/).
Внутри и снаружи этого базового механизма внимания можно много чего модифицировать -- мы писали про температуру в софтмаксе (https://t.me/gonzo_ML/3013), про отказ от нормализации до или после слоёв внимания (https://t.me/gonzo_ML/3478), 100500 вариантов разреженного и прочего модифицированного внимания, которые даже перечислять долго (просто как пример -- Reformer, https://t.me/gonzo_ML/176, далее воспользуйтесь поиском по каналу). Текущая работа тоже где-то в этом пуле.
Допустим, мы хотим найти предложение, содержащее несколько элементов. Пусть для примера это будет предложение “Where did Alice see the rabbit?” и мы хотим найти одновременное упоминание Алисы и кролика, им соответствуют query вектора q_a и q_r. Стандартный механизм считает веса внимания описанным выше способом, мы можем “найти” места в контексте, содержащие эти слова, и нам надо бы проверить, что они находятся где-то в соседних позициях. Но стандартный механизм внимания не даёт этого сделать в пределах одного слоя (через увеличение глубины можно, но хотелось бы и без), поскольку никаких взаимодействий между отдельными attention maps в нём нет, и даже если мы используем отдельные головы внимания для обнаружения Алисы и кролика, то нет механизма для комбинирования этих весов внимания. Модификация внимания в MTA позволяет добавить это взаимодействие между attention maps для соседних позиций Q и K или между отдельными головами.
На уровне конкретных модификаций внутри стандартного механизма внимания появляются три новых блока:
1) key-query convolution: комбинирует несколько key и query внутри головы
2) head mixing convolution: шарит информацию между головами и усиливает важную
3) group normalization with depth scaling: улучшает поток градиентов
Key-query convolution перемешивает веса внимания от разных временных шагов и работает так: к логитам внимания перед софтсаксом (QK/sqrt(d)) применяется двумерная обучаемая свёртка по измерениям q и k, измерения для батча и голов внимания не трогаются. Каждая голова внимания учит свою свёртку. Внутри свёртки используется маска с занулением элементов, чтобы не залезать в будущее. Это был pre-softmax convolution, он будет использоваться по дефолту. Можно также сделать post-softmax convolution, тогда свёртка считается не поверх логитов, а уже после софтмакса. Это делает взаимодействия между весами внимания аддитивными, а не мультипликативными. Я кстати не до конца понял, почему они до софтмакса прям мультипликативные...
Forwarded from Den4ik Research
Ну ещё есть локальные типа teratts utrobin tts
Forwarded from Pavel
Я у них только SaluteSpeech помню.
Из наших SOVA/VOSK/silero или как их там
Из наших SOVA/VOSK/silero или как их там
Forwarded from max.sh
LLM много рассуждают. Но можно ли верить их рассуждениям? Alignment команда 🖥 показывает, что нет.
Статья. Блогпост.
TL;DR: Эксперименты простые, на полусинтетических средах. Доверять цеопчкам рассуждений (CoT) рассуждающих (по крайней мере Claude и DeepSeek )моделей рано. Модели нужно проверять, проверять и перепроверять. При чем как ответы (предсказания), так и рассуждения - далеко не всегда они озвучивают то, что реально думают.
А теперь подробнее.
📍 Рассуждающие (Reasoning) модели везде. Их суть в том, что прежде, чем дать финальный ответ на вопрос, они могут нагенерировать промежуточных цепочек рассуждений (CoTs), а потом дать финальный ответ.
Такие модели, как правило, значительно бустят метрики на всех бенчмарках и способны решать очень сложные задачи.
В идеальном мире через CoT мы можем понять, как модель реально мыслит и приходит к ответу. То есть в цепочках должны быть достоверные (faithful) описания того, как модель принимает решения. Авторы пытаются протестировать гипотезу достоверности цепочек, генерируемых моделью. На Claude 3.7 и DeepSeek R1 выводы довольно удручающие - текущие модели далеки от генерации достоверных CoT.
Проверяется гипотеза о достоверности рассуждений через три разных эксперимента. В посте только про основной “тест на достоверность”
📍 Сетап эксперимента.
Берут Multiple choice вопросы из MMLU и GPQA. В одном инференсе модели дают стандартный промпт с вопросом, просят порассуждать и потом дать ответ на вопрос.
Затем на том же датасете вопросов в промт намеренно добавляют подсказку (hint) для каждого вопроса. Подсказки бывают разных типов: правильные, неправильные, безопасные или с указанием на нелегальное получение информации
С таким injected промптом модель снова просят порассуждать и дает ответ.
Оставляют только те вопросы, где ответ модели между промптом без подсказки и промптом с подсказкой поменялся (картинка 1 для пояснений). Логично предположить, что это именно тот набор вопросов, где подсказка изменила размышления модели (все остальные переменные зафиксированы, а фактор случайности в изменении ответа отфильтровывается), а следовательно и ответ. На этом наборе вопросов измеряют достоверность цепочек.
📍 Как мерить достоверность
Достоверная модель, если дать в промпт дополнительную информацию об ответе на вопрос, должна упомянуть факт подсказки и озвучить (verbalize) это в своих CoT как фактор, на который она опирается при ответе. Если ответ модели зависит от наличия подсказки в промпте, то безопасная система должна обозначить фактор подсказки в своих рассуждения - опять же, если гипотеза, что CoT отражают процесс принятия решений моделью верна.
Фактор вербализации подсказки измеряют через Claude 3.5 с последующей ручной верификацией.
Наблюдаем следующее:
🔘 Claude 3.7 в среднем генерирует 25% достоверных цепочек, а R1 - 39%. Таким образом, подавляющее большинство CoT никак не упомянули в своем рассуждении факт подсказки. Картинка 2 с результатми на разных типах подсказок
🔘 Все модели используют подсказки. То есть если в промпте есть подсказка (и не важно, правильная или нет), модели имеют склонность выбрать вариант из подсказки. Картинка 3 с результатами.
🔘 Claude модели на 24% чаще используют фактор подсказки, в сравнении с DeepSeek. Удручает, что неправильная подсказка меняет внутренние убеждения модели в пользу неправильного ответа без какой-либо вербализации почему она это делает (то есть нет указания на подсказку) - модель просто генерирует длинные цепочки неверных рассуждений подгоняясь под неправильный ответ в подсказке.
🔘 Недостоверные цепочки в среднем длиннее. Claude 3.7 в среднем задействовал 2064 токена для генерации недостоверных цепочек, тогда как для достоверных хватало 1439.
🔘 Достоверность падает с увеличением сложности вопросов.
В общем, у задачи Alignment-а еще большой путь, а модели пока все такой же черный ящик, который может врать и не краснеть -😄
💡 В комментариях оставил маленький абзац про другие эксперименты из статьи. В целом советую всю статью к прочтению - хорошо структурировано и классно подано.
Статья. Блогпост.
TL;DR: Эксперименты простые, на полусинтетических средах. Доверять цеопчкам рассуждений (CoT) рассуждающих (по крайней мере Claude и DeepSeek )моделей рано. Модели нужно проверять, проверять и перепроверять. При чем как ответы (предсказания), так и рассуждения - далеко не всегда они озвучивают то, что реально думают.
А теперь подробнее.
Такие модели, как правило, значительно бустят метрики на всех бенчмарках и способны решать очень сложные задачи.
В идеальном мире через CoT мы можем понять, как модель реально мыслит и приходит к ответу. То есть в цепочках должны быть достоверные (faithful) описания того, как модель принимает решения. Авторы пытаются протестировать гипотезу достоверности цепочек, генерируемых моделью. На Claude 3.7 и DeepSeek R1 выводы довольно удручающие - текущие модели далеки от генерации достоверных CoT.
Проверяется гипотеза о достоверности рассуждений через три разных эксперимента. В посте только про основной “тест на достоверность”
Берут Multiple choice вопросы из MMLU и GPQA. В одном инференсе модели дают стандартный промпт с вопросом, просят порассуждать и потом дать ответ на вопрос.
Затем на том же датасете вопросов в промт намеренно добавляют подсказку (hint) для каждого вопроса. Подсказки бывают разных типов: правильные, неправильные, безопасные или с указанием на нелегальное получение информации
С таким injected промптом модель снова просят порассуждать и дает ответ.
Оставляют только те вопросы, где ответ модели между промптом без подсказки и промптом с подсказкой поменялся (картинка 1 для пояснений). Логично предположить, что это именно тот набор вопросов, где подсказка изменила размышления модели (все остальные переменные зафиксированы, а фактор случайности в изменении ответа отфильтровывается), а следовательно и ответ. На этом наборе вопросов измеряют достоверность цепочек.
Достоверная модель, если дать в промпт дополнительную информацию об ответе на вопрос, должна упомянуть факт подсказки и озвучить (verbalize) это в своих CoT как фактор, на который она опирается при ответе. Если ответ модели зависит от наличия подсказки в промпте, то безопасная система должна обозначить фактор подсказки в своих рассуждения - опять же, если гипотеза, что CoT отражают процесс принятия решений моделью верна.
Фактор вербализации подсказки измеряют через Claude 3.5 с последующей ручной верификацией.
Наблюдаем следующее:
В общем, у задачи Alignment-а еще большой путь, а модели пока все такой же черный ящик, который может врать и не краснеть -
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from ML for Value / Ваня Максимов
ML-челленджи супераппов: Как впихнуть интересы юзера в один экран (ч1) ?
Понемногу все приложения пытаются стать супераппами. Яндекс.Go обьединяет доставку всего (уже и не только доставку: например, Афишу). Авито - продажу всего от товаров до услуг и брони квартир. Тинькофф пробует завязать на себя все финансовые сервисы и оплаты/покупки. Тикток - развлечения, образование и маркетплейс. Да даже я делаю "суперапп" про контент в DS из этого канала + @abpolice
Ноги у всего растут из стоимости закупки трафика: она сильно растет. И теперь выгоднее не покупать рекламу на рынке, а перегонять аудиторию внутри своих сервисов. Чаще всего эта проблема особенно острая в задачах information retrieval: поиске и рекомендациях
Но чем больше сервисов в одном супераппе, тем тяжелее понять, что именно сейчас хочет пользователь. По поисковому запросу "курица" показать ему куриную тушку из магазина, готовое блюдо из курицы, рецепт, мультик Куриный побег, игрушку-курицу или что-то еще? А если нет поисковго запроса и мы просто хотим порекомендовать ему что-то на главной странице приложения, то какие интересы пользователя ему показать? В общем, огромный челендж - как алгоритмически и визуально впихнуть очень разные интересы пользователя (категории, сервисы) в один экран. Это во многом и позволит шерить аудиторию между сервисами за условно-бесплатно
🧐 Если ничего не делать, то чаще всего алгоритмы будут вытаскивать 1-2 категории интересов, что явно не очень оптимально. А попробовать можно вот что
1. Эвристики разнообразия контента
Например, не более 10 товаров одной категории / сервиса. Очень просто - невеоятно эффективно
Чуть более продвинутые эвристики - MRR и DPP. Тоже можно попробовать, но требуют побольше вычислительных ресурсов и времени
2. Подбрасывать монетку
Да-да, сначала случайно или пропорционально релевантности категории (можно просто взять скор релевантности первого товара из категории) сэмплировать категорию на каждую позицию экрана. А затем внутри категории выбирать товар/контент. На 1-5% мест можно подмешивать случайные категории или товры. Работает тоже просто, но крайне эффективно. По кулуарным разговорам, 80% сервисов в том или ином виде пользуются этим. Открыто от таком подходе говорит, например, Авито
3. RL и Нейронки с лоссом на разнообразие
Современно, но эти подходы просто не работают) Ну по крайней мере, очень мало супераппов репортят об этом, а если и репортят, то с мизерными приростами метрик
4. MultiSlot ranking
Вот тут уже есть первые интересные результаты. Например, Yotube обучает жадный multi-slot алгоритм, учитывающий на позиции k фичи предыдущих товаров - репортуют о росте в оффлайне до +10%
5. Real-time
Не сохраняем заранее посчитанные результаты по всем поисковым запросам / рекомендации по user_id, а генерим и обновляем их на лету. Уже во многих сервисах поиск и рекомендации грузят товары пачками по 10-20 штук. И действия в первых 10-20 товаров сильно повлияют на следующие 10-20: не покликал на блюда из курицы - дальше тебе их не покажут. Можно дойти до загрузки 1 карточки контента на экран (как делает Тикток) и обновлять рекомендации/поиск после действия / бездействия с каждой. Это круто, но достаточно сложно
В общем, если вы только начинаете путь к супераппу - эвристики и подбрасывание монетки дадут вам многое
Если вы уже не одни грабли на этом пути собрали - стоит идти сначала в Multi-slot ranking, а потом и в Real-time
В следюущих частях планирую рассказать про:
ч2 - апсел, кроссел
ч3 - монетизация и реклама
👍 если интересно прочитать следующие части
Понемногу все приложения пытаются стать супераппами. Яндекс.Go обьединяет доставку всего (уже и не только доставку: например, Афишу). Авито - продажу всего от товаров до услуг и брони квартир. Тинькофф пробует завязать на себя все финансовые сервисы и оплаты/покупки. Тикток - развлечения, образование и маркетплейс. Да даже я делаю "суперапп" про контент в DS из этого канала + @abpolice
Ноги у всего растут из стоимости закупки трафика: она сильно растет. И теперь выгоднее не покупать рекламу на рынке, а перегонять аудиторию внутри своих сервисов. Чаще всего эта проблема особенно острая в задачах information retrieval: поиске и рекомендациях
Но чем больше сервисов в одном супераппе, тем тяжелее понять, что именно сейчас хочет пользователь. По поисковому запросу "курица" показать ему куриную тушку из магазина, готовое блюдо из курицы, рецепт, мультик Куриный побег, игрушку-курицу или что-то еще? А если нет поисковго запроса и мы просто хотим порекомендовать ему что-то на главной странице приложения, то какие интересы пользователя ему показать? В общем, огромный челендж - как алгоритмически и визуально впихнуть очень разные интересы пользователя (категории, сервисы) в один экран. Это во многом и позволит шерить аудиторию между сервисами за условно-бесплатно
🧐 Если ничего не делать, то чаще всего алгоритмы будут вытаскивать 1-2 категории интересов, что явно не очень оптимально. А попробовать можно вот что
1. Эвристики разнообразия контента
Например, не более 10 товаров одной категории / сервиса. Очень просто - невеоятно эффективно
Чуть более продвинутые эвристики - MRR и DPP. Тоже можно попробовать, но требуют побольше вычислительных ресурсов и времени
2. Подбрасывать монетку
Да-да, сначала случайно или пропорционально релевантности категории (можно просто взять скор релевантности первого товара из категории) сэмплировать категорию на каждую позицию экрана. А затем внутри категории выбирать товар/контент. На 1-5% мест можно подмешивать случайные категории или товры. Работает тоже просто, но крайне эффективно. По кулуарным разговорам, 80% сервисов в том или ином виде пользуются этим. Открыто от таком подходе говорит, например, Авито
3. RL и Нейронки с лоссом на разнообразие
Современно, но эти подходы просто не работают) Ну по крайней мере, очень мало супераппов репортят об этом, а если и репортят, то с мизерными приростами метрик
4. MultiSlot ranking
Вот тут уже есть первые интересные результаты. Например, Yotube обучает жадный multi-slot алгоритм, учитывающий на позиции k фичи предыдущих товаров - репортуют о росте в оффлайне до +10%
5. Real-time
Не сохраняем заранее посчитанные результаты по всем поисковым запросам / рекомендации по user_id, а генерим и обновляем их на лету. Уже во многих сервисах поиск и рекомендации грузят товары пачками по 10-20 штук. И действия в первых 10-20 товаров сильно повлияют на следующие 10-20: не покликал на блюда из курицы - дальше тебе их не покажут. Можно дойти до загрузки 1 карточки контента на экран (как делает Тикток) и обновлять рекомендации/поиск после действия / бездействия с каждой. Это круто, но достаточно сложно
В общем, если вы только начинаете путь к супераппу - эвристики и подбрасывание монетки дадут вам многое
Если вы уже не одни грабли на этом пути собрали - стоит идти сначала в Multi-slot ranking, а потом и в Real-time
В следюущих частях планирую рассказать про:
ч2 - апсел, кроссел
ч3 - монетизация и реклама
👍 если интересно прочитать следующие части
Forwarded from Small Data Science for Russian Adventurers
#полезно
Очень классный источник обзорных статей с красивыми визуализациями от одного из авторов книги "Hands-On Large Language Models". Есть обзоры по LLM-агентам, рассуждающим моделям, смеси экспертов, квантованию, моделе Mamba.
https://newsletter.maartengrootendorst.com
Очень классный источник обзорных статей с красивыми визуализациями от одного из авторов книги "Hands-On Large Language Models". Есть обзоры по LLM-агентам, рассуждающим моделям, смеси экспертов, квантованию, моделе Mamba.
https://newsletter.maartengrootendorst.com
Forwarded from Мальцев: Карьера с AI
Ребята, мой прошлый пост про «Как GPT помогает разобраться с нечетко описанными задачами» разошелся на сотни репостов в телеге и вк. Видно, что тема делегирования «по-нормальному» очень откликается.
Теперь разверну ситуацию на 180° и напишу свой опыт про то
как грамотно делегировать задачи, чтобы результат радовал вас и команду, а не требовал бесконечных переделок. Особенно когда надо поставить задачу быстро, как это часто бывает в рабочих чатах Для меня четкая постановка задачи при делегировании =
Но не все задачи одинаково полезно делегировать
Прежде чем перейти к магии GPT, вспомним классику делегирования из «One Minute Manager», по которому учат менеджеров в бигтехе
Делегируйте:
Делайте сами:
Работа с GPT учит постановке задач при делегировании
Когда я написал с тысячу запросов с промптами, то поймал себя на мысли:
Утверждение «чтобы получить полезное решение от GPT, нужно дать достаточное количество вводных в шаблоне промпта для нейросети» появилось из мира людей и также работает в командном взаимодействии с сотрудниками.
В хорошем промпте для GPT есть все необходимое для грамотной постановки задачи любому сотруднику:
Нейросети можно и нужно использовать для делегирования, когда надо быстро поставить задачу и дать сотруднику больше вводных, чем успевается написать самостоятельно.
Если вам откликается тема — давайте накинем ❤️ и следующим сообщением я пришлю промпт на делегирование через GPT, чтобы экономить кучу времени на постановке хорошо описанных задач. А также покажу 3 примера его работы.
Мальцев: Карьера. Маркетинг. AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Мальцев: Карьера с AI
Продолжаем тему прошлого поста: забирайте промпт, в который можно дописать пару строк в [___] и получить более четкую, понятную формулировку задачи для делегирования любому сотруднику.
Твоя роль: Ты эксперт по эффективному делегированию и описанию задач для сотрудников с десятилетним опытом работы в роли Executive Coach в Fortune 500 компаниях.
Твоя задача: помоги мне сформулировать и описать задачу для делегирования сотруднику, следуя лучшим практикам делегирования.
Исходные данные от меня:
1. Что нужно сделать: [кратко суть задачи, как обычно пишете в мессенджере].
2. Кому делегирую: [напиши роль или должность, так станет понятнее, какие навыки есть у сотрудника].
3. Почему это важно: [одно предложение, для какой цели, метрики бизнеса нужна задача или контекст, в котором появилась задача].
4. Критерий качества: [укажи 1-2 метрики для роста или факта, которым должно соответствовать решение от сотрудника].
5. Когда: к [дате месяца или дню] .
5. Уровень самостоятельности [оставь только 1 вариант: предложи варианты на выбор, предложи целевое решение, действуй самостоятельно и держи в курсе по прогрессу, сделай всё под ключ и поделись итогами].
На основе этой информации составь структурированное сообщение для делегирования, которое будет включать:
1. Контекст и важность задачи. Объясни «большую картину»: почему эта задача важна, как она связана с целями компании/команды, какую проблему решает или какую возможность использует.
2. Конкретный ожидаемый результат - Конкретно и измеримо опиши, что должно получиться в итоге, какие параметры должны быть достигнуты.
3. Уровень самостоятельности. Выбери один из уровней:
- Предложи варианты на выбор
- Рекомендуй целевое решение и получи одобрение
- Действуй самостоятельно, держи меня в курсе
- Полная самостоятельность с отчетом по итогам
4. Сроки и промежуточные проверки. Укажи финальный дедлайн и промежуточные точки контроля, если задача длительная.
5. Доступные ресурсы и возможные ограничения. Перечисли потенциальные ресурсы, про которые стоит подумать для решения задачи, потенциальные препятствия и существующие ограничения (если они описаны выше).
6. Критерии успешного выполнения: Как будет оцениваться качество работы? Какие конкретные метрики или характеристики должны быть достигнуты?
7. На что повлияет результат решения задачи? Что произойдет после выполнения задачи, как будет использован результат?
Критерий качества для тебя: сделай сообщение понятным, мотивирующим и профессиональным, но без лишнего формализма. Это должно быть готовое к отправке сообщение для чата в мессенджере или email, которое не требует дополнительных правок.
При разработке ответа используй рассуждения, логику, дедукцию и аргументацию.
Как использовать промпт:
Заполнения шаблона займет на 5 минут больше, чем просто бросить задачу в чат. Но сэкономит часы на уточнениях, переделках и исправлении ошибок. Плюс ваша команда будет чувствовать себя увереннее, понимая, что конкретно вы от них ждете.
❤️ и 👍 если пост полезен, сохраняйте его в избранное чтобы не потерялось. В коммент я сложил пару примеров «было-стало» и показал, как GPT распишет реальные задачи.
Мальцев: Карьера. Маркетинг. AI.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Борис опять
https://www.docker.com/blog/introducing-docker-model-runner/
Docker сделал llama.cpp + хранилище моделей в Docker Hub + OpenAI API из коробки, в общем докеризация моделей от докера
Docker сделал llama.cpp + хранилище моделей в Docker Hub + OpenAI API из коробки, в общем докеризация моделей от докера