Forwarded from Quant Valerian
🤝 КОМАНДА vs РАБОЧАЯ ГРУППА
У обоих есть общая цель. Но в команде каждый действительно хочет этой цели достичь. В рабочей группе каждый просто делает свою работу, что должно продвигать группу в сторону цели, но у сотрудников отсутствует персональное стремление к этой общей цели.
⭐️ МОДЕЛЬ ТАКМАНА И ЕЁ ОГРАНИЧЕНИЯ
Модель Такмана описывает динамику развития группы через пять стадий.
В организационной психологии нет единого мнения о развитии группы.
Стадийный подход рассматривает процесс командообразования как последовательность этапов.
Циклический подход предполагает, что развитие группы происходит в виде циклов стабильности и перемен.
Модель прерывистого равновесия Конника и Герчика описывает рабочие группы с дедлайном.
Все модели групповой динамики имеют свои ограничения.
• Модель Такмана подходит для психотерапевтических групп, но не для рабочих.
• Модель прерывистого равновесия Конника и Герчика применима к рабочим группам с дедлайном.
⭐️ ПРОЦЕСС КОМАНДООБРАЗОВАНИЯ В РЕАЛЬНОСТИ
Рабочая группа проходит через этапы формирования, напряжения, кризиса и системных изменений.
Процесс может протекать с разной скоростью и степенью выраженности.
Группа может возвращаться на предыдущие стадии развития.
Процесс командообразования может протекать по-разному в зависимости от обстоятельств.
Группа может избежать стадии шторма.
Влияние на процесс командообразования зависит от этапа развития группы.
У обоих есть общая цель. Но в команде каждый действительно хочет этой цели достичь. В рабочей группе каждый просто делает свою работу, что должно продвигать группу в сторону цели, но у сотрудников отсутствует персональное стремление к этой общей цели.
⭐️ МОДЕЛЬ ТАКМАНА И ЕЁ ОГРАНИЧЕНИЯ
Модель Такмана описывает динамику развития группы через пять стадий.
В организационной психологии нет единого мнения о развитии группы.
Стадийный подход рассматривает процесс командообразования как последовательность этапов.
Циклический подход предполагает, что развитие группы происходит в виде циклов стабильности и перемен.
Модель прерывистого равновесия Конника и Герчика описывает рабочие группы с дедлайном.
Все модели групповой динамики имеют свои ограничения.
• Модель Такмана подходит для психотерапевтических групп, но не для рабочих.
• Модель прерывистого равновесия Конника и Герчика применима к рабочим группам с дедлайном.
⭐️ ПРОЦЕСС КОМАНДООБРАЗОВАНИЯ В РЕАЛЬНОСТИ
Рабочая группа проходит через этапы формирования, напряжения, кризиса и системных изменений.
Процесс может протекать с разной скоростью и степенью выраженности.
Группа может возвращаться на предыдущие стадии развития.
Процесс командообразования может протекать по-разному в зависимости от обстоятельств.
Группа может избежать стадии шторма.
Влияние на процесс командообразования зависит от этапа развития группы.
Forwarded from Мягкие техники
Третий признак рабочего аргумента
Помните, как на встрече один неубедительный аргумент с вашей стороны мог сорвать весь план? Или как один слабый довод от собеседника на встрече заставлял вас начать сомневаться в его правоте. Или тот случай, когда вы пытались доказать свою идею, но аргументы просто не складывались в логичную цепочку.
Давайте обсудим почему так происходит: у нас в меню последний, третий, признак рабочего аргумента и подытожим тему аргументации.
Предыдущие два признака были: подходит под тему дискуссии и сформулирован на языке выгод для второй стороны.
⸻
Признак рабочего аргумента №3: Аргумент сформулирован ёмко, то есть соответствует принципу «достаточности»
В идеале аргументы подтверждают тезис, а тезис логически вытекает из аргументов. Для этого, как правило, приходится приводить несколько аргументов: одного чаще всего недостаточно. При этом все эти аргументы должны быть достаточно убедительными.
Во втором примере аргумент про ускорение релизов фичей выглядит как пустые красивые слова, которые никак не подтверждены — их прицепили вагончиком к нормальному первому аргументу о стабильном результате.
Есть риск, что слушатель, заметив такой неказистый второй аргумент, напряжётся и с подозрением отнесётся так же и к первому тезису.
⸻
В качестве упражнения попробуйте на этой неделе выбирать один-два аргумента, но чтобы они были максимально убедительными и выстраивать диалог вокруг них.
Мне такое упражнение помогло понять, почему я вываливаю много аргументов, но они пролетают мимо собеседника.
⸻
Итого, мы разобрали три признака рабочего аргумента:
1. Подходит под тему дискуссии;
2. На языке выгод для второй стороны;
3. Достаточный.
Чтобы аргументация была прочной:
— убедитесь, что аргументы, которые вы приводите, будут понятны для собеседника;
— оставьте по возможности только те аргументы, с которыми собеседнику будет легко согласиться (больше — не значит лучше).
Виды аргументов, которые сложно критиковать (но не невозможно):
— статистика с подробным описанием методологии и выводами из исследования;
— аксиомы и общепринятые факты;
— официальные документы и законы.
⸻
В этот раз без «тёмной стороны» :). Нашли что-то полезное в этой заметке?
Я не размещаю рекламу и не делаю интеграции. Благодарность для меня — ваши лайки, комменты и репосты в других каналах.
Помните, как на встрече один неубедительный аргумент с вашей стороны мог сорвать весь план? Или как один слабый довод от собеседника на встрече заставлял вас начать сомневаться в его правоте. Или тот случай, когда вы пытались доказать свою идею, но аргументы просто не складывались в логичную цепочку.
Давайте обсудим почему так происходит: у нас в меню последний, третий, признак рабочего аргумента и подытожим тему аргументации.
Предыдущие два признака были: подходит под тему дискуссии и сформулирован на языке выгод для второй стороны.
⸻
Признак рабочего аргумента №3: Аргумент сформулирован ёмко, то есть соответствует принципу «достаточности»
В идеале аргументы подтверждают тезис, а тезис логически вытекает из аргументов. Для этого, как правило, приходится приводить несколько аргументов: одного чаще всего недостаточно. При этом все эти аргументы должны быть достаточно убедительными.
Например
Тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом.»
Связка аргументов, каждый сформулирован достаточно ёмко и убедительно: «Чтобы стабильно добиваться поставленных KPI, мы строго придерживаемся процесса оценки всех новых задач. Это также позволяет нам расставлять приоритеты осознанно, учитывать загрузку, риски и взаимосвязи между задачами. В итоге мы релизим фичи быстрее и качественнее».
Пример, где аргументы не соответствуют принципу достаточности: «Чтобы стабильно добиваться поставленных KPI, мы строго придерживаемся процесса оценки всех новых задач. Это также позволяет нам релизить фичи быстрее и качественнее».
Во втором примере аргумент про ускорение релизов фичей выглядит как пустые красивые слова, которые никак не подтверждены — их прицепили вагончиком к нормальному первому аргументу о стабильном результате.
Есть риск, что слушатель, заметив такой неказистый второй аргумент, напряжётся и с подозрением отнесётся так же и к первому тезису.
⸻
В качестве упражнения попробуйте на этой неделе выбирать один-два аргумента, но чтобы они были максимально убедительными и выстраивать диалог вокруг них.
Мне такое упражнение помогло понять, почему я вываливаю много аргументов, но они пролетают мимо собеседника.
⸻
Итого, мы разобрали три признака рабочего аргумента:
1. Подходит под тему дискуссии;
2. На языке выгод для второй стороны;
3. Достаточный.
Чтобы аргументация была прочной:
— убедитесь, что аргументы, которые вы приводите, будут понятны для собеседника;
— оставьте по возможности только те аргументы, с которыми собеседнику будет легко согласиться (больше — не значит лучше).
Виды аргументов, которые сложно критиковать (но не невозможно):
— статистика с подробным описанием методологии и выводами из исследования;
— аксиомы и общепринятые факты;
— официальные документы и законы.
⸻
В этот раз без «тёмной стороны» :). Нашли что-то полезное в этой заметке?
Я не размещаю рекламу и не делаю интеграции. Благодарность для меня — ваши лайки, комменты и репосты в других каналах.
Forwarded from Пристанище Дата Сайентиста (TelepostBot)
RouteLLM снижает ваши расходы на инференс LLM в 3,6 раза 💵.
Он выбирает использовать сильную или слабую LLM в зависимости от сложности запроса пользователя. Это оптимизирует баланс между стоимостью и качеством ответа.
Вы можете использовать его напрямую через их Python-библиотеку.
Вот как работает модель:
- Модель обучена на предпочтениях, полученных из 80 000 сражений на платформе Chatbot Arena.
- Они группируют модели по уровням, чтобы справиться с разреженностью меток. Сильные модели берутся из топ-уровней, а слабые — из третьего уровня.
- Они тестируют разные подходы к маршрутизации, включая матричную факторизацию, классификатор на основе BERT, ранжирование с учетом сходства (SW) и даже каузальный классификатор Llama 3 8B.
- Маршрутизатор на основе матричной факторизации снижает затраты до 3,66 раза, сохраняя качество, сопоставимое с GPT-4.
Эти маршрутизаторы хорошо обобщаются на разные пары сильных и слабых моделей без необходимости повторного обучения.
Статья
Он выбирает использовать сильную или слабую LLM в зависимости от сложности запроса пользователя. Это оптимизирует баланс между стоимостью и качеством ответа.
Вы можете использовать его напрямую через их Python-библиотеку.
Вот как работает модель:
- Модель обучена на предпочтениях, полученных из 80 000 сражений на платформе Chatbot Arena.
- Они группируют модели по уровням, чтобы справиться с разреженностью меток. Сильные модели берутся из топ-уровней, а слабые — из третьего уровня.
- Они тестируют разные подходы к маршрутизации, включая матричную факторизацию, классификатор на основе BERT, ранжирование с учетом сходства (SW) и даже каузальный классификатор Llama 3 8B.
- Маршрутизатор на основе матричной факторизации снижает затраты до 3,66 раза, сохраняя качество, сопоставимое с GPT-4.
Эти маршрутизаторы хорошо обобщаются на разные пары сильных и слабых моделей без необходимости повторного обучения.
Статья
Forwarded from ML Advertising
Сделал подборку туториалов по промпт инжинирингу для LLM:
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Anthropic
https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
https://github.com/anthropics/prompt-eng-interactive-tutorial
OpenAI
https://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api
Супер методичка от Гугла по Gemini
https://services.google.com/fh/files/misc/gemini-for-google-workspace-prompting-guide-101.pdf
Материалы на русском
https://www.promptingguide.ai/ru
Хотя каждый пишет доки по промптам под свою конкретную архитектуру и апишку, но в целом практики применимы ко всем моделям.
Сохраняем себе!
Claude API Docs
Prompt engineering overview
Claude API Documentation
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №4. Choosing Technologies Across the Data Engineering Lifecycle. Часть №3
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Завершаю пост по 4й главе заметками автора про финансовые вопросы в инженерии, а именно как считать стоимость.
🔹Total Cost of Ownership (TCO, полная стоимость владения) - это совокупная стоимость решения, включающая как прямые, так и косвенные затраты.
Их можно разделить на категории:
- капитальные (СAPEX) - затраты, на приобретение или обновление необоротных активов.
- операционные (OPEX) - связанные с текущей деятельностью компании и влияющие на её операционную прибыль.
С учетом того что облачные сервисы подразумевают регулярные платежи то расходы на инфраструктуру легко укладываются в операционные расходы. On-premise инфраструктура попадает в CAPEX так как сначала нужно провести анализ, согласовать бюджет, найти поставщика, дождаться поставки, ввести железо в эксплуатацию.
🔹Total Opportunity Cost of Ownership (TOCO, альтернативная стоимость владения) – это цена упущенных возможностей, связанных с выбором конкретной технологии, архитектуры или процесса.
Анализ TOCO помогает избежать риска "технологической ловушки", когда выбранное решение ограничивает развитие или устаревает, не позволяя компании адаптироваться к изменениям. Пример который приходит на ум: Oracle vs PostgreSQL, первый подразумевает vendor lock, лицензии итп. А второй есть в любом облаке + можно поднять самому.
Еще можно разобрать TOCO на примере on premise или cloud.
К упущенным возможностям при покупке своего железа можно отнести:
- заморозку капитала (вместо того чтобы вложить деньги в то что приносит деньги явно мы вкладываемся в то что даст отдачу не сразу)
- гибкость, ведь железо может устареть и потерять в цене.
- риск поломки, и как следствие риск частично. или полной остановки процессов
Но это не значит что все срочно бежим в облака, свое железо это дыра в бюджете, ведь в некоторых ситуациях вкладываться в свое железо будет выгоднее чем в облако, так как у компании могут быть свои упущенные возможности связанные с этим, примеры выше это чисто для наглядности.
🔹FinOps – это практика (eщё один buzzword / Ops) управления затратами на облачные ресурсы с целью оптимизации расходов и максимизации бизнес-ценности. Как получать больше и при этом тратить меньше.
Я в дисциплину не погружался, но вижу что материалов в сети предостаточно, видимо это действительно отдельный пласт знаний который привнесли облака.
Расскажите в комментариях как считаете стоимость своей инфры🙂
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №5. Data Generation in Source Systems. Часть №1 Источники исходных данных для Data системы.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.
Информация о том где лежат данные, процессе зарождения и уникальных свойствах имеет решающее значение перед началом работы с необработанными данными и построением Data систем. Важно помнить, что исходные системы, как правило, вне нашего контроля как специалистов по обработке данных.
На что следует обратить внимание:
- Безопасность: зашифрованы ли данные, доступен ли доступ через общедоступный Интернет или VPN, защищены ли ключи-токены, доверяете ли вы исходной системе.
- Управление: кто управляет данными, каково качество данных, какова схема, правила.
- DataOps: автоматизация, наблюдаемость, реагирование на инциденты.
- Архитектура: надежность, долговечность, доступность.
- Разработка программного обеспечения: сетевая связность, аутентификация, cценарии доступа, оркестрация.
Источники данных
🔹Файл - это последовательность байт, обычно хранящаяся на диске. Эти файлы имеют свои особенности и могут быть:
- структурированные (Excel, CSV),
- полуструктурированные (JSON, XML, CSV),
- неструктурированные (TXT, CSV).
В структурированных также есть очень популярные форматы для обработки данных (особенно больших данных):
- Parquet
- ORC
- Avro.
🔹API - это стандартный способ обмена данными в облаке, для платформ SaaS и между внутренними системами компании.
Примеры:
- REST
- GraphQL
- WebHooks
- RPC
🔹СУБД - (в рамках этой заметки нас интересует OLTP СУБД), хранит состояние и подходит для серверных приложений с высокой степенью параллелизма. Однако такие СУБД не очень хорошо подходят для аналитики, где для выполнения одного запроса требуется сканировать большой объем данных. Часто небольшие компании запускают аналитику непосредственно по протоколу OLTP. Эта схема работает в краткосрочной перспективе, но в конечном счете не поддается масштабированию.
Характеристики OLTP СУБД:
- считывает и записывает отдельные записи с высокой скоростью
- низкая задержка
- высокий уровень параллелизма (обрабатывает тысячи операций чтения и записи в секунду)
Важное свойство большинства СУБД это предоставляемые гарантии к транзакциям. Выделяют 2 парадигмы - ACID и BASE. Их нужно учитывать Data инженеру при интеграции с системой источником.
🔹OLAP СУБД - предназначены для обработки аналитических запросов, но неэффективны при поиске отдельных записей.
Такие системы обычно предполагают сканирование блоков данных размером не менее 100 МБ для каждого запроса. Попытка выполнить тысячи отдельных запросов в секунду может привести к перегрузке системы, если только она не будет объединена со слоем кэширования.
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Fundamentals of Data Engineering. Глава №5. Data Generation in Source Systems. Часть №2 Важные термины и паттерны в контексте Data Generation
🔹Change Data Capture (CDC)
CDC это прием подразумевающий что мы извлекаем из СУБД каждое событие изменения состояния (вставка, обновление, удаление).
CDC используется для:
- репликации между базами данных практически в режиме реального времени
- создания потока событий для последующей обработки.
🔹Логи / Журнал СУБД как источник информации
Журнал базы данных могут быть очень полезным инструментом для создания Data систем, в частности стать источником информации для CDC системы, в результате работы которой можно получить поток событий изменений СУБД.
Журнал фиксирует основную информацию о событии (запросе) + метаданные (пользователь, настройки итп)
Журнал можно хранить по разному. Бинарный формат эффективен с точки зрения хранения и ввода-вывода, в то время как полуструктурированный текст переносимый и легко парсится.
🔹CRUD (Create, Read, Update, Destroy)
CRUD - это термин описывающий основные операции над данными в программировании. Он широко используется в API и базах данных для хранения и извлечения данных.
🔹Insert-only сценарий
Подход "Только для вставки" подразумевает что все данные в хранилище неизменяемые, следовательно если нам требуется внести изменение то мы создаем новые строки с измененным состоянием.
Основной известный мне пример такого подхода - событийные системы и брокеры сообщений. Event Sourcing и вот это вот всё. Важно помнить что на больших нагрузках хранилище может очень быстро распухнуть и это нужно закладывать в план масштабирования.
🔹Change Data Capture (CDC)
CDC это прием подразумевающий что мы извлекаем из СУБД каждое событие изменения состояния (вставка, обновление, удаление).
CDC используется для:
- репликации между базами данных практически в режиме реального времени
- создания потока событий для последующей обработки.
🔹Логи / Журнал СУБД как источник информации
Журнал базы данных могут быть очень полезным инструментом для создания Data систем, в частности стать источником информации для CDC системы, в результате работы которой можно получить поток событий изменений СУБД.
Журнал фиксирует основную информацию о событии (запросе) + метаданные (пользователь, настройки итп)
Журнал можно хранить по разному. Бинарный формат эффективен с точки зрения хранения и ввода-вывода, в то время как полуструктурированный текст переносимый и легко парсится.
🔹CRUD (Create, Read, Update, Destroy)
CRUD - это термин описывающий основные операции над данными в программировании. Он широко используется в API и базах данных для хранения и извлечения данных.
🔹Insert-only сценарий
Подход "Только для вставки" подразумевает что все данные в хранилище неизменяемые, следовательно если нам требуется внести изменение то мы создаем новые строки с измененным состоянием.
Основной известный мне пример такого подхода - событийные системы и брокеры сообщений. Event Sourcing и вот это вот всё. Важно помнить что на больших нагрузках хранилище может очень быстро распухнуть и это нужно закладывать в план масштабирования.
Forwarded from LLM под капотом
Можно ли использовать LLM для оптимизации промптов?
Время от времени кто-нибудь в чате поднимает этот вопрос. Более того, я сам в курсе рассказывал про использование мощных моделей в дистилляции инструкций для моделей послабее.
Казалось бы, что может быть сложного в том, чтобы задать вопрос:
А потом просто автоматизировать процесс перебора вариантов.
Проблема в том, что в итоге будет ерунда и каша. LLM по своей природе усредняют ответы, чтобы понравиться среднему читателю. Их к этому приучили через RLHF. На скриншоте пример того, как ChatGPT o1 pro пару минут назад у меня банально скатилась в китайский, настолько она старалась сгладить логические углы.
А при работе с какими-то исключениями и конкретными кейсами нам не нужно сглаживать углы. Наоборот, надо раскручивать размышления, раскапывать нестыковки.
Поэтому лучше работает, когда мы даем мощной LLM материал для размышлений и просим ее проанализировать ошибки. А потом глазами просматриваем результаты и сами изменяем промпт.
Получается в итоге тот же паттерн "Human in the Loop", даже для оптимизации логических блоков. Как без него обойтись в разработке систем с LLM под капотом - я пока не знаю.
Ваш, @llm_under_hood 🤗
Время от времени кто-нибудь в чате поднимает этот вопрос. Более того, я сам в курсе рассказывал про использование мощных моделей в дистилляции инструкций для моделей послабее.
Казалось бы, что может быть сложного в том, чтобы задать вопрос:
Эй, ChatGPT, вот тебе исходный промпт и вот результаты его работы. Перепиши промпт так, чтобы этих ошибок больше не было.
А потом просто автоматизировать процесс перебора вариантов.
Проблема в том, что в итоге будет ерунда и каша. LLM по своей природе усредняют ответы, чтобы понравиться среднему читателю. Их к этому приучили через RLHF. На скриншоте пример того, как ChatGPT o1 pro пару минут назад у меня банально скатилась в китайский, настолько она старалась сгладить логические углы.
А при работе с какими-то исключениями и конкретными кейсами нам не нужно сглаживать углы. Наоборот, надо раскручивать размышления, раскапывать нестыковки.
Поэтому лучше работает, когда мы даем мощной LLM материал для размышлений и просим ее проанализировать ошибки. А потом глазами просматриваем результаты и сами изменяем промпт.
Получается в итоге тот же паттерн "Human in the Loop", даже для оптимизации логических блоков. Как без него обойтись в разработке систем с LLM под капотом - я пока не знаю.
Ваш, @llm_under_hood 🤗
Forwarded from LLM под капотом
Новую PDF распознавалку от IBM подвезли - SmolDocling
Это vision LM в 256M. Говорят, что работает лучше Qwen2.5VL, но не со всеми языками. Импонирует то, что модель извлекает не просто текст, а сразу структуру.
Что там под капотом?
- Это vision LM со специальными токенами для элементов markdown
- Основана на SmolVLM-256M — самой компактной vision LM.
- Обучена на страницах и транскрипциях Docling (с использованием нового формата DocTags для лучшего отображения элементов и их местоположения).
- Читает документ за 0.35 секунды (на A100) при использовании 0.5 GB VRAM.
- Доступна в Hugging Face transformers и vLLM.
Модельку качать тут, пробовать тут.
Кто-нибудь уже пробовал на своих задачах?
Ваш, @llm_under_hood 🤗
PS: Whitepaper: https://arxiv.org/html/2503.11576v1
Это vision LM в 256M. Говорят, что работает лучше Qwen2.5VL, но не со всеми языками. Импонирует то, что модель извлекает не просто текст, а сразу структуру.
Что там под капотом?
- Это vision LM со специальными токенами для элементов markdown
- Основана на SmolVLM-256M — самой компактной vision LM.
- Обучена на страницах и транскрипциях Docling (с использованием нового формата DocTags для лучшего отображения элементов и их местоположения).
- Читает документ за 0.35 секунды (на A100) при использовании 0.5 GB VRAM.
- Доступна в Hugging Face transformers и vLLM.
Модельку качать тут, пробовать тут.
Кто-нибудь уже пробовал на своих задачах?
Ваш, @llm_under_hood 🤗
PS: Whitepaper: https://arxiv.org/html/2503.11576v1
Forwarded from LLM под капотом
Все архитектуры Enterprise RAG Challenge
Вот вам обновленный и интерактивный leaderboard по результатам второго раунда Enterprise RAG Challenge: https://abdullin.com/erc/. Можно кликать на команды и читать про детали их решений на основе заполненных опросников. Если у команды было несколько экспериментов, то в карточке они тоже будут упомянуты.
В итоге у нашего коммьюнити получилось мощное исследование разных RAG архитектур на практической бизнес-задаче!
Причем, leaderboard с деталями решений - это далеко не последний результат. Я попозже дополню эту таблицу ссылками на посты и исходники, которые мне присылают.
А еще мы потихоньку начинаем планировать третий round. Его в итоге обсуждений решили сделать более организованным, чтобы выхлоп от R&D был интереснее и полезнее для всех в нашем комьюнити.
Идея простая - учимся на своих ошибках и двигаемся дальше.
В первом раунде мы обнаружили, что решения на базе SO / CoT легко занимают первое место. Вывод - сделаем генератор вопросов менее предсказуемым, чтобы SO/CoT жизнь маслом не казалась.
Второй раунд - многие использовали SO/CoT без векторов, но в итоге победило решение Ильи. Он заранее собрал инфраструктуру для оценки своего пайплайна и перебрал варианты его настройки на основе тестового набора данных.
Вывод - заранее соберем нормальную инфраструктуру для оценки пайплайнов и опубликуем ее вместе с тестовыми данными для всех желающих. Чтобы каждый мог быстро ставить разные эксперименты и оценивать их результаты.
И посмотрим, что получится в третьем раунде. Ведь интересно же, правда?)
Ваш, @llm_under_hood 🤗
Вот вам обновленный и интерактивный leaderboard по результатам второго раунда Enterprise RAG Challenge: https://abdullin.com/erc/. Можно кликать на команды и читать про детали их решений на основе заполненных опросников. Если у команды было несколько экспериментов, то в карточке они тоже будут упомянуты.
В итоге у нашего коммьюнити получилось мощное исследование разных RAG архитектур на практической бизнес-задаче!
Причем, leaderboard с деталями решений - это далеко не последний результат. Я попозже дополню эту таблицу ссылками на посты и исходники, которые мне присылают.
А еще мы потихоньку начинаем планировать третий round. Его в итоге обсуждений решили сделать более организованным, чтобы выхлоп от R&D был интереснее и полезнее для всех в нашем комьюнити.
Идея простая - учимся на своих ошибках и двигаемся дальше.
В первом раунде мы обнаружили, что решения на базе SO / CoT легко занимают первое место. Вывод - сделаем генератор вопросов менее предсказуемым, чтобы SO/CoT жизнь маслом не казалась.
Второй раунд - многие использовали SO/CoT без векторов, но в итоге победило решение Ильи. Он заранее собрал инфраструктуру для оценки своего пайплайна и перебрал варианты его настройки на основе тестового набора данных.
Вывод - заранее соберем нормальную инфраструктуру для оценки пайплайнов и опубликуем ее вместе с тестовыми данными для всех желающих. Чтобы каждый мог быстро ставить разные эксперименты и оценивать их результаты.
И посмотрим, что получится в третьем раунде. Ведь интересно же, правда?)
Ваш, @llm_under_hood 🤗
Forwarded from Artem Ryblov’s Data Science Weekly
Machine Learning from Scratch by Danny Friedman
This book is for readers looking to learn new machine learning algorithms or understand algorithms at a deeper level. Specifically, it is intended for readers interested in seeing machine learning algorithms derived from start to finish. Seeing these derivations might help a reader previously unfamiliar with common algorithms understand how they work intuitively. Or, seeing these derivations might help a reader experienced in modeling understand how different algorithms create the models they do and the advantages and disadvantages of each one.
This book will be most helpful for those with practice in basic modeling. It does not review best practices—such as feature engineering or balancing response variables—or discuss in depth when certain models are more appropriate than others. Instead, it focuses on the elements of those models.
Link: Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning
@data_science_weekly
This book is for readers looking to learn new machine learning algorithms or understand algorithms at a deeper level. Specifically, it is intended for readers interested in seeing machine learning algorithms derived from start to finish. Seeing these derivations might help a reader previously unfamiliar with common algorithms understand how they work intuitively. Or, seeing these derivations might help a reader experienced in modeling understand how different algorithms create the models they do and the advantages and disadvantages of each one.
This book will be most helpful for those with practice in basic modeling. It does not review best practices—such as feature engineering or balancing response variables—or discuss in depth when certain models are more appropriate than others. Instead, it focuses on the elements of those models.
Link: Book
Navigational hashtags: #armbooks
General hashtags: #ml #machinelearning
@data_science_weekly