Пишу, помогаю, обучаю, внедряю, консультирую по AI Coding
О канале https://t.me/the_ai_architect/2
Связь: @yatimur | Визитка: timurkhakhalev.t.me
О канале https://t.me/the_ai_architect/2
Связь: @yatimur | Визитка: timurkhakhalev.t.me
anthropic.claude-3-7-sonnet-20250219-v1:0
Claude 3.7 Sonnet is Anthropic's most intelligent model to date and the first Claude model to offer extended thinking - the ability to solve complex problems with careful, step-by-step reasoning.
Anthropic is the first AI lab to introduce a single model where users can balance speed and quality by choosing between standard thinking for near-instant responses or extended thinking or advanced reasoning.
Claude 3.7 Sonnet is state-of-the-art for coding, and delivers advancements in computer use, agentic capabilities, complex reasoning, and content generation. With frontier performance and more control over speed, Claude 3.7 Sonnet is the ideal choice for powering AI agents, especially customer-facing agents, and complex AI workflows.
Supported use cases: RAG or search & retrieval over vast amounts of knowledge, product recommendations, forecasting, targeted marketing, code generation, quality control, parse text from images, agentic computer use, content generation
Model attributes: Reasoning, Text generation, Code generation, Rich text formatting, Agentic computer use
Ожидаем сегодня-завтра
В эти дни в Нью-Йорке проходит конференция AI Engineer, посвященная Agent Engineering.
Записи на YouTube:
Day 1
Day 2
Я посмотрел выступления OpenAI и Anthropic — в целом, ничего сверхъестественного не услышал, только подтверждение того что слышал ранее или о чем я писал на своем канале.
Anthropic, например, в своей презентации использовали свою классную статью, которую я переводил ранее, из примечательного — это идея "Подумай от лица агента, какой контекст у тебя есть, какие инструменты есть, и как бы ты выполнил задачу" — очень неплохо подсказывает понять, где в вашей системе может быть ошибка или недостаток контекста для агента (или обычного workflow)
Записи на YouTube:
Day 1
Day 2
Я посмотрел выступления OpenAI и Anthropic — в целом, ничего сверхъестественного не услышал, только подтверждение того что слышал ранее или о чем я писал на своем канале.
Anthropic, например, в своей презентации использовали свою классную статью, которую я переводил ранее, из примечательного — это идея "Подумай от лица агента, какой контекст у тебя есть, какие инструменты есть, и как бы ты выполнил задачу" — очень неплохо подсказывает понять, где в вашей системе может быть ошибка или недостаток контекста для агента (или обычного workflow)
https://www.perplexity.ai/page/anthropic-develops-hybrid-mode-mBWGhYyMQVCmBgkGE80r1g
В прошлом посте я посетовал на то, что у нас нет никаких слухов о новом Claude 4 или каких-либо других новых продуктах Anthropic, и вот, они появились.
Источники говорят, что у новой модели Anthropic наконец-то появится reasoning, а так же, можно будет управлять "силой рассуждения" (reasoning effort) — можно будет указывать, какое количество времени модель будет думать над вопросом. Так уже реализовано у OpenAI o1-like моделей.
Ну и ещё, говорят о том, что в coding tasks эта модель будет обгонять o3-mini-high.
Новости меня очень порадовали, но у Anthropic есть несколько "но".
◾️ Во-первых, у них в последние месяцы появился дефицит вычислительных ресурсов. Это заметно особенно в то время, когда в США наступает утро, а у Claude отваливаются запросы на генерацию. Надеюсь, у Dario есть какие-то идеи решения этой проблемы.
◾️ Во-вторых, цена. На данный момент, модели Anthropic являются одними из самых дорогих на рынке (по API). Надеюсь, что новые модели не будут дороже моделей OpenAI.
◾️ Ну и в-третьих, хоть и не сильно критично, но Anthropic всё ещё не завезли structured output — новый стандарт индустрии. Надеюсь, в новых моделях он появится.
И кстати говоря, в этом же таймлайне OpenAI должны выпустить новую модель GPT 5.
В этой битве я топлю за Anthropic. Не знаю почему, но их модели мне нравятся больше, хоть и смущает плотное сотрудничество с военкой США.
Так что, ближайшие несколько недель обещают быть очень насыщенными на релизы.
Хороший пример использования reasoning моделей https://t.me/llm_under_hood/493
В статье блога Answer AI, авторы делятся своим мнением об использовании Devin.
Devin – это такой AI teammate, который скоро нас всех заменит ©. Такой электрический программист стоит $500/month, общение с ним происходит через Slack. Вы тегаете его, описываете свою задачу, а он начинает её выполнять и отписывается о статусе в треде Slack. Примечательно, что сами создатели (Coginition AI) рекомендуют не перегружать Devin задачами дольше трёх часов.
Perplexity говорит, что Cognition AI была создана в ноябре 2023 года в Сан-Франциско тремя программистами-олимпиадниками © Scott Wu, Walden Yan, и Steven Hao на волне хайпа AI.
Так вот, авторы статьи описывают, что первой задачей была типичная таска для джуна – программно переносить данные из Notion database в Google Sheets и Devin с ней справился.
Далее, электро-дурачку дали задачи посложнее и тут уже появились проблемы.
Все задачи разделили на 3 части:
1. Создание новых проектов с нуля
2. Исследовательские задачи
3. Работа с изменением существующих проектов
И общая статистика получилась неутешительной: из 20 задач, 14 были неудачными, 3 были успешным и 3 закончились неполным ответов.
Авторы упоминают, что задачи, которые подразумевают создание нового проекта с нуля, Devin тоже зафейлил, хотя, казалось бы, это самое простое и для человека, и для существующих LLM.
Devin часто увязал в усложнениях кода, абстракциях и ненужных конструкциях. В некоторых случаях авторам проще было решить задачу с помощью Cursor, чем с Devin.
В заключении, авторы пишут, что Devin всё еще сырой для того, чтобы полноценно его использовать.
Для меня, Devin выглядит как продукт хайпа AI в 2024 – большие обещания и грандиозные планы, немыслимые $500/mo за использование, а на деле – сильно сырой продукт, на уровне MVP, который ещё пилить и пилить. Cursor на его фоне выглядит намного лучше.
Также, странно, что у Devin возникают такие проблемы с кодингом, хотя у нас есть LLM, который очень неплохо пишет код (Claude), неужели они не используют его для кода?
Правительство США начинает регулировать экспорт LLM
> The AI Diffusion Rule introduces a tiered country classification system to govern the export of advanced AI technologies. This system categorizes nations based on their strategic importance and alignment with U.S. interests
>include [...] A “know-your-customer” requirement to ensure exported technologies are not redirected to unauthorized entities
🤡 🤡 🤡
Короче, походу у нас есть 4 месяца на то чтобы собрать свои важные чаты и проекты из Claude и ChatGPT и быть готовым к тому что людям из РФ/Беларуси закроют доступ из-за "плохого" паспорта.
В целом, рано или поздно это должно было случиться, интересно как это отразится на развитии AI сферы.
https://www.perplexity.ai/page/new-us-ai-export-rules-YiRvOtrUQG.kWJBqQqAHVg
> The AI Diffusion Rule introduces a tiered country classification system to govern the export of advanced AI technologies. This system categorizes nations based on their strategic importance and alignment with U.S. interests
>include [...] A “know-your-customer” requirement to ensure exported technologies are not redirected to unauthorized entities
Короче, походу у нас есть 4 месяца на то чтобы собрать свои важные чаты и проекты из Claude и ChatGPT и быть готовым к тому что людям из РФ/Беларуси закроют доступ из-за "плохого" паспорта.
В целом, рано или поздно это должно было случиться, интересно как это отразится на развитии AI сферы.
https://www.perplexity.ai/page/new-us-ai-export-rules-YiRvOtrUQG.kWJBqQqAHVg
AI фишинг – результаты нового исследования из Гарварда 🎣
Главные результаты
Исследователи из Гарварда показали, что современные языковые модели (они использовали Claude 3.5 Sonnet и GPT-4o) могут создавать фишинговые письма такого же качества, как и опытные специалисты. Результаты впечатляют:
◾️ Контрольная группа (обычный фишинг): 12% успешности
◾️ Письма от экспертов: 54%
◾️ Полностью автоматизированные AI письма: 54%
◾️ AI + human-in-the-loop: 56%
Основные выводы
◾️ AI достиг паритета с человеком-экспертом в написании фишинговых писем. Это большой скачок по сравнению с 2023 годом, когда для такой эффективности требовалось человеческое участие.
◾️ Исследователи разработали AI инструмент, который может:
– Автоматически собирать информацию о жертвах
– Генерировать персонализированные фишинговые письма
– Отслеживать успешность
– Самообучаться на основе результатов
Технические детали
Интересный технический момент – исследователи отправляли письма батчами по 10 штук, чтобы не попадать в спам фильтры (больший объем похожих писем быстро отмечается как спам).
Экономика фишинга
Самое тревожное – экономика AI фишинга. При достаточном масштабе (около 5000 жертв), автоматизированный фишинг может быть в 50 раз прибыльнее традиционного. А учитывая, как быстро развиваются LLM, это становится серьезной угрозой безопасности 😐
Безопасность
◾️ Существующие ограничения AI легко обойти
◾️ Эффективность AI фишинга создает серьезные проблемы безопасности
◾️ Исследователи подчеркивают необходимость улучшения защитных мер и политик
Ключевые инсайты
1. Психология доверия:
◾️ 40% пользователей, кликнувших по AI-письмам, отметили, что персонализация повысила доверие
◾️ Аутентичность отправителя была главным индикатором подозрительности
2. Эволюция AI:
◾️ В 2023 году AI требовал помощи человека
◾️ Сейчас работает автономно на уровне экспертов
◾️ К 2025 году прогнозируется значительное превосходство над человеком
Интересные факты
◾️ Письма отправлялись между 10:30 и 14:00 для максимальной эффективности
◾️ Ручной сбор информации занимал около 23 минут на цель, AI справляется за минуты
◾️ Из 101 участника только 60 проявили активность после регистрации
◾️ Claude 3.5 Sonnet достиг практически идеального обнаружения на тестовом наборе из 20 писем
В исследовании также показано, что те же самые LLM отлично справляются с детектом фишинговых писем (Claude 3.5 Sonnet показал точность 97.25% без ложных срабатываний).
Главные результаты
Исследователи из Гарварда показали, что современные языковые модели (они использовали Claude 3.5 Sonnet и GPT-4o) могут создавать фишинговые письма такого же качества, как и опытные специалисты. Результаты впечатляют:
◾️ Контрольная группа (обычный фишинг): 12% успешности
◾️ Письма от экспертов: 54%
◾️ Полностью автоматизированные AI письма: 54%
◾️ AI + human-in-the-loop: 56%
Основные выводы
◾️ AI достиг паритета с человеком-экспертом в написании фишинговых писем. Это большой скачок по сравнению с 2023 годом, когда для такой эффективности требовалось человеческое участие.
◾️ Исследователи разработали AI инструмент, который может:
– Автоматически собирать информацию о жертвах
– Генерировать персонализированные фишинговые письма
– Отслеживать успешность
– Самообучаться на основе результатов
Технические детали
Интересный технический момент – исследователи отправляли письма батчами по 10 штук, чтобы не попадать в спам фильтры (больший объем похожих писем быстро отмечается как спам).
Экономика фишинга
Самое тревожное – экономика AI фишинга. При достаточном масштабе (около 5000 жертв), автоматизированный фишинг может быть в 50 раз прибыльнее традиционного. А учитывая, как быстро развиваются LLM, это становится серьезной угрозой безопасности 😐
Безопасность
◾️ Существующие ограничения AI легко обойти
◾️ Эффективность AI фишинга создает серьезные проблемы безопасности
◾️ Исследователи подчеркивают необходимость улучшения защитных мер и политик
Ключевые инсайты
1. Психология доверия:
◾️ 40% пользователей, кликнувших по AI-письмам, отметили, что персонализация повысила доверие
◾️ Аутентичность отправителя была главным индикатором подозрительности
2. Эволюция AI:
◾️ В 2023 году AI требовал помощи человека
◾️ Сейчас работает автономно на уровне экспертов
◾️ К 2025 году прогнозируется значительное превосходство над человеком
Интересные факты
◾️ Письма отправлялись между 10:30 и 14:00 для максимальной эффективности
◾️ Ручной сбор информации занимал около 23 минут на цель, AI справляется за минуты
◾️ Из 101 участника только 60 проявили активность после регистрации
◾️ Claude 3.5 Sonnet достиг практически идеального обнаружения на тестовом наборе из 20 писем
В исследовании также показано, что те же самые LLM отлично справляются с детектом фишинговых писем (Claude 3.5 Sonnet показал точность 97.25% без ложных срабатываний).
Использование Claude для защиты китов 🐋
Anthropic выпустили новый шоу-кейс. Сиднейский университет вместе с Accenture используют Claude для анализа акустических данных китов.
Суть проекта в том, что под водой установлены микрофоны (гидрофоны), которые записывают звуки. Раньше эти записи анализировали вручную, что занимало около двух недель. Теперь же они создали систему на основе Claude, которая делает это в реальном времени.
Технические детали:
◾️ Система комбинирует два типа AI – CNN для первичной обработки и Claude для продвинутого анализа
◾️ Звуковые записи конвертируются в спектрограммы (визуальные паттерны звука)
◾️ Точность определения китов достигает 89.4% (для сравнения, старые методы давали только 76.5%)
◾️ Система может обнаруживать китов в радиусе 5 километров от гидрофона
Интересный момент: система анализирует тысячи километров североамериканского побережья и обрабатывает сотни тысяч акустических записей ежегодно. Представьте себе объём данных – это как прослушать все подкасты мира, только под водой 🎧
Что интересно с технической точки зрения:
Использовали transfer learning (дообучение на датасете), что позволило обучить модель на относительно небольшом датасете (что критично, т.к. размеченных данных по морским животным очень мало)
Claude используется именно для анализа визуальных данных (спектрограмм), а не самого звука
Система работает в реальном времени, что позволяет быстро реагировать на появление китов
Кстати, раньше китов отслеживали через физические метки и ловушки. По сути, этот проект – первый случай полностью неинвазивного мониторинга китов в таком масштабе.
Практическое применение:
◾️ Перенаправление морского трафика если киты поблизости
◾️ Приостановка буровых работ
◾️ Корректировка зон рыбной ловли
Небольшой факт: каждый год тысячи китов погибают от столкновений с кораблями. Эта система может реально помочь снизить эти цифры.
В будущем команда планирует расширить систему для распознавания других морских животных через multiclass classification.
👆 Интересно, но это один из немногих кейсов, где AI реально помогает сохранить жизни, а не просто оптимизирует какие-то бизнес-процессы.
Anthropic выпустили новый шоу-кейс. Сиднейский университет вместе с Accenture используют Claude для анализа акустических данных китов.
Суть проекта в том, что под водой установлены микрофоны (гидрофоны), которые записывают звуки. Раньше эти записи анализировали вручную, что занимало около двух недель. Теперь же они создали систему на основе Claude, которая делает это в реальном времени.
Технические детали:
◾️ Система комбинирует два типа AI – CNN для первичной обработки и Claude для продвинутого анализа
◾️ Звуковые записи конвертируются в спектрограммы (визуальные паттерны звука)
◾️ Точность определения китов достигает 89.4% (для сравнения, старые методы давали только 76.5%)
◾️ Система может обнаруживать китов в радиусе 5 километров от гидрофона
Интересный момент: система анализирует тысячи километров североамериканского побережья и обрабатывает сотни тысяч акустических записей ежегодно. Представьте себе объём данных – это как прослушать все подкасты мира, только под водой 🎧
Что интересно с технической точки зрения:
Использовали transfer learning (дообучение на датасете), что позволило обучить модель на относительно небольшом датасете (что критично, т.к. размеченных данных по морским животным очень мало)
Claude используется именно для анализа визуальных данных (спектрограмм), а не самого звука
Система работает в реальном времени, что позволяет быстро реагировать на появление китов
Кстати, раньше китов отслеживали через физические метки и ловушки. По сути, этот проект – первый случай полностью неинвазивного мониторинга китов в таком масштабе.
Практическое применение:
◾️ Перенаправление морского трафика если киты поблизости
◾️ Приостановка буровых работ
◾️ Корректировка зон рыбной ловли
Небольшой факт: каждый год тысячи китов погибают от столкновений с кораблями. Эта система может реально помочь снизить эти цифры.
В будущем команда планирует расширить систему для распознавания других морских животных через multiclass classification.
Гибридные подходы к LC и RAG: разбираем детали 🔍
А зачем нужен LC, если мы уже нашли релевантные куски с помощью RAG? Давайте разберемся.
1. Проблема контекста при ретриве
RAG часто разбивает текст на чанки, что создает проблемы:
- Теряются связи между частями текста
- Контекст может быть разорван на границах чанков
- Общая картина может быть искажена
Пример: в начале текста написано "Компания X", а через несколько абзацев "Их выручка составила...". RAG может взять только второй кусок, и LLM не будет понимать о какой компании речь.
2. Гибридные подходы
a) Последовательный подход:
- RAG для initial filtering большого корпуса
- LC получает найденные куски + окружающий контекст
- Плюс: сохраняем связность информации
b) Параллельный подход:
- Запускаем и RAG и LC одновременно
- Сравниваем/комбинируем результаты
- Плюс: используем сильные стороны обоих
3. Практические рекомендации:
✅ Используйте RAG для первичной фильтрации
✅ Давайте LC больше контекста вокруг найденных кусков
✅ Экспериментируйте с размером чанков
✅ Сохраняйте метаданные об источниках
В итоге, гибридный подход – это не просто "сложить два метода вместе". Это возможность построить систему, где RAG отвечает за поиск релевантной информации, а LC – за её глубокое понимание с учетом контекста.
Я часто вижу, что в приложениях используется в основном RAG, а кто-то использует LC? Расскажите в комментах 👇
А зачем нужен LC, если мы уже нашли релевантные куски с помощью RAG? Давайте разберемся.
1. Проблема контекста при ретриве
RAG часто разбивает текст на чанки, что создает проблемы:
- Теряются связи между частями текста
- Контекст может быть разорван на границах чанков
- Общая картина может быть искажена
Пример: в начале текста написано "Компания X", а через несколько абзацев "Их выручка составила...". RAG может взять только второй кусок, и LLM не будет понимать о какой компании речь.
2. Гибридные подходы
a) Последовательный подход:
- RAG для initial filtering большого корпуса
- LC получает найденные куски + окружающий контекст
- Плюс: сохраняем связность информации
b) Параллельный подход:
- Запускаем и RAG и LC одновременно
- Сравниваем/комбинируем результаты
- Плюс: используем сильные стороны обоих
3. Практические рекомендации:
✅ Используйте RAG для первичной фильтрации
✅ Давайте LC больше контекста вокруг найденных кусков
✅ Экспериментируйте с размером чанков
✅ Сохраняйте метаданные об источниках
В итоге, гибридный подход – это не просто "сложить два метода вместе". Это возможность построить систему, где RAG отвечает за поиск релевантной информации, а LC – за её глубокое понимание с учетом контекста.
Я часто вижу, что в приложениях используется в основном RAG, а кто-то использует LC? Расскажите в комментах 👇
Long Context vs RAG: что лучше работает
В последнее время много обсуждений вокруг двух подходов к работе с большими документами в LLM: Long Context (LC) и Retrieval-Augmented Generation (RAG). Давайте разберем свежее исследование, которое проливает свет на их сравнение.
Ключевые находки:
1. Общая картина
LC в целом показывает лучшие результаты, чем RAG (56.3% vs 49.0% правильных ответов).
2. Где какой подход лучше работает:
LC хорош для:
- Википедии и других структурированных текстов
- Художественной литературы
- Четких фактологических вопросов (кто/где/когда)
RAG показывает себя лучше в:
- Диалогах
- Фрагментированной информации
- Общих вопросах (особенно да/нет)
3. Интересный момент про ретриверы
Протестировали разные подходы к поиску:
- BM25
- Contriever
- OpenAI Embeddings
- Llama-Index
- RAPTOR
RAPTOR (иерархический подход с саммаризацией) показал лучшие результаты – 38.5% правильных ответов. Это намекает на то, что будущее за более сложными методами ретрива, чем простой чанкинг 📈
4. Забавный факт
Около 29% вопросов из датасета модель могла ответить вообще без контекста – просто из своих параметров. Это показывает, насколько много знаний уже "зашито" в самих LLM.
5. Важный нюанс про датасеты
Многие бенчмарки для тестирования long context на самом деле constructed synthetic – то есть собраны из кусков релевантного текста + шум. По сути, это как предварительно сделанный RAG для LC модели, что создает определенный bias в тестировании.
Выводы:
- Нет универсально лучшего решения
- Выбор между LC и RAG должен зависеть от типа документов и задач
- Будущее вероятно за гибридными подходами
В последнее время много обсуждений вокруг двух подходов к работе с большими документами в LLM: Long Context (LC) и Retrieval-Augmented Generation (RAG). Давайте разберем свежее исследование, которое проливает свет на их сравнение.
Ключевые находки:
1. Общая картина
LC в целом показывает лучшие результаты, чем RAG (56.3% vs 49.0% правильных ответов).
2. Где какой подход лучше работает:
LC хорош для:
- Википедии и других структурированных текстов
- Художественной литературы
- Четких фактологических вопросов (кто/где/когда)
RAG показывает себя лучше в:
- Диалогах
- Фрагментированной информации
- Общих вопросах (особенно да/нет)
3. Интересный момент про ретриверы
Протестировали разные подходы к поиску:
- BM25
- Contriever
- OpenAI Embeddings
- Llama-Index
- RAPTOR
RAPTOR (иерархический подход с саммаризацией) показал лучшие результаты – 38.5% правильных ответов. Это намекает на то, что будущее за более сложными методами ретрива, чем простой чанкинг 📈
4. Забавный факт
Около 29% вопросов из датасета модель могла ответить вообще без контекста – просто из своих параметров. Это показывает, насколько много знаний уже "зашито" в самих LLM.
5. Важный нюанс про датасеты
Многие бенчмарки для тестирования long context на самом деле constructed synthetic – то есть собраны из кусков релевантного текста + шум. По сути, это как предварительно сделанный RAG для LC модели, что создает определенный bias в тестировании.
Выводы:
- Нет универсально лучшего решения
- Выбор между LC и RAG должен зависеть от типа документов и задач
- Будущее вероятно за гибридными подходами
Я запустил этот канал 1,5 месяца назад и не ожидал что смогу собрать первые 100 подписчиков за такой срок 🎅
В 2025 году планирую писать ещё больше постов, а также хочу запустить блог на английском языке.
Всех с наступающим Новым Годом 🎄, желаю счастья, успехов и здоровья!
В Вастрик.Клубе сейчас выходит серия постов (доступ публичный) про историю взаимоотношений Илона Маска и OpenAI, очень интересно, прям Санта-Барбара 🙂
Первая часть
Вторая часть
По первой части было понятно, что «всё не так однозначно» с Илоном в OpenAI 🙃
Первая часть
Вторая часть
По первой части было понятно, что «всё не так однозначно» с Илоном в OpenAI 🙃
Мой перевод наконец-то прошёл модерацию на Хабре и был опубликован час назад, уже успел схлопотать -1 рейтинга в карму 🤷♂️ 🤷♂️ 🤷♂️
У кого есть возможность голосования, плюсаните, плиз!♥️
https://habr.com/ru/articles/869360/
У кого есть возможность голосования, плюсаните, плиз!
https://habr.com/ru/articles/869360/
В комментах в Вастрик.Клубе резонно указали, что не хватает примеров. Хорошее замечание, поэтому добавим больше примеров.
Давайте разберём описанные подходы на кейсе – ai fitness app.
Идея приложения – AI может анализировать видео записи тренировок пользователя, давать советы по технике. Может составить план тренировок, план питания, вести пользователя по этим планам.
Начнём по порядку:
1. Цепочка промптов
Тут всё просто – например, для после регистрации пользователя в системе, просим его рассказать о себе и о своих целях. Далее, мы можем: проанализировать инпут пользователя и понять, достаточно ли нам информации для того чтобы составлять курс тренировки или нужно запросить у пользователя еще информацию.
Если информации достаточно, то передаём её в воркфлоу, который составляет программу тренировок. Можем передать эту информацию в воркфлоу, который составляет программу питания. А можем сделать необольшой ричёрч и посмотреть, например, рекомендации ВОЗ по физической нагрузке для конкретного нашего пользователя.
2. Воркфлоу: Роутинг
Здесь можно привести такой пример – пользователь голосом отправляет сообщение, например, о том, что у него есть вопрос по питанию. Под капотом, после того как мы дешифруем голос в текст, мы отправляем этот текст в "роутер", которому в системный промпт добавляем все возможные действия нашего приложения (например, ответить на вопросы по питанию, тренировкам; составить программу тренировок; заменить упражнение и т. д.). Ну и роутер уже может выбрать действие соответствующее запросу юзера и передать флоу далее по пайплайну.
3. Воркфлоу: Параллелизация
Декомпозиция: разделяем запросы на генерацию силовых упражнений, кардио упражнений, а полученный результат анализируем и готовим отчёт по всем упражнениям.
Консенсус: просим LLM в несколько запросов оценить технику выполнения, анализируем полученные результаты, находим общие паттерны и используем их в качестве совета.
4. Воркфлоу: Оркестратор
Насколько я понимаю, такой подход применяется в Pro версии Perplexity – когда система сама сначала разбивает задачу на сабтаски, потом генерит промпт для поиска информации в интернете и оценивает результат.
Я пока что не видел хороших примеров использования такого подхода (если вы знаете такие примеры, пишите в комментах), кроме как в системах подобных Perplexity, так как никогда не хочется давать электронному дурачку большой выбор – я считаю, что его стоит держать в узде и ограничивать набор разрешённых действий.
4. Воркфлоу: Оценщик
Одним запросом LLM выполняет задачу, например, по составлению плана тренировки.
Другим запросом LLM смотрит на этот план тренировки и валидирует его по указанным правилам, и отправляет первую LLM'ку переделывать свою работу
5. Агент
В моём понимании, агент – это более комплекс различных воркфлоу, интеграций со сторонними сервисами и в целом автономная система, которая в состоянии обработать (не обязательно решить) любой запрос пользователя и дать ответ.
Давайте разберём описанные подходы на кейсе – ai fitness app.
Идея приложения – AI может анализировать видео записи тренировок пользователя, давать советы по технике. Может составить план тренировок, план питания, вести пользователя по этим планам.
Начнём по порядку:
1. Цепочка промптов
Тут всё просто – например, для после регистрации пользователя в системе, просим его рассказать о себе и о своих целях. Далее, мы можем: проанализировать инпут пользователя и понять, достаточно ли нам информации для того чтобы составлять курс тренировки или нужно запросить у пользователя еще информацию.
Если информации достаточно, то передаём её в воркфлоу, который составляет программу тренировок. Можем передать эту информацию в воркфлоу, который составляет программу питания. А можем сделать необольшой ричёрч и посмотреть, например, рекомендации ВОЗ по физической нагрузке для конкретного нашего пользователя.
2. Воркфлоу: Роутинг
Здесь можно привести такой пример – пользователь голосом отправляет сообщение, например, о том, что у него есть вопрос по питанию. Под капотом, после того как мы дешифруем голос в текст, мы отправляем этот текст в "роутер", которому в системный промпт добавляем все возможные действия нашего приложения (например, ответить на вопросы по питанию, тренировкам; составить программу тренировок; заменить упражнение и т. д.). Ну и роутер уже может выбрать действие соответствующее запросу юзера и передать флоу далее по пайплайну.
3. Воркфлоу: Параллелизация
Декомпозиция: разделяем запросы на генерацию силовых упражнений, кардио упражнений, а полученный результат анализируем и готовим отчёт по всем упражнениям.
Консенсус: просим LLM в несколько запросов оценить технику выполнения, анализируем полученные результаты, находим общие паттерны и используем их в качестве совета.
4. Воркфлоу: Оркестратор
Насколько я понимаю, такой подход применяется в Pro версии Perplexity – когда система сама сначала разбивает задачу на сабтаски, потом генерит промпт для поиска информации в интернете и оценивает результат.
Я пока что не видел хороших примеров использования такого подхода (если вы знаете такие примеры, пишите в комментах), кроме как в системах подобных Perplexity, так как никогда не хочется давать электронному дурачку большой выбор – я считаю, что его стоит держать в узде и ограничивать набор разрешённых действий.
4. Воркфлоу: Оценщик
Одним запросом LLM выполняет задачу, например, по составлению плана тренировки.
Другим запросом LLM смотрит на этот план тренировки и валидирует его по указанным правилам, и отправляет первую LLM'ку переделывать свою работу
5. Агент
В моём понимании, агент – это более комплекс различных воркфлоу, интеграций со сторонними сервисами и в целом автономная система, которая в состоянии обработать (не обязательно решить) любой запрос пользователя и дать ответ.
Сделал перевод замечательного (очередного) поста от Anthropic об агентах.
https://vas3k.club/post/26791/
Во вчерашнем посту я упомянул, что у openai есть ограничения на длину ответа при использовании structured output. В комментах меня поправили, что речь скорее о размере всей схемы structured output при её определении, хоть и в документации это плохо объясняется.
Я кратко расскажу, почему я пришёл к такому выводу.
В моём кейсе, промпт подразумевает, что LLM сделает анализ входного текста и выдаст мне результат анализа + сразу же вытащит некоторые параметры этого репорта в виде JSON, чтобы я мог из этих параметров сгенерить красивые диаграммки (для кейса это нужно). При анализе данных я ставлю температуру повыше, 0.8-1, т.к мы помним, что низкая температура может отуплять модель.
Сегодня я обнаружил закономерность - при использовании structured output, если вы ожидаете довольно длинный текст в одном из полей, необходимо как можно больше снижать температуру🙂
Я провел краткий эксперимент. С одним и тем же промптом + инпутом я менял температуру и вот что получилось:
temp 1.0 - 175 tokens
temp 0.5 - 257 tokens
temp 0.2 - 588 tokens
Это количество токенов в одном поле, в котором я ожидаю полный анализ. Если что, я использую модель gpt-4o-2024-11-20.
В самом тексте модель либо просто никак не продолжает текст, либо пишет что-то вроде "ну дальше там тоже самое разберись сам"
Делаю вывод, что при повышении температуры, модель кумарит и ей становится лень работать🙂 🙂 🙂
Я кратко расскажу, почему я пришёл к такому выводу.
В моём кейсе, промпт подразумевает, что LLM сделает анализ входного текста и выдаст мне результат анализа + сразу же вытащит некоторые параметры этого репорта в виде JSON, чтобы я мог из этих параметров сгенерить красивые диаграммки (для кейса это нужно). При анализе данных я ставлю температуру повыше, 0.8-1, т.к мы помним, что низкая температура может отуплять модель.
Сегодня я обнаружил закономерность - при использовании structured output, если вы ожидаете довольно длинный текст в одном из полей, необходимо как можно больше снижать температуру
Я провел краткий эксперимент. С одним и тем же промптом + инпутом я менял температуру и вот что получилось:
temp 1.0 - 175 tokens
temp 0.5 - 257 tokens
temp 0.2 - 588 tokens
Это количество токенов в одном поле, в котором я ожидаю полный анализ. Если что, я использую модель gpt-4o-2024-11-20.
В самом тексте модель либо просто никак не продолжает текст, либо пишет что-то вроде "ну дальше там тоже самое разберись сам"
Делаю вывод, что при повышении температуры, модель кумарит и ей становится лень работать