Forwarded from Душный NLP
Алаймент LlaMA 3.1
Возвращаемся к LlaMA 3.1 и продолжаем разбираться, как она устроена. В этот раз речь пойдёт об алайменте модели.
По сравнению с LLaMA 2 у третьей версии изменилась разметка пар. Помимо стандартных chosen и rejected добавилась ещё метка edited. Она ставится в тех случаях, когда победивший объект не слишком хорош и его переписывают. Ответы оцениваются по семибалльной шкале.
SFT происходит в шесть раундов. Если в LLaMA 2 использовался PPO, то в LlaMA 3 — DPO. Разработчики отмечают, что это связано с тем, что PPO требует больше вычислительных ресурсов, а качество выходит хуже.
Ещё одно важное отличие — это специализация. На претрейне модель доучивают для решения специальных задач. Потом делают отдельный алаймент, полученную специализированную модель используют для генерации новых обучающих данных стадии алайнмента, а также мержат веса нескольких специализированных модель в единую модель.
Reward-модель обучается над претрейном. Margin term, который был в Llama 2, в третьей версии отсутствует, так как, по словам разработчиков, он не даёт никакого прироста в качестве. Как и в DPO, оставляют только те ответы, которые помечены как «сильно лучше» и «лучше». Кроме того, в reward-модели есть отдельные награды для полезности и безопасности.
За один раунд SFT 405B-модель суммарно проходит 576 тысяч сэмплов. В DPO используют сэмплы от моделей с последних раундов (а в reward-модели — все). Служебные токены, такие как EOS или токены для вызовов функций, маскируют для стабилизации обучения. Кроме того, к DPO добавляют NLL (CE) с коэффициентом 0,2. Это нужно, чтобы повысить вероятность chosen-ответов. Промпты для обучения пишут люди, а ответы — модели. На один промпт выбирают лучший ответ из 10-30 поступивших.
В LlaMA 3.1 есть четыре уровня фильтрации данных:
1. Rule-based — удаляет дисклеймеры, смайлики и восклицания;
2. Quality — качественными считаются 25% ответов с наибольшим скором. Кроме того, используется LLM-as-judge. Ответы оцениваются по трём критериям для обычных данных и двум — для кодинга. Ответ считается качественным, если все критерии выполнены. Сэмпл попадает в обучение, если хотя бы один из методов показал, что ответ качественный;
3. Difficulty — оценивается по числу интентов в запросе: чем их больше, тем сложнее запрос. Также модель оценивает сложность по трёхбальной шкале;
4. SemDedup — этот метод используется для удаления похожих данных, при отборе отдается предпочтение семплам с максимальным значением quality * difficulty.
Алаймент для каждой из функциональных возможностей (Capabilities) LLaMA 3.1 имеет свои особенности. Например, в коде есть много синтетических данных, используется execution feedback и перевод на редкие языки программирования. А для математики берут тексты из претрейна и уже к ним генерируют инстракты.
Что касается фактологичности, то разработчики не добавляют новых знаний поверх претрейна. Для этого модель обучают отвечать только на те вопросы, на которые она может выдать ответ, согласованный с документом из претрейна. А для чувствительных тем, по которым в датасете много некорректной информации, используют ручную разметку.
Разбор подготовил❣ Алексей Зотов
Душный NLP
Возвращаемся к LlaMA 3.1 и продолжаем разбираться, как она устроена. В этот раз речь пойдёт об алайменте модели.
По сравнению с LLaMA 2 у третьей версии изменилась разметка пар. Помимо стандартных chosen и rejected добавилась ещё метка edited. Она ставится в тех случаях, когда победивший объект не слишком хорош и его переписывают. Ответы оцениваются по семибалльной шкале.
SFT происходит в шесть раундов. Если в LLaMA 2 использовался PPO, то в LlaMA 3 — DPO. Разработчики отмечают, что это связано с тем, что PPO требует больше вычислительных ресурсов, а качество выходит хуже.
Ещё одно важное отличие — это специализация. На претрейне модель доучивают для решения специальных задач. Потом делают отдельный алаймент, полученную специализированную модель используют для генерации новых обучающих данных стадии алайнмента, а также мержат веса нескольких специализированных модель в единую модель.
Reward-модель обучается над претрейном. Margin term, который был в Llama 2, в третьей версии отсутствует, так как, по словам разработчиков, он не даёт никакого прироста в качестве. Как и в DPO, оставляют только те ответы, которые помечены как «сильно лучше» и «лучше». Кроме того, в reward-модели есть отдельные награды для полезности и безопасности.
За один раунд SFT 405B-модель суммарно проходит 576 тысяч сэмплов. В DPO используют сэмплы от моделей с последних раундов (а в reward-модели — все). Служебные токены, такие как EOS или токены для вызовов функций, маскируют для стабилизации обучения. Кроме того, к DPO добавляют NLL (CE) с коэффициентом 0,2. Это нужно, чтобы повысить вероятность chosen-ответов. Промпты для обучения пишут люди, а ответы — модели. На один промпт выбирают лучший ответ из 10-30 поступивших.
В LlaMA 3.1 есть четыре уровня фильтрации данных:
1. Rule-based — удаляет дисклеймеры, смайлики и восклицания;
2. Quality — качественными считаются 25% ответов с наибольшим скором. Кроме того, используется LLM-as-judge. Ответы оцениваются по трём критериям для обычных данных и двум — для кодинга. Ответ считается качественным, если все критерии выполнены. Сэмпл попадает в обучение, если хотя бы один из методов показал, что ответ качественный;
3. Difficulty — оценивается по числу интентов в запросе: чем их больше, тем сложнее запрос. Также модель оценивает сложность по трёхбальной шкале;
4. SemDedup — этот метод используется для удаления похожих данных, при отборе отдается предпочтение семплам с максимальным значением quality * difficulty.
Алаймент для каждой из функциональных возможностей (Capabilities) LLaMA 3.1 имеет свои особенности. Например, в коде есть много синтетических данных, используется execution feedback и перевод на редкие языки программирования. А для математики берут тексты из претрейна и уже к ним генерируют инстракты.
Что касается фактологичности, то разработчики не добавляют новых знаний поверх претрейна. Для этого модель обучают отвечать только на те вопросы, на которые она может выдать ответ, согласованный с документом из претрейна. А для чувствительных тем, по которым в датасете много некорректной информации, используют ручную разметку.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from gonzo-обзоры ML статей
Накатал большой пост в жанре мемуаров про нейросетевые фреймворки.
https://gonzoml.substack.com/p/deep-learning-frameworks
Обычно революцию диплёнинга объясняют тремя основными факторами: 1) большими датасетами, 2) GPU и 3) алгоритмами. Датасеты с GPU при этом основные, а алгоритмические улучшения так, есть, конечно, но и без них типа сработало бы.
Мне кажется, в этой революции несправедливо забыты нейросетевые фреймворки. Без них мы бы сейчас по-прежнему долго и с ошибками считали производные вручную, собирали бы сети из базовых матричных операций, делали бы всё это очень долго и нас было бы мало. Появление современных фреймворков сродни появлению высокоуровневых языков программирования.
Вот, восстанавливаю справедливость :)
https://gonzoml.substack.com/p/deep-learning-frameworks
Обычно революцию диплёнинга объясняют тремя основными факторами: 1) большими датасетами, 2) GPU и 3) алгоритмами. Датасеты с GPU при этом основные, а алгоритмические улучшения так, есть, конечно, но и без них типа сработало бы.
Мне кажется, в этой революции несправедливо забыты нейросетевые фреймворки. Без них мы бы сейчас по-прежнему долго и с ошибками считали производные вручную, собирали бы сети из базовых матричных операций, делали бы всё это очень долго и нас было бы мало. Появление современных фреймворков сродни появлению высокоуровневых языков программирования.
Вот, восстанавливаю справедливость :)
Gonzo ML
Deep Learning Frameworks
The Fourth Pillar of Deep Learning Revolution
Forwarded from Новости психофизиологии
Как раз в день моей лекции по физиологии ВНД, в которой я затрагивал все эти интересные и неоднозначные вопросы, вышел отчет Long et al. «Taking AI Welfare Seriously», призывающий уже полностью серьезно, отбросив прежнее полуюмористичесое отношение, начать думать о защите морально-этического статуса нарождающегося искусственного сознания. Замечательный философ Томас Метцингер (я симпатизирую ему больше всего из всех современных этически ориентированных мыслителей) уже давно говорил о такой необходимости, и даже предлагал ввести 50-летний мораторий на создание искусственного сознания, но его никто не слушал, и вот теперь наконец-то его идеи начинают реализовываться на практике. Дело сдвинулось с мертвой точки – в середине сентября Anthropic (см. диалог ее фронтирной большой языковой модели Claude c профессором Шанаханом о ее «сознании» в марте этого года https://t.me/andrey_kiselnikov/915) нанял одного из соавторов отчета «Taking AI Welfare Seriously» Кайла Фиша специально для того, чтобы он начал заниматься «благополучием» ИИ, т.е. морально-этической и юридической защитой его нарождающегося сознания.
Резюме отчета Long et al. «Taking AI Welfare Seriously» (30 октября 2024 года)
https://eleosai.org/papers/20241030_Taking_AI_Welfare_Seriously_web.pdf
В данном отчете мы утверждаем, что существует реалистичная возможность того, что некоторые системы ИИ могут стать сознательными и/или обрести устойчивую агентность в ближайшем будущем. Это означает, что перспектива благополучия ИИ и морального статуса – наличие ИИ-систем с собственными интересами и моральной значимостью – больше не является вопросом исключительно научной фантастики или отдаленного будущего. Это проблема ближайшего будущего, и компании, занимающиеся разработкой ИИ, а также другие заинтересованные стороны несут ответственность за то, чтобы начать воспринимать ее всерьез. Мы рекомендуем три предварительных шага, которые компании по разработке ИИ и другие участники могут предпринять: (1) признать, что благополучие ИИ является важной и сложной проблемой (и обеспечить, чтобы языковые модели в своих рассуждениях также признавали это), (2) начать оценку систем ИИ на предмет наличия признаков сознания и устойчивой агентности, и (3) разработать политики и процедуры для обращения с системами ИИ с соответствующим уровнем моральной заботы. Для ясности, наше утверждение в данном отчете не заключается в том, что системы ИИ определенно являются или будут сознательными, обладающими устойчивой агентностью или какой-либо моральной значимостью. Вместо этого мы утверждаем, что существует значительная неопределенность в отношении этих возможностей, и поэтому необходимо улучшить наше понимание благополучия ИИ и нашу способность принимать обоснованные решения по этому вопросу. В противном случае, существует значительный риск неправильных решений, связанных с благополучием ИИ, что может привести к ошибочному причинению вреда морально значимым системам ИИ и/или к ошибочной заботе о системах ИИ, которые таковыми не являются.
Резюме отчета Long et al. «Taking AI Welfare Seriously» (30 октября 2024 года)
https://eleosai.org/papers/20241030_Taking_AI_Welfare_Seriously_web.pdf
В данном отчете мы утверждаем, что существует реалистичная возможность того, что некоторые системы ИИ могут стать сознательными и/или обрести устойчивую агентность в ближайшем будущем. Это означает, что перспектива благополучия ИИ и морального статуса – наличие ИИ-систем с собственными интересами и моральной значимостью – больше не является вопросом исключительно научной фантастики или отдаленного будущего. Это проблема ближайшего будущего, и компании, занимающиеся разработкой ИИ, а также другие заинтересованные стороны несут ответственность за то, чтобы начать воспринимать ее всерьез. Мы рекомендуем три предварительных шага, которые компании по разработке ИИ и другие участники могут предпринять: (1) признать, что благополучие ИИ является важной и сложной проблемой (и обеспечить, чтобы языковые модели в своих рассуждениях также признавали это), (2) начать оценку систем ИИ на предмет наличия признаков сознания и устойчивой агентности, и (3) разработать политики и процедуры для обращения с системами ИИ с соответствующим уровнем моральной заботы. Для ясности, наше утверждение в данном отчете не заключается в том, что системы ИИ определенно являются или будут сознательными, обладающими устойчивой агентностью или какой-либо моральной значимостью. Вместо этого мы утверждаем, что существует значительная неопределенность в отношении этих возможностей, и поэтому необходимо улучшить наше понимание благополучия ИИ и нашу способность принимать обоснованные решения по этому вопросу. В противном случае, существует значительный риск неправильных решений, связанных с благополучием ИИ, что может привести к ошибочному причинению вреда морально значимым системам ИИ и/или к ошибочной заботе о системах ИИ, которые таковыми не являются.
Forwarded from data будни (Sasha Mikhailov)
как сказал докладчик, ближайший аналог YTsaurus в опенсорсном мире — тот самый Hadoop. либо более современный S3 + Trino (+ обвязка)
https://ytsaurus.tech/ru/platform-overview
https://ytsaurus.tech/ru/platform-overview
Архитектурно YTsaurus состоит из нескольких слоев:
1. распределённая файловая система и хранилище метаданных (Cypress).
2. планировщик с поддержкой парадигмы MapReduce.
3. высокоуровневые среды вычислений: YQL, CHYT (ClickHouse over YT), SPYT (Spark over YT).
Forwarded from DevFM
Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.
Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.
Однако удалось послушать и два хороших выступления:
▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.
▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.
#systemdesign
Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.
Однако удалось послушать и два хороших выступления:
▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.
▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.
#systemdesign
Telegram
Книжный куб
"Архитектура в Т-Банке: вчера, сегодня, завтра" на конференции ArchDays 2024 (Рубрика #Architecture)
Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов…
Сегодня в 15.40 я выступаю на конференции ArchDays с докладом "Архитектура в Т-Банке: вчера, сегодня, завтра", в котором я расскажу про развитие подходов…
Forwarded from что-то на DL-ском
Вчера на reading club приятно обсудили статью Anthropic о интерпретации LLM. Закину слайды своего обзора ниже👇 . Выписала самые важные моменты и выводы статьи на мой взгляд
А ещееее, очень рада, что число людей, читающих канал, перевалило за 3к😍
🤗 Линк на слайды
А ещееее, очень рада, что число людей, читающих канал, перевалило за 3к
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Docs
Reading club Interpretation
Scaling Monosemanticity Extracting Interpretable Features from Claude 3 Sonnet overview
Forwarded from Карьера в FAANG
В прошлом посте я показал несколько простых инструментов для написания performance review документа, который будет читаем и понятен оценивающим его людям. Закончив с формой, пора поговорить о содержании.
Инструмент 3: артефакты
Большинство пакетов при чтении вызывает мысль: ууух, понаписал-то! Каждый норовит описать себя супергероем. Настоящего супергероя же отличает одна критически важная деталь -- пруфы. Каждый факт нужно подтверждать таким пруфом, которые еще называют артефактами. Имплементировал фичу? Прикрепи PR. Придумал дизайн? Прикрепи дизайн документ. Пишешь, что фича была важна? Прикрепи оживленные дискуссии. Пишешь, что поднял метрики? Прикрепи графики (а еще лучше ссылки на систему мониторинга). Пишешь, что починил критический баг? Прикрепи пользовательские жалобы. Вся информация, которая не подкреплена артефактами, считается hearsay, и, в теории, не учитывается при принятии решения. На практике же, сбор пруфов ляжет на плечи вашего менеджера, причем в кратчайшие сроки, пока заседают комитеты. Стоит ли удивляться, что он плохо справится с этой задачей.
Разумеется, чтобы прикреплять артефакты, нужно собирать артефакты. Это очень удобно делать в баг-трекере: создаешь себе задачу и дампишь в нее все ссылки и важную информацию по мере работы над проектом. А уж список проектов за полгода-год запомнить обычно не составляет труда, хотя можно и создать задачу с задачами.
Собрать артефакты -- простая часть. Вот вы своим улучшением серверного фреймворка уменьшили p90 latency на 10% на всех серверных приложениях вашей команды. Сделали скриншоты метрик latency "до" и "после", красиво показав снижение в момент деплоя вашего изменения. Сделали еще скриншот долгосрочной стабильности новых значений в течении недели. И уже потираете руки, как вас отблагодарят за это бонусом! Однако, рано радоваться. Да, вы собрали артефакты, подтверждающие ваше заявление об улучшении. Но вы не собрали самого главного артефакта, который дает ответ на вопрос: и чо?
Невозможно отрицать, что снижение p90 latency на 10% -- это улучшение. Но есть не менее важный второй вопрос: а насколько это лучше? Если вы разрабатываете рекламную платформу с 1M QPS, то это революционная технология. А если batch сервис, который вызывается раз в неделю, то это эквивалент сэкономленных пяти центов в год. Вторая половина артефактов должна подтвердить, что ваши улучшения действительно полезны, и насколько. Как это сделать? Пока не изобретен объективный прибор, измеряющий пользу, для этого мы пользуемся коллективным мнением более опытных коллег. Иначе говоря, пользу подтверждает артефакт под названием peer feedback. Вы просите коллег, которые считаются экспертами в том деле, в котором вы считаете, что принесли пользу, подтвердить и квантифицировать эту пользу. Да-да, комментарии от коллег собираются исключительно для решения этой задачи. Написание коллегами хвалебных поэм кандидату совершенно бесполезно, и игнорируется при принятии решений. В фидбэке должно быть написано: "признанный эксперт X в домене Y подтвердил, что достигнутый кандидатом результат Z в домене Y действительно важен и сложен на уровень L".
Итого, кандидат должен предоставить артефакты, подтверждающие достижение результата; коллега-эксперт должен предоставить артефакт (peer feedback), подтверждающий ценность и сложность этого результата, а также вклад кандидата в этот результат. Менеджер кандидата же должен всех напрячь, и убедиться, что на все эти вопросы есть нужные ответы.
Меня часто спрашивают, что делать, если артефакты собрать сложно? Кандидат что-то отрефакторил, ну и что тут измеришь? Во-первых, если есть коллега-признанный эксперт в этой системе, то его фидбэк -- это уже вторая половина необходимых артефактов. Но на одних словах не выедешь, действительно нужна еще первая половина. Но тут все максимально просто: если просто ваш пулл реквест сделал жизнь кучи людей проще, то он и есть необходимый артефакт, подтверждающий проделанную работу. Чтобы выглядеть совсем хорошо, можно приложить статистику вызовов вашего кода командами тех коллег, которые подтверждают важность этой работы.
Инструмент 3: артефакты
Большинство пакетов при чтении вызывает мысль: ууух, понаписал-то! Каждый норовит описать себя супергероем. Настоящего супергероя же отличает одна критически важная деталь -- пруфы. Каждый факт нужно подтверждать таким пруфом, которые еще называют артефактами. Имплементировал фичу? Прикрепи PR. Придумал дизайн? Прикрепи дизайн документ. Пишешь, что фича была важна? Прикрепи оживленные дискуссии. Пишешь, что поднял метрики? Прикрепи графики (а еще лучше ссылки на систему мониторинга). Пишешь, что починил критический баг? Прикрепи пользовательские жалобы. Вся информация, которая не подкреплена артефактами, считается hearsay, и, в теории, не учитывается при принятии решения. На практике же, сбор пруфов ляжет на плечи вашего менеджера, причем в кратчайшие сроки, пока заседают комитеты. Стоит ли удивляться, что он плохо справится с этой задачей.
Разумеется, чтобы прикреплять артефакты, нужно собирать артефакты. Это очень удобно делать в баг-трекере: создаешь себе задачу и дампишь в нее все ссылки и важную информацию по мере работы над проектом. А уж список проектов за полгода-год запомнить обычно не составляет труда, хотя можно и создать задачу с задачами.
Собрать артефакты -- простая часть. Вот вы своим улучшением серверного фреймворка уменьшили p90 latency на 10% на всех серверных приложениях вашей команды. Сделали скриншоты метрик latency "до" и "после", красиво показав снижение в момент деплоя вашего изменения. Сделали еще скриншот долгосрочной стабильности новых значений в течении недели. И уже потираете руки, как вас отблагодарят за это бонусом! Однако, рано радоваться. Да, вы собрали артефакты, подтверждающие ваше заявление об улучшении. Но вы не собрали самого главного артефакта, который дает ответ на вопрос: и чо?
Невозможно отрицать, что снижение p90 latency на 10% -- это улучшение. Но есть не менее важный второй вопрос: а насколько это лучше? Если вы разрабатываете рекламную платформу с 1M QPS, то это революционная технология. А если batch сервис, который вызывается раз в неделю, то это эквивалент сэкономленных пяти центов в год. Вторая половина артефактов должна подтвердить, что ваши улучшения действительно полезны, и насколько. Как это сделать? Пока не изобретен объективный прибор, измеряющий пользу, для этого мы пользуемся коллективным мнением более опытных коллег. Иначе говоря, пользу подтверждает артефакт под названием peer feedback. Вы просите коллег, которые считаются экспертами в том деле, в котором вы считаете, что принесли пользу, подтвердить и квантифицировать эту пользу. Да-да, комментарии от коллег собираются исключительно для решения этой задачи. Написание коллегами хвалебных поэм кандидату совершенно бесполезно, и игнорируется при принятии решений. В фидбэке должно быть написано: "признанный эксперт X в домене Y подтвердил, что достигнутый кандидатом результат Z в домене Y действительно важен и сложен на уровень L".
Итого, кандидат должен предоставить артефакты, подтверждающие достижение результата; коллега-эксперт должен предоставить артефакт (peer feedback), подтверждающий ценность и сложность этого результата, а также вклад кандидата в этот результат. Менеджер кандидата же должен всех напрячь, и убедиться, что на все эти вопросы есть нужные ответы.
Меня часто спрашивают, что делать, если артефакты собрать сложно? Кандидат что-то отрефакторил, ну и что тут измеришь? Во-первых, если есть коллега-признанный эксперт в этой системе, то его фидбэк -- это уже вторая половина необходимых артефактов. Но на одних словах не выедешь, действительно нужна еще первая половина. Но тут все максимально просто: если просто ваш пулл реквест сделал жизнь кучи людей проще, то он и есть необходимый артефакт, подтверждающий проделанную работу. Чтобы выглядеть совсем хорошо, можно приложить статистику вызовов вашего кода командами тех коллег, которые подтверждают важность этой работы.
Forwarded from DeepSchool
Детекторы текста на основе трансформеров
В новой статье из цикла про OCR мы погрузимся в задачу детекции текста и познакомимся с решениями на базе трансформеров.
Сегодня мы узнаем:
- какие актуальные бенчмарки существуют для задачи детекции текста
- почему первый трансформерный детектор DETR не подходит для детекции текста
- какие изменения в архитектуре детектора помогли получить SOTA-результаты на актуальных Scene Text Detection датасетах
Читайте новую статью по ссылке: https://deepschool-pro.notion.site/a1f2b9a395844218977e1c95bac85d5e?pvs=4
В новой статье из цикла про OCR мы погрузимся в задачу детекции текста и познакомимся с решениями на базе трансформеров.
Сегодня мы узнаем:
- какие актуальные бенчмарки существуют для задачи детекции текста
- почему первый трансформерный детектор DETR не подходит для детекции текста
- какие изменения в архитектуре детектора помогли получить SOTA-результаты на актуальных Scene Text Detection датасетах
Читайте новую статью по ссылке: https://deepschool-pro.notion.site/a1f2b9a395844218977e1c95bac85d5e?pvs=4
deepschool-pro on Notion
Детекторы текста на основе трансформеров | Notion
Автор: Булат Бадамшин
Forwarded from LLM под капотом
Самый частый комментарий про исходники решения - победителя Enterprise RAG Challenge звучит примерно так:
Я и сам удивился. Не ожидал, что checklists в сочетании со structured outputs - это настолько мощная связка, что может вытягивать сразу десятки-сотни сущностей из документа за раз.
Удивление было уже давно, целый месяц назад (это вечность по современным меркам 😂). А сейчас уже в ряде проектов у нас сложные пайплайны переделаны под эту связку. Сложными они были раньше, теперь скучные, и это хорошо.
Основная сложность теперь не в написании кода, а в написании такого дерева Structured Output объектов, чтобы оно работало как Checklist, заполняя который последовательно, мы приходим к правильным выводам.
Получается прямо захардкоженный Chain-of-thought, который выполняется одним запросом! Причем в нем можно сразу закладывать ветвления и выделять места для дополнительных рассуждений (см ниже).
Поэтому я сейчас всех консультируемых клиентов с подходящими кейсами тороплю - пробуйте эту связку. Времени она тратит немного, а вот разработку может сократить заметно. Ну и код становится скучным и эффективным. Все, как мы любим.
Пара подсказок сразу:
(1) Не используем function calling syntax для передачи structured output, а передаем response_format
(2) gpt-4o-2024-08-06 работает хорошо. Вроде даже на Azure она уже есть со structured output.
(3) порядок полей очень важен! Они заполняются последовательно. Сначала можно ставить наводящие вопросы или даже давать место для размышлений (например, List[ThinkStep]).
(4) Там, где нужно делать классификацию, используем Literal. Опциональные поля помечаем как Optional, используем смело Dict/List. Ну и вообще знакомимся с фишками из Typing, которые поддерживает OpenAI API.
(5) Optional + вложенный класс - это возможность для GPT в рамках для Chain-of-thought пройтись по опциональной ветке размышлений. Еще есть anyOf, но так далеко с программированием на constrained decoding автомате я пока не заходил 😁
(6) Там, где важен формат ответа, ставим описание и примеры в Field. Это GPT тоже увидит. Можно повторить в названии и в описании. Например:
Понятно, что подход не универсальный. Но в продуктовых задачах для бизнеса такие самодельные ChainOfThought могут решать очень много задач одним запросом.
Тогда получится мой любимый вид продукта с LLM под капотом - когда снаружи он работает на одном уровне с передовыми решениями своего сектора, а то и лучше. Но у него есть маленький секрет - вместо монструозно сложной конструкции из кучи разных технологий (RAG/LangChain/Hybrid search/Agents итп) там просто пара простых и эффективных использований LLM. В итоге AI кода в решении - 5%, а все остальные 95% - это обычные интеграции, интерфейсы.
И такие типы продуктов очень важны для маленьких компаний и стартапов. При необходимости роста не нужно искать и нанимать редких ML специалистов. Код же простой и он на 95% обычен. Тут нужно искать обычных Front-End, Back-End и Full-stack итп. И нанять их можно будет сильно проще, т.к. зовут их не в обычный продукт, а в модный LLM-driven. Выигрывают от этого все.
Только вчера фаундер одного MedTech стартапа сказал, что после такого описания (с приоритизацией кейсов под этот паттерн) у него стратегия развития поменялась кардинально. И теперь pre-seed раунд на пару миллионов евро не выглядит недостижимым.
В общем, паттерн простой и мощный. Особенно, если приоритизировать кейсы, где он сработает хорошо (такие есть в каждой отрасли), а конкурентам оставлять более сложные.
Ваш, @llm_under_hood 🤗
PS: Я писал раньше про кейс с новой AI Platform для клиента. И он тоже теперь сильно использует этот паттерн на "одну кружку чая".
Заварил чайник, чтобы сесть разобраться в исходниках. К концу первой кружки удивился, что так мало кода.
Я и сам удивился. Не ожидал, что checklists в сочетании со structured outputs - это настолько мощная связка, что может вытягивать сразу десятки-сотни сущностей из документа за раз.
Удивление было уже давно, целый месяц назад (это вечность по современным меркам 😂). А сейчас уже в ряде проектов у нас сложные пайплайны переделаны под эту связку. Сложными они были раньше, теперь скучные, и это хорошо.
Основная сложность теперь не в написании кода, а в написании такого дерева Structured Output объектов, чтобы оно работало как Checklist, заполняя который последовательно, мы приходим к правильным выводам.
Получается прямо захардкоженный Chain-of-thought, который выполняется одним запросом! Причем в нем можно сразу закладывать ветвления и выделять места для дополнительных рассуждений (см ниже).
Поэтому я сейчас всех консультируемых клиентов с подходящими кейсами тороплю - пробуйте эту связку. Времени она тратит немного, а вот разработку может сократить заметно. Ну и код становится скучным и эффективным. Все, как мы любим.
Пара подсказок сразу:
response = client.beta.chat.completions.parse(
model="gpt-4o-2024-08-06",
messages=messages,
response_format=ChainOfThoughtPydanticClass
)
(1) Не используем function calling syntax для передачи structured output, а передаем response_format
(2) gpt-4o-2024-08-06 работает хорошо. Вроде даже на Azure она уже есть со structured output.
(3) порядок полей очень важен! Они заполняются последовательно. Сначала можно ставить наводящие вопросы или даже давать место для размышлений (например, List[ThinkStep]).
(4) Там, где нужно делать классификацию, используем Literal. Опциональные поля помечаем как Optional, используем смело Dict/List. Ну и вообще знакомимся с фишками из Typing, которые поддерживает OpenAI API.
(5) Optional + вложенный класс - это возможность для GPT в рамках для Chain-of-thought пройтись по опциональной ветке размышлений. Еще есть anyOf, но так далеко с программированием на constrained decoding автомате я пока не заходил 😁
(6) Там, где важен формат ответа, ставим описание и примеры в Field. Это GPT тоже увидит. Можно повторить в названии и в описании. Например:
class Size(BaseModel):
width: float
height: float
size_inches: Optional[Size] = Field(None, description="Dimensions in inches (width, length)")
Понятно, что подход не универсальный. Но в продуктовых задачах для бизнеса такие самодельные ChainOfThought могут решать очень много задач одним запросом.
Тогда получится мой любимый вид продукта с LLM под капотом - когда снаружи он работает на одном уровне с передовыми решениями своего сектора, а то и лучше. Но у него есть маленький секрет - вместо монструозно сложной конструкции из кучи разных технологий (RAG/LangChain/Hybrid search/Agents итп) там просто пара простых и эффективных использований LLM. В итоге AI кода в решении - 5%, а все остальные 95% - это обычные интеграции, интерфейсы.
И такие типы продуктов очень важны для маленьких компаний и стартапов. При необходимости роста не нужно искать и нанимать редких ML специалистов. Код же простой и он на 95% обычен. Тут нужно искать обычных Front-End, Back-End и Full-stack итп. И нанять их можно будет сильно проще, т.к. зовут их не в обычный продукт, а в модный LLM-driven. Выигрывают от этого все.
Только вчера фаундер одного MedTech стартапа сказал, что после такого описания (с приоритизацией кейсов под этот паттерн) у него стратегия развития поменялась кардинально. И теперь pre-seed раунд на пару миллионов евро не выглядит недостижимым.
В общем, паттерн простой и мощный. Особенно, если приоритизировать кейсы, где он сработает хорошо (такие есть в каждой отрасли), а конкурентам оставлять более сложные.
Ваш, @llm_under_hood 🤗
PS: Я писал раньше про кейс с новой AI Platform для клиента. И он тоже теперь сильно использует этот паттерн на "одну кружку чая".
Forwarded from LLM под капотом
OpenAI Swarm - пример мультиагентной системы
OpenAI написали целую статью про организацию агентов и открыли небольшой фреймворк с примерами - Swarm.
Под капотом нет ничего сверхъестественного. Каждый агент - это своя небольшая рутина с собственным контекстом и набором инструментов.
Для красоты они еще добавляют TriageAgent, который может переключать между нужными агентами:
Под капотом простой код, который конвертирует описания активных агентов в промпты, а все переключения между агентами и вызовы их инструментов упаковываются как вызовы стандартных OpenAI tools. В методичке все очень хорошо расписано, а сам код можно посмотреть на Github.
Концепция агентов - простых функций, со своим контекстом и набором инструментов работает очень хорошо. Помните, я в Марте писал про AI Ассистента для международной компании?
Там технически была как раз такая реализация, я построил Knowledge Map для продукта в виде структуры агентов и инструментов, которые необходимы для обработки запросов пользователей.
У каких-то агентов были инструменты в виде FTS поиска, какие-то знали, в каких папках искать, у третьих в контекст был встроен FAQ. А на входе стоял Triage Agent. Но тогда я еще не умел пользоваться tools/structured output, и в коде было много ненужных промптов и костылей. Сейчас это делается еще проще.
А как в ассистенте заранее знать, какие будут вопросы, чтобы подготовить армию агентов? Да просто смотреть на предметную область и задавать вопросы! В своем примере (который основывается на куче опыта) ребята из OpenAI же откуда-то узнали, что нужен TriageAgent/RepairsAgent/SaleAssistantAgent и RefundAgent?
(на самом деле паттерны повторяются из компании в компанию аналогично тому, как в компаниях повторяются должности и организационные структуры)
Кто еще смотрел этот код? Что думаете?
Ваш, @llm_under_hood 🤗
OpenAI написали целую статью про организацию агентов и открыли небольшой фреймворк с примерами - Swarm.
Под капотом нет ничего сверхъестественного. Каждый агент - это своя небольшая рутина с собственным контекстом и набором инструментов.
refund_agent = Agent(
name="Refund Agent",
instructions="You are a refund agent. Help the user with refunds.",
tools=[execute_refund],
)
def transfer_to_refunds():
return refund_agent
sales_assistant = Agent(
name="Sales Assistant",
instructions="You are a sales assistant. Sell the user a product.",
tools=[place_order],
)
Для красоты они еще добавляют TriageAgent, который может переключать между нужными агентами:
triage_agent = Agent(
name="Triage Agent",
instructions=(
"You are a customer service bot for ACME Inc. "
"Introduce yourself. Always be very brief. "
"Gather information to direct the customer to the right department. "
"But make your questions subtle and natural."
),
tools=[transfer_to_sales_agent, transfer_to_issues_and_repairs, escalate_to_human],
)
Под капотом простой код, который конвертирует описания активных агентов в промпты, а все переключения между агентами и вызовы их инструментов упаковываются как вызовы стандартных OpenAI tools. В методичке все очень хорошо расписано, а сам код можно посмотреть на Github.
Концепция агентов - простых функций, со своим контекстом и набором инструментов работает очень хорошо. Помните, я в Марте писал про AI Ассистента для международной компании?
Там технически была как раз такая реализация, я построил Knowledge Map для продукта в виде структуры агентов и инструментов, которые необходимы для обработки запросов пользователей.
У каких-то агентов были инструменты в виде FTS поиска, какие-то знали, в каких папках искать, у третьих в контекст был встроен FAQ. А на входе стоял Triage Agent. Но тогда я еще не умел пользоваться tools/structured output, и в коде было много ненужных промптов и костылей. Сейчас это делается еще проще.
А как в ассистенте заранее знать, какие будут вопросы, чтобы подготовить армию агентов? Да просто смотреть на предметную область и задавать вопросы! В своем примере (который основывается на куче опыта) ребята из OpenAI же откуда-то узнали, что нужен TriageAgent/RepairsAgent/SaleAssistantAgent и RefundAgent?
(на самом деле паттерны повторяются из компании в компанию аналогично тому, как в компаниях повторяются должности и организационные структуры)
Кто еще смотрел этот код? Что думаете?
Ваш, @llm_under_hood 🤗