Пишу про AI Coding, помогаю разработчикам освоить AI, внедряю AI в бизнес, провожу консультации.
Связь: @yatimur | Визитка: timurkhakhalev.t.me
Связь: @yatimur | Визитка: timurkhakhalev.t.me
Правительство США начинает регулировать экспорт 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.
В самом тексте модель либо просто никак не продолжает текст, либо пишет что-то вроде "ну дальше там тоже самое разберись сам"
Делаю вывод, что при повышении температуры, модель кумарит и ей становится лень работать
Только что до меня дошло, что у меня не было комментов на канале
Включил вроде🐱
Включил вроде
Технические заметки по одному текущему проекту
В последнее время много работаю с различными LLM и хочу поделиться некоторыми инсайтами.
Основную работу делаем через openai gpt-4o. Модель отлично справляется с извлечением JSON из текста, анализом информации, переводами и генерацией markdown таблиц. Кстати, забавный момент – пытались использовать gpt 4o-mini для оптимизации расходов, но столкнулись с тем, что она иногда игнорирует часть инструкций в промпте, особенно когда нужно и перевести текст с английского на русский, и сконвертировать его в markdown.
◾️ Structured output – база. Очень удобно вытаскивать нужную информацию из респонсов в виде JSON, а потом использовать в приложении.
◾️ Интеграция с zod (я пишу на node js) позволяет использовать схему для ответа модели еще и для типов в typescript.
◾️ Узнал, что у openai есть ограничения на длину ответа при использовании structured output - 15k символов (не токенов)
◾️ Кэширование на redis – мастхэв при разработке. В качестве ключей использую хэш system message + хэш user message, очень здорово экономятся токены.
Самый интересный технический челлендж возник при интеграции с Perplexity для получения актуальных данных. Оказалось, что их модели не очень дружит с русским языком – в ответах появляются китайские иероглифы🤯 Потом обнаружил, что их модели основаны на llama 3.1, а эта модель не поддерживает русский язык. Пришлось выкручиваться: теперь формируем запросы на английском, а потом переводим через gpt-4o. Хотя качество перевода пока не идеальное, подумываем о подключении специализированного сервиса переводов.
Забавно, но даже если в англоязычном промпте для Perplexity попросить ответить на русском – модель упорно игнорирует эту часть запроса😐
В последнее время много работаю с различными LLM и хочу поделиться некоторыми инсайтами.
Основную работу делаем через openai gpt-4o. Модель отлично справляется с извлечением JSON из текста, анализом информации, переводами и генерацией markdown таблиц. Кстати, забавный момент – пытались использовать gpt 4o-mini для оптимизации расходов, но столкнулись с тем, что она иногда игнорирует часть инструкций в промпте, особенно когда нужно и перевести текст с английского на русский, и сконвертировать его в markdown.
◾️ Structured output – база. Очень удобно вытаскивать нужную информацию из респонсов в виде JSON, а потом использовать в приложении.
◾️ Интеграция с zod (я пишу на node js) позволяет использовать схему для ответа модели еще и для типов в typescript.
◾️ Узнал, что у openai есть ограничения на длину ответа при использовании structured output - 15k символов (не токенов)
◾️ Кэширование на redis – мастхэв при разработке. В качестве ключей использую хэш system message + хэш user message, очень здорово экономятся токены.
Самый интересный технический челлендж возник при интеграции с Perplexity для получения актуальных данных. Оказалось, что их модели не очень дружит с русским языком – в ответах появляются китайские иероглифы
Забавно, но даже если в англоязычном промпте для Perplexity попросить ответить на русском – модель упорно игнорирует эту часть запроса
У кого-то из чата уже заработали аудио-ввод и вывод (генерация речи), у меня пока нет(
https://blog.google/technology/google-deepmind/google-gemini-ai-update-december-2024/
Ссылка попробовать в AI Studio БЕСПЛАТНО: тык
Reddit, крупнейшая площадка с пользовательским контентом, откуда Perplexity и другие AI берут самые полезные ответы, добавила поиск с ИИ - Reddit Answers.
По сути это диалоговый интерфейс поверх существующих обсуждений. Задаешь вопрос и получаешь релевантные куски с разных тредов, с прямыми ссылками на источники. Результаты можно читать прямо в поиске или переходить в оригинальные дискуссии.
Пока запустили только в США на английском. Обещают добавить другие страны и языки позже, можно подписаться на уведомления о запуске в своем регионе.
В отличие от генеративных чатботов, система не придумывает ответы, а собирает их из реальных обсуждений. Это логичный апгрейд поиска по Reddit - платформа давно пыталась сделать свой контент более доступным для поиска.
По сути это диалоговый интерфейс поверх существующих обсуждений. Задаешь вопрос и получаешь релевантные куски с разных тредов, с прямыми ссылками на источники. Результаты можно читать прямо в поиске или переходить в оригинальные дискуссии.
Пока запустили только в США на английском. Обещают добавить другие страны и языки позже, можно подписаться на уведомления о запуске в своем регионе.
В отличие от генеративных чатботов, система не придумывает ответы, а собирает их из реальных обсуждений. Это логичный апгрейд поиска по Reddit - платформа давно пыталась сделать свой контент более доступным для поиска.
Доброе утро!
Написал статью про промптинг, собрал все актуальные техники на конец 2024 года. Приятного чтения🌹 , обсуждение приветствуется 😍
https://teletype.in/@timur_khakhalev/prompts-guide-2024-2025
Написал статью про промптинг, собрал все актуальные техники на конец 2024 года. Приятного чтения
https://teletype.in/@timur_khakhalev/prompts-guide-2024-2025
В целом прикольно, хоть и сыровато пока что. На маке пока что не поддерживается работа с nvm (пакетный менеджер), необходимо вручную указывать путь до нужной версии ноды
Anthropic представили Model Context Protocol
Протокол MCP предназначен для того чтобы дать возможность LLM использовать 3rd-party приложения.
На сегодняшний день MCP поддерживают: Claude Desktop, Zed (IDE для маков), Cody (автокомплит для IDE).
Протокол open-source, так что любой разработчик может интегрировать его в свои приложения.
Здесь описан весь стандарт.
Протокол представляет собой типичную client-server архитектуру, где, на данный момент, clients – Claude Desktop, Zed, etc, server – 3rd-party apps. Участники протокола могут общаться между собой с помощью различных протоколов, можно даже создать свой, здесь подробнее.
На данный момент клиенты могут подключаться только к локальным серверам, позже обещают дать доступ для удалённых серверов.
В прикреплённом видео показывается пример того как пользователь просит Claude создать простую html страничку, опубликовать её в Github (с помощью созданного MCP сервера), создать Issue.
Таким образом, пользователь может в своём любимом UI (Claude, IDE, etc) просить LLM выполнить некоторые действия со сторонним приложением. Получился такой function calling на стероидах.
Ещё один шаг к распространению тренда на AI agents, пик которого ожидается на 2025 год.
Протокол MCP предназначен для того чтобы дать возможность LLM использовать 3rd-party приложения.
На сегодняшний день MCP поддерживают: Claude Desktop, Zed (IDE для маков), Cody (автокомплит для IDE).
Протокол open-source, так что любой разработчик может интегрировать его в свои приложения.
Здесь описан весь стандарт.
Протокол представляет собой типичную client-server архитектуру, где, на данный момент, clients – Claude Desktop, Zed, etc, server – 3rd-party apps. Участники протокола могут общаться между собой с помощью различных протоколов, можно даже создать свой, здесь подробнее.
На данный момент клиенты могут подключаться только к локальным серверам, позже обещают дать доступ для удалённых серверов.
В прикреплённом видео показывается пример того как пользователь просит Claude создать простую html страничку, опубликовать её в Github (с помощью созданного MCP сервера), создать Issue.
Таким образом, пользователь может в своём любимом UI (Claude, IDE, etc) просить LLM выполнить некоторые действия со сторонним приложением. Получился такой function calling на стероидах.
Ещё один шаг к распространению тренда на AI agents, пик которого ожидается на 2025 год.
Обнаружил у себя первых подпищеков, всем спасибо за подписку 💜
Пока думаю над следующим постом, ищу интересных авторов на сабстаке и в твитторе, наткнулся на сабстак Jeremy Caplan, который обозревает новые AI тулы разного вида. Вот, например
https://wondertools.substack.com/p/aidata?utm_source=profile&utm_medium=reader2
https://wondertools.substack.com/p/heres-my-ai-toolkit?utm_source=profile&utm_medium=reader2
Я для себя ничего полезного не нашёл, но может кому-то будет полезно
Пока думаю над следующим постом, ищу интересных авторов на сабстаке и в твитторе, наткнулся на сабстак Jeremy Caplan, который обозревает новые AI тулы разного вида. Вот, например
https://wondertools.substack.com/p/aidata?utm_source=profile&utm_medium=reader2
https://wondertools.substack.com/p/heres-my-ai-toolkit?utm_source=profile&utm_medium=reader2
Я для себя ничего полезного не нашёл, но может кому-то будет полезно