Клуб по интересам - SAP + AI R&D
Идея AI R&D в области автоматизации бизнес-процессов в SAP выстрелила лучше, чем я ожидал.
SAP - это как 1C, только гораздо масштабнее и сложнее. Им пользуются почти все крупнейшие компании в мире.
Причем не только со стороны разработчиков и команд (т.к. это интересный и сложный кейс для внедрения AI агентов/операторов в крупных компаниях), но и со стороны компаний, которые с этим SAP работают.
Поэтому сейчас начинаем процесс сбора кейсов использования SAP, где есть самый обычный бизнес процесс, который ну очень очень хочется хоть как-то автоматизировать. Например: добавление нового фрилансера в систему, добавление инвойса, согласование табелей рабочего времени или обработка закупочных заказов.
Собирать кейсы будем в таком формате, который сделает удобным создание отраслевого бенчмарка для операторов и агентов. А потом - подчистку специфики и запуск открытого Enterprise RPA Challenge на эту тему (как мы это с вами сделали с RAG-ами)
Про формат сбора кейсов я потом напишу. Если кратко, то понадобится несколько скриншотов интерфейса (секреты можно и нужно замазывать), заполненный вопросник про бизнес-процесс и контакт эксперта, который может ответить на вопросы.
Как ни странно, это как раз та конкретика и движуха, которой не хватает ни AI R&D командам ни даже самому SAP и его партнерам. Ну а те компании, которые пришлют подходящие кейсы - попадут в этот небольшой клуб по интересам.
Пока все предварительно. Если потенциально интересно поучаствовать или есть вопросы - пишите в комментарии. Лучше сразу упоминать отрасль и тип бизнес-процесса. Имена и названия - не обязательно)
Ваш, @llm_under_hood 🤗
Идея AI R&D в области автоматизации бизнес-процессов в SAP выстрелила лучше, чем я ожидал.
SAP - это как 1C, только гораздо масштабнее и сложнее. Им пользуются почти все крупнейшие компании в мире.
Причем не только со стороны разработчиков и команд (т.к. это интересный и сложный кейс для внедрения AI агентов/операторов в крупных компаниях), но и со стороны компаний, которые с этим SAP работают.
Поэтому сейчас начинаем процесс сбора кейсов использования SAP, где есть самый обычный бизнес процесс, который ну очень очень хочется хоть как-то автоматизировать. Например: добавление нового фрилансера в систему, добавление инвойса, согласование табелей рабочего времени или обработка закупочных заказов.
Собирать кейсы будем в таком формате, который сделает удобным создание отраслевого бенчмарка для операторов и агентов. А потом - подчистку специфики и запуск открытого Enterprise RPA Challenge на эту тему (как мы это с вами сделали с RAG-ами)
Про формат сбора кейсов я потом напишу. Если кратко, то понадобится несколько скриншотов интерфейса (секреты можно и нужно замазывать), заполненный вопросник про бизнес-процесс и контакт эксперта, который может ответить на вопросы.
Как ни странно, это как раз та конкретика и движуха, которой не хватает ни AI R&D командам ни даже самому SAP и его партнерам. Ну а те компании, которые пришлют подходящие кейсы - попадут в этот небольшой клуб по интересам.
Пока все предварительно. Если потенциально интересно поучаствовать или есть вопросы - пишите в комментарии. Лучше сразу упоминать отрасль и тип бизнес-процесса. Имена и названия - не обязательно)
Ваш, @llm_under_hood 🤗
🔥46❤10🤝6😱3👍1
Кейсы: Структурированное извлечение данных из документов, типичные проблемы и советы
Вчера консультировал компанию, которая занимается логистикой в Европе. Они пилят внутренний продукт с LLM под капотом.
Кейс - нужно извлекать информацию из таможенных деклараций, чтобы автоматически загружать в дальнейший бизнес-процесс. Ситуация осложняется тем, что в каждой стране EU свой формат деклараций, а единого электронного формата пока нет.
Текущий статус - используют Google Gemini, которому скармливают страницы и просят извлечь ответ по структуре. Есть даже evaluation datasets. По ним видно, что точность пока недостаточна.
Но вот как этот прототип масштабировать до стабильного продукта в компании и осознанно двигаться к повышению качества - они пока не знают. А галлюцинаций там хватает.
У меня было минут 30, поэтому быстро прошлись по их решению и сразу перешли к обсуждению того, как с этим работать. Мои советы были очень типичны - просто подсветить приоритет того, что нужно сделать в первую очередь:
(1) Закрыть Feedback Loop и сделать так, чтобы можно было очень быстро тестировать качество работы всего пайплайна после любого изменения. В идеале, если на выходе будет визуализация ошибок в виде heatmap.
(вот пример визуализации: https://labs.abdullin.com/res/ai-assistants-ru-S02M13-heatmaps.png)
Тогда можно будет повысить качество просто подбором параметров pipeline. Причем это будет делать не от балды, а осознанно - по паттернам ошибок.
(2) Выкинуть ненужный мусор из промпта и начать использовать SO/CoT на всю катушку. У них был текстовый промпт, который не использовал ни Literals (вместо этого добавили вручную правило в текст) ни встраивал цепочки рассуждений перед проблемными полями. Из-за этого точность была сильно хуже того, что можно было получить.
(3) Следить за Signal vs Noise и декомпозировать, если сложные задачи. Но извлечение данных - это обычно задача простая.
И, в принципе, все. Этих вещей достаточно для того, чтобы начать двигаться в правильном направлении с технической стороны.
А одной команде это и вовсе помогло решить полностью конкретную проблему в инструменте для командной работы. Было:
После подсветки приоритетов команда сфокусировалась на главном и быстро получила результат:
Так что если у вас в продукте с LLM под капотом есть схожая ситуация, то для начала можно свериться с тремя пунктами выше. А для осознанности и понимания контекста можно еще прочитать разборы других кейсов продуктов с LLM под капотом.
Кто-нибудь еще валидирует ошибки не одной accuracy, а интересной таблицей или графиком? Поделитесь скриншотами своих визуализаций!
Ваш, @llm_under_hood 🤗
Вчера консультировал компанию, которая занимается логистикой в Европе. Они пилят внутренний продукт с LLM под капотом.
Кейс - нужно извлекать информацию из таможенных деклараций, чтобы автоматически загружать в дальнейший бизнес-процесс. Ситуация осложняется тем, что в каждой стране EU свой формат деклараций, а единого электронного формата пока нет.
Текущий статус - используют Google Gemini, которому скармливают страницы и просят извлечь ответ по структуре. Есть даже evaluation datasets. По ним видно, что точность пока недостаточна.
Но вот как этот прототип масштабировать до стабильного продукта в компании и осознанно двигаться к повышению качества - они пока не знают. А галлюцинаций там хватает.
У меня было минут 30, поэтому быстро прошлись по их решению и сразу перешли к обсуждению того, как с этим работать. Мои советы были очень типичны - просто подсветить приоритет того, что нужно сделать в первую очередь:
(1) Закрыть Feedback Loop и сделать так, чтобы можно было очень быстро тестировать качество работы всего пайплайна после любого изменения. В идеале, если на выходе будет визуализация ошибок в виде heatmap.
(вот пример визуализации: https://labs.abdullin.com/res/ai-assistants-ru-S02M13-heatmaps.png)
Тогда можно будет повысить качество просто подбором параметров pipeline. Причем это будет делать не от балды, а осознанно - по паттернам ошибок.
(2) Выкинуть ненужный мусор из промпта и начать использовать SO/CoT на всю катушку. У них был текстовый промпт, который не использовал ни Literals (вместо этого добавили вручную правило в текст) ни встраивал цепочки рассуждений перед проблемными полями. Из-за этого точность была сильно хуже того, что можно было получить.
(3) Следить за Signal vs Noise и декомпозировать, если сложные задачи. Но извлечение данных - это обычно задача простая.
И, в принципе, все. Этих вещей достаточно для того, чтобы начать двигаться в правильном направлении с технической стороны.
А одной команде это и вовсе помогло решить полностью конкретную проблему в инструменте для командной работы. Было:
Оно по сути работает, но надежности добиться не получается никак… Причем иногда оно стабильно работает неделями, а потом чето рандомно ломается) Довольно плохо слушает инструкции, даже жесткие. Модели разные пробовали, лучше всего на гпт 4о.
Подскажи пожалуйста, в нашем кейсе реально добиться надежности или пока технологически ограничены?
После подсветки приоритетов команда сфокусировалась на главном и быстро получила результат:
Да действительно так все и оказалось как ты говорил.
Нормальный промпт, SO+checklist показали приемлемую надежность в ответах даже на датасете со сложными переменными даты и времени.
Спасибо 🤝
Так что если у вас в продукте с LLM под капотом есть схожая ситуация, то для начала можно свериться с тремя пунктами выше. А для осознанности и понимания контекста можно еще прочитать разборы других кейсов продуктов с LLM под капотом.
Кто-нибудь еще валидирует ошибки не одной accuracy, а интересной таблицей или графиком? Поделитесь скриншотами своих визуализаций!
Ваш, @llm_under_hood 🤗
👍67🔥34❤16🥰2😁1
Какой паттерн из курса вам пригодился больше всего?
Если вы прошли мой курс по AI Ассистентам или проходите его, напишите, пожалуйста, какой паттерн из курса вам пригодился больше всего? REPL, Search итп. И чем он помог?
Я потом распишу подробно самый полезный паттерн отдельным постом в канале, а ответы на самые частые вопросы - интегрирую обратно в курс.
Ваш, @llm_under_hood 🤗
Если вы прошли мой курс по AI Ассистентам или проходите его, напишите, пожалуйста, какой паттерн из курса вам пригодился больше всего? REPL, Search итп. И чем он помог?
Я потом распишу подробно самый полезный паттерн отдельным постом в канале, а ответы на самые частые вопросы - интегрирую обратно в курс.
Ваш, @llm_under_hood 🤗
❤21🔥11🤝5🤗3😁1
SO CoT - самый полезный паттерн при создании продуктов с LLM под капотом
Так выходит, если судить по комментариям в моем прошлом опросе.
Я обещал расписать самый полезный паттерн постом в канале. Поскольку сам ответ не влазит в масштаб и формат поста, вот вам две статьи с более подробным описанием и примерами:
- Structured Output (SO): https://abdullin.com/structured-output/
- Custom Chain of Thought (SO CoT): https://abdullin.com/custom-chain-of-thought/
Ваш, @llm_under_hood 🤗
Так выходит, если судить по комментариям в моем прошлом опросе.
Я обещал расписать самый полезный паттерн постом в канале. Поскольку сам ответ не влазит в масштаб и формат поста, вот вам две статьи с более подробным описанием и примерами:
- Structured Output (SO): https://abdullin.com/structured-output/
- Custom Chain of Thought (SO CoT): https://abdullin.com/custom-chain-of-thought/
Ваш, @llm_under_hood 🤗
❤73👍36🔥23⚡2🤩2😁1💯1🤝1
Llama 4 вышла - MoE по 17B на эксперта
Пока в мире гадают, что это за модель Quasar на OpenRouter, Meta выпустила четвертую версию Llama
Читать тут. Любоваться тут.
Модели Llama 4 — это мультимодальные MoE модели, оптимизированные для многоязычных задач, программирования, вызова инструментов и создания автономных систем (агентов). Знания - по август 2024.
Llama 4 Scout:
- Поддерживается ввод текста и до 5 изображений.
- Поддерживает арабский, английский, французский, немецкий, хинди, индонезийский, итальянский, португальский, испанский, тагальский, тайский и вьетнамский языки (понимание изображений — только на английском).
- 16 экспертов по 17B
- Может работать на одном GPU (при использовании INT4-квантованной версии на одном GPU H100).
- Максимальная длина контекста: 10 млн токенов.
Llama 4 Maverick:
- Мультимодальность
- Поддерживает те же языки, что и Scout (понимание изображений — только на английском).
- 128 экспертов по 17B параметров
- Максимальная длина контекста: 1 млн токенов.
Хотя общее число параметров составляет 109B и 400B, во время вычислений активны только 17B, что уменьшает задержки при выводе и обучении. Это очень неплохо должно лечь на Apple Silicon!
Ваш, @llm_under_hood 🤗
Пока в мире гадают, что это за модель Quasar на OpenRouter, Meta выпустила четвертую версию Llama
Читать тут. Любоваться тут.
Модели Llama 4 — это мультимодальные MoE модели, оптимизированные для многоязычных задач, программирования, вызова инструментов и создания автономных систем (агентов). Знания - по август 2024.
Llama 4 Scout:
- Поддерживается ввод текста и до 5 изображений.
- Поддерживает арабский, английский, французский, немецкий, хинди, индонезийский, итальянский, португальский, испанский, тагальский, тайский и вьетнамский языки (понимание изображений — только на английском).
- 16 экспертов по 17B
- Может работать на одном GPU (при использовании INT4-квантованной версии на одном GPU H100).
- Максимальная длина контекста: 10 млн токенов.
Llama 4 Maverick:
- Мультимодальность
- Поддерживает те же языки, что и Scout (понимание изображений — только на английском).
- 128 экспертов по 17B параметров
- Максимальная длина контекста: 1 млн токенов.
Хотя общее число параметров составляет 109B и 400B, во время вычислений активны только 17B, что уменьшает задержки при выводе и обучении. Это очень неплохо должно лечь на Apple Silicon!
Ваш, @llm_under_hood 🤗
🔥61❤10🤩8👍5😁1
Как заставить AI писать качественный код?
Нужно просто мыслить масштабно. Сейчас объясню)
Я знаю, что модели уже давно способны писать качественный код. Просто они как джинн с тремя желаниями. Нужно правильно уметь формулировать свои требования и хотелки, даже просто разбивать задачу. AI - это инструмент, с которым надо набить руку.
В рамках эксперимента по обучению AI+Coding разработчиков одной компании, я увидел, что для этого умения требуется две вещи:
(1) насмотренность - чтобы знать паттерны того, что и как нужно просить у моделей
(2) практика - чтобы можно было оперировать этими паттернами не задумываясь.
Проиллюстрировать это может помочь такое практическое задание.
Нужно написать качественный код парсера бизнес-документации на основе вот этого требования. Чем быстрее, тем лучше. Язык не имеет значения. Но вы должны быть уверены в качестве этого кода [1] Максимальное время - 4 часа.
А потом в комментариях к посту - рассказать насколько далеко и быстро получилось дойти, и какие шаги были сделаны. И сравнить свои действия с действиями других. Они будут кардинально различаться!
После такого простого упражнения один из участников (с кучей опыта разработки сложных систем) написал:
В общем, нет никакой магии в том, чтобы использовать AI для написания качественного кода. Нужна просто практика и насмотренность на разные паттерны использования. Кто-то это назовет "мыслить масштабно". Можно начать с упражнения выше.
Ваш, @llm_under_hood 🤗
[1] Если вдруг во время выполнения задания встретите очередную пасхалку - так и надо. Use your best judgement.
Нужно просто мыслить масштабно. Сейчас объясню)
Я знаю, что модели уже давно способны писать качественный код. Просто они как джинн с тремя желаниями. Нужно правильно уметь формулировать свои требования и хотелки, даже просто разбивать задачу. AI - это инструмент, с которым надо набить руку.
В рамках эксперимента по обучению AI+Coding разработчиков одной компании, я увидел, что для этого умения требуется две вещи:
(1) насмотренность - чтобы знать паттерны того, что и как нужно просить у моделей
(2) практика - чтобы можно было оперировать этими паттернами не задумываясь.
Проиллюстрировать это может помочь такое практическое задание.
Нужно написать качественный код парсера бизнес-документации на основе вот этого требования. Чем быстрее, тем лучше. Язык не имеет значения. Но вы должны быть уверены в качестве этого кода [1] Максимальное время - 4 часа.
А потом в комментариях к посту - рассказать насколько далеко и быстро получилось дойти, и какие шаги были сделаны. И сравнить свои действия с действиями других. Они будут кардинально различаться!
После такого простого упражнения один из участников (с кучей опыта разработки сложных систем) написал:
Это действительно впечатляет. Я думал, что предоставил инструменту слишком много контроля, разбив задачу на пошаговые действия, но, похоже, даже этого оказалось недостаточно. Я мыслил недостаточно масштабно.
В общем, нет никакой магии в том, чтобы использовать AI для написания качественного кода. Нужна просто практика и насмотренность на разные паттерны использования. Кто-то это назовет "мыслить масштабно". Можно начать с упражнения выше.
Ваш, @llm_under_hood 🤗
[1] Если вдруг во время выполнения задания встретите очередную пасхалку - так и надо. Use your best judgement.
❤47👍24🔥22🤝3😁2🤣2🎄2
А как решалось AI+Coding упражнение про парсер?
(см описание тут)
Да все просто и быстро. Самое главное - думать как опытный и ленивый специалист. То есть, свалить максимум работ на AI. Humans decide, AI does mundane work.
Первый шаг - просим просмотреть требования и проанализировать задачу. Например, что-то вроде:
Оно выдаст что-то годное:
1. Clarify Requirements and Edge Cases
2. Choose the Right Parsing Strategy
3. Clearly Define Parser Responsibilities
4. Implement Parsing in Phases (Iterative and Incremental)
5. Develop a Robust Testing Strategy. Tests are critical—write them first!
6. Error Handling and Reporting
7. Implementation Quality and Maintainability
8. Iterate with Feedback
Подсветка моя. Дальше действуем по плану. Начнем с тестов. Если спросить у AI идеи про тесты (чтобы попроще и попрагматичнее), то оно укажет на такой абзац в тексте:
Нам даже не надо писать тесты (что сделал каждый участник экспериментальной группы), достаточно просто распарсить этот текст и достать пары input-expected.
Поэтому, сначала подчистим текст в markdown, который любит любой AI:
Если LLM не осиливает весь объем сразу, то можно временно переключиться на модель с reasoning или просто спеку кусками вставлять.
Кстати, а что еще нам AI советовал? Clarify Requirements and Edge Cases
Вот тут AI и найдет грабли, про которые я предупреждал. Можно поправить, а можно оставить так.
Ладно, читаемый текст в формате md есть, “пишем” тесты:
Оно напишет извлекатор, который можно красиво обернуть вручную (Copilot) в тестер. Он будет доставать текст из файла, разбирать input и сравнивать его с ожидаемым результатом. Все.
А потом финальный цикл разработки:
Вставляем результат в код и смотрим. Если вдруг какие-то тесты не проходят - кидаем код парсера, спек и текст ошибки в ChatGPT/Claude и просим поправить.
У меня при проходе по этому workflow с ChatGPT все тесты стали зелеными за пару итераций.
А у вас как быстро сходятся все тесты?
Ваш, @llm_under_hood 🤗
(см описание тут)
Да все просто и быстро. Самое главное - думать как опытный и ленивый специалист. То есть, свалить максимум работ на AI. Humans decide, AI does mundane work.
Первый шаг - просим просмотреть требования и проанализировать задачу. Например, что-то вроде:
Help me to identify the most efficient and error-prone way to implement this parser. Don't code, just think and plan from the perspective of a very experienced pragmatic software engineer with 20 years of experience in shipping systems to production
Оно выдаст что-то годное:
1. Clarify Requirements and Edge Cases
2. Choose the Right Parsing Strategy
3. Clearly Define Parser Responsibilities
4. Implement Parsing in Phases (Iterative and Incremental)
5. Develop a Robust Testing Strategy. Tests are critical—write them first!
6. Error Handling and Reporting
7. Implementation Quality and Maintainability
8. Iterate with Feedback
Подсветка моя. Дальше действуем по плану. Начнем с тестов. Если спросить у AI идеи про тесты (чтобы попроще и попрагматичнее), то оно укажет на такой абзац в тексте:
The document below describes a simple text format that can be deterministically parsed into JSON objects. This document is also a test suite! Code admonitions always come in pairs: first input and then json.
Нам даже не надо писать тесты (что сделал каждый участник экспериментальной группы), достаточно просто распарсить этот текст и достать пары input-expected.
Поэтому, сначала подчистим текст в markdown, который любит любой AI:
Carefully read this spec. It lost its markdown formatting, please fix and return it.
Если LLM не осиливает весь объем сразу, то можно временно переключиться на модель с reasoning или просто спеку кусками вставлять.
Кстати, а что еще нам AI советовал? Clarify Requirements and Edge Cases
Check this spec for any contradictions or mistakes. For each - suggest a fix. Use your best judgement
Вот тут AI и найдет грабли, про которые я предупреждал. Можно поправить, а можно оставить так.
Ладно, читаемый текст в формате md есть, “пишем” тесты:
This is the spec that I have saved in file spec.md. Please write me python parser to read this spec and extract all code blocks.
Оно напишет извлекатор, который можно красиво обернуть вручную (Copilot) в тестер. Он будет доставать текст из файла, разбирать input и сравнивать его с ожидаемым результатом. Все.
А потом финальный цикл разработки:
You are an experienced and pragmatic software engineer with two decades of experience. Write me a recursive descent parser that will implement function `def parse(input: str) → Block` and will follow this spec:
Вставляем результат в код и смотрим. Если вдруг какие-то тесты не проходят - кидаем код парсера, спек и текст ошибки в ChatGPT/Claude и просим поправить.
У меня при проходе по этому workflow с ChatGPT все тесты стали зелеными за пару итераций.
А у вас как быстро сходятся все тесты?
Ваш, @llm_under_hood 🤗
🥰26🔥23👍18❤12🤔4🤯2⚡1😱1🤩1
LLM Benchmarks - прогресс у Google
За месяц накопились новые бенчмарки. Поэтому вот сразу пачка обновлений.
Gemini-2.5-pro-preview - это платная и самая большая модель Google. Она так хороша, как про нее говорят. В моем LLM бенчмарке на продуктовых задачах она побила OpenAI o1 и Anthropic Claude 3.7 Sonnet, заняв второе место. При этом она работала без Structured Outputs (ибо у Google он пока реализован шиворот навыворот)
DeepSeek-V3-0324 - это новая версия DeepSeek Chat (не путать с r1). Они смогли последовательно улучшить качество предыдущей chat версии. Прогресс не стоит на месте. Посмотрим, как у них будет дальше с новыми моделями.
Llama 4 модели - появились на радаре, но пока не обладают выдающимися способностями. Но это типичная картина, которая повторялась со всеми версиями Llama. Meta выпускает мощные foundational модели, которые потом тюнятся под конкретные задачи. Ждем r1 distill.
Gemma-3-27B-it - а вот тут уже очень интересно становится. Эта локальная мультимодальная модель от Google Deepmind. Это первая модель такого небольшого размера, которая забралась так высоко. Заявляется контекст 128k, поддержка 140 языков и function calling.
Возможно благодаря последнему модель смогла вытянуть достойный результат без поддержки Structured Output. Лучше всего она показала себя в инженерных задачах на работу со сложным кодом.
Ее младшая сестренка - gemma-3-12b-it тоже отличилась и заняла место на уровне лучших моделей в пару раз больше.
Что-то такое интересное Google DeepMind нащупали, что дает им возможность клепать хорошие модели по всем уровням (еще и на TPU). Будем ждать от них новых релизов.
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
За месяц накопились новые бенчмарки. Поэтому вот сразу пачка обновлений.
Gemini-2.5-pro-preview - это платная и самая большая модель Google. Она так хороша, как про нее говорят. В моем LLM бенчмарке на продуктовых задачах она побила OpenAI o1 и Anthropic Claude 3.7 Sonnet, заняв второе место. При этом она работала без Structured Outputs (ибо у Google он пока реализован шиворот навыворот)
DeepSeek-V3-0324 - это новая версия DeepSeek Chat (не путать с r1). Они смогли последовательно улучшить качество предыдущей chat версии. Прогресс не стоит на месте. Посмотрим, как у них будет дальше с новыми моделями.
Llama 4 модели - появились на радаре, но пока не обладают выдающимися способностями. Но это типичная картина, которая повторялась со всеми версиями Llama. Meta выпускает мощные foundational модели, которые потом тюнятся под конкретные задачи. Ждем r1 distill.
Gemma-3-27B-it - а вот тут уже очень интересно становится. Эта локальная мультимодальная модель от Google Deepmind. Это первая модель такого небольшого размера, которая забралась так высоко. Заявляется контекст 128k, поддержка 140 языков и function calling.
Возможно благодаря последнему модель смогла вытянуть достойный результат без поддержки Structured Output. Лучше всего она показала себя в инженерных задачах на работу со сложным кодом.
Ее младшая сестренка - gemma-3-12b-it тоже отличилась и заняла место на уровне лучших моделей в пару раз больше.
Что-то такое интересное Google DeepMind нащупали, что дает им возможность клепать хорошие модели по всем уровням (еще и на TPU). Будем ждать от них новых релизов.
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
🔥52👍16❤12🤔2🤯2😱1🤩1
Исключительный повод написать про квантизацию (сжатие) моделей
Про квантизации я обычно не пишу, т.к. в бизнес задачах их практически не используют [1].
Но Google Gemma-3-27B стала исключением. Это сама по себе хорошая модель, которая еще и внезапно неплохо умеет в reasoning c SO CoT. Она весит 55GB и при загрузке в GPU в bf16 формате потребует ~ 60GB VRAM для текстовых задач. Это значит, что она влазит в одну H100 80GB.
Народ, естественно, начал перепаковывать эту модель в всякие хитрые квантизации, чтобы запускать на карточках поменьше.
А потом Google сделали ход конем и выпустили официальный google/gemma-3-27b-it-qat-q4_0-gguf. Эта квантизация условно использует не два байта на один параметр, а в четыре раза меньше (~4 бита на параметр), что транслируется в ~3x экономии памяти.
Фишка и отличие здесь в том, что Google использовали Quantisation Aware Training (QAT), которая позволяет пожать модель без особой потери качества.
Если раньше у меня были большие надежды на версии qwen-2.5 для умных локальных систем, то сейчас еще больше нравится Gemma-3 (27B и 12B). У них выхлоп на размер сильно больше, думать умеют, поддержка языков заявлена хорошая, а теперь еще и появилось больше способов запускать на разном железе.
Возможности для стартапов с локальными моделями прямо подскочили!
Ваш, @llm_under_hood 🤗
[1] Квантизации могут экономить память GPU-шек за счет сжатия параметров , но при этом негативно влиять на точность и скорость ответов. Чем сильнее и хитрее пожали, тем больше эффект. И при этом еще и требуется, чтобы такую хитрую квантизацию нормально поддерживал софт и были люди с опытом.
bf16 за квантизацию можно не считать, да и fp8 тоже (если он делается при помощи QAT и запускается нативно на GPU последних поколений)
Про квантизации я обычно не пишу, т.к. в бизнес задачах их практически не используют [1].
Но Google Gemma-3-27B стала исключением. Это сама по себе хорошая модель, которая еще и внезапно неплохо умеет в reasoning c SO CoT. Она весит 55GB и при загрузке в GPU в bf16 формате потребует ~ 60GB VRAM для текстовых задач. Это значит, что она влазит в одну H100 80GB.
Народ, естественно, начал перепаковывать эту модель в всякие хитрые квантизации, чтобы запускать на карточках поменьше.
А потом Google сделали ход конем и выпустили официальный google/gemma-3-27b-it-qat-q4_0-gguf. Эта квантизация условно использует не два байта на один параметр, а в четыре раза меньше (~4 бита на параметр), что транслируется в ~3x экономии памяти.
Фишка и отличие здесь в том, что Google использовали Quantisation Aware Training (QAT), которая позволяет пожать модель без особой потери качества.
Если раньше у меня были большие надежды на версии qwen-2.5 для умных локальных систем, то сейчас еще больше нравится Gemma-3 (27B и 12B). У них выхлоп на размер сильно больше, думать умеют, поддержка языков заявлена хорошая, а теперь еще и появилось больше способов запускать на разном железе.
Возможности для стартапов с локальными моделями прямо подскочили!
Ваш, @llm_under_hood 🤗
[1] Квантизации могут экономить память GPU-шек за счет сжатия параметров , но при этом негативно влиять на точность и скорость ответов. Чем сильнее и хитрее пожали, тем больше эффект. И при этом еще и требуется, чтобы такую хитрую квантизацию нормально поддерживал софт и были люди с опытом.
bf16 за квантизацию можно не считать, да и fp8 тоже (если он делается при помощи QAT и запускается нативно на GPU последних поколений)
🔥63👍21❤9🤯4🥰1💯1
Google: Agent2Agent Protocol (A2A)
Google захотела сделать свой MCP протокол, только с крупными компаниями. Готово.
Назвали его A2A (Agent2Agent). Это открытый стандарт для обмена информацией между ИИ-агентами, работающими в разных системах. Он использует технологии HTTP, SSE и JSON-RPC для упрощения интеграции в существующую инфраструктуру.
Основные моменты:
(1) Dynamic Capability Discovery - агенты обмениваются данными через JSON-Agent Card, что позволяет выбирать подходящего исполнителя задачи.
(2) Task-Centric Communication - протокол работает с задачами, у которых есть свой жизненный цикл. A2A поддерживает как быстрые операции, так и долгосрочные процессы с обратной связью и уведомлениями.
(3) Security (за что критиковали MCP) - продуманы средства аутентификации и авторизации для защиты данных.
(4) Мультимодальность - обмен информацией в виде текста, аудио или видео.
В теории, общее назначение A2A - упростить автоматизацию и интеграцию процессов в корпоративных системах. Однако на HN люди уже высказывались насчет сложности протокола и его влияния на контроль над данными. Мол, нагородили всякого, лишь бы рынок отжевать.
Мне кажется, с такой компанией оно может и взлететь. Но из-за сложности и непредсказуемости систем лететь будет так себе.
Почитать доки можно тут.
Ваш, @llm_under_hood 🤗
Google захотела сделать свой MCP протокол, только с крупными компаниями. Готово.
Назвали его A2A (Agent2Agent). Это открытый стандарт для обмена информацией между ИИ-агентами, работающими в разных системах. Он использует технологии HTTP, SSE и JSON-RPC для упрощения интеграции в существующую инфраструктуру.
Основные моменты:
(1) Dynamic Capability Discovery - агенты обмениваются данными через JSON-Agent Card, что позволяет выбирать подходящего исполнителя задачи.
(2) Task-Centric Communication - протокол работает с задачами, у которых есть свой жизненный цикл. A2A поддерживает как быстрые операции, так и долгосрочные процессы с обратной связью и уведомлениями.
(3) Security (за что критиковали MCP) - продуманы средства аутентификации и авторизации для защиты данных.
(4) Мультимодальность - обмен информацией в виде текста, аудио или видео.
В теории, общее назначение A2A - упростить автоматизацию и интеграцию процессов в корпоративных системах. Однако на HN люди уже высказывались насчет сложности протокола и его влияния на контроль над данными. Мол, нагородили всякого, лишь бы рынок отжевать.
Мне кажется, с такой компанией оно может и взлететь. Но из-за сложности и непредсказуемости систем лететь будет так себе.
Почитать доки можно тут.
Ваш, @llm_under_hood 🤗
👍34❤11🤔6🤯3😁2🔥1😢1🤝1
Cекретная Quasar Alpha модель довольно неплоха. Погадаем, кто это?
У модели 8 место в моем бенчмарке на текущий момент.
Пока не совсем известно, кто это может быть, но мы можем применить дедукцию)
Смотрите, у модели есть нормальный Structured Output, которым она умеет пользоваться. Это сразу сужает круг подозреваемых:
(1) OpenAI
(2) Fireworks SO
(3) Mistral
Кстати, Google не стоит и близко, т.к. их Structured Output - это не JSON Schema, а огрызок от OpenAPI в версии VertexAI API. Он бы мой бенчмарк не вытащил.
FireworksAI можно вычеркивать смело, новые модели - это не их формат.
Остаются только OpenAI и Mistral. OpenAI слишком крупный для рекламной компании с OpenRouter - это не их профиль, а вот для небольшой французской компании Mistral - формат подойдет. Плюс, у них давно не было толковых релизов.
Да и, если смотреть на
Так что я думаю, что секретный Quasar - это новая французская моделька. Если это так, то их стоит поздравить с хорошим результатом!
Кстати, судя по профилю latency - модель относительно небольшая. То, что она так высоко забралась делает ее интересной и потенциально недорогой.
Ваш, @llm_under_hood 🤗
У модели 8 место в моем бенчмарке на текущий момент.
Пока не совсем известно, кто это может быть, но мы можем применить дедукцию)
Смотрите, у модели есть нормальный Structured Output, которым она умеет пользоваться. Это сразу сужает круг подозреваемых:
(1) OpenAI
(2) Fireworks SO
(3) Mistral
Кстати, Google не стоит и близко, т.к. их Structured Output - это не JSON Schema, а огрызок от OpenAPI в версии VertexAI API. Он бы мой бенчмарк не вытащил.
FireworksAI можно вычеркивать смело, новые модели - это не их формат.
Остаются только OpenAI и Mistral. OpenAI слишком крупный для рекламной компании с OpenRouter - это не их профиль, а вот для небольшой французской компании Mistral - формат подойдет. Плюс, у них давно не было толковых релизов.
Да и, если смотреть на
supported parameters
Quasar, то совпадений больше с предыдущими моделями Mistral, нежели с OpenAI. Профиль latency + throughput тоже похож.Так что я думаю, что секретный Quasar - это новая французская моделька. Если это так, то их стоит поздравить с хорошим результатом!
Кстати, судя по профилю latency - модель относительно небольшая. То, что она так высоко забралась делает ее интересной и потенциально недорогой.
Ваш, @llm_under_hood 🤗
🔥66👍17❤11🤣2
Нас не волнует то, чего мы не знаем. LLM тоже
На фотографии - McArthur Wheeler, который в 1995 году ограбил два банка. Он это делал даже без маски, т.к. вымазал лицо в лимонном соке и был уверен, что это сделает его невидимым для камер.
Логика? С помощью лимонного сока можно писать невидимый текст на бумаге, значит и человека это тоже сделает невидимым.
Два исследователя так впечатлились этим примером, что провели исследование. Их звали Джастин Крюгер и Дэвид Даннинг, а синдром назвали Эффектом Даннинга — Крюгера: Нас не волнует то, чего мы не знаем.
Если бы это было не так, то люди бы до сих пор сидели на деревьях и боялись спуститься на землю. А вдруг съедят? Но для эволюции имеют значение не те миллионы, которых ожидаемо слопали, а те единицы, которым повезло выжить и оставить потомство.
Какое отношение это имеет к LLM?
LLM - это модели, которые заточены на то, чтобы выдавать наиболее приятные для человека ответы. По смыслу там средняя температура по больнице, главное не вглядываться в детали.
LLM при генерации ответа не волнует, можем ли мы проверить их ответы на ошибки. Языковые модели просто делают свою работу и генерируют правдоподобное полотно текста.
Скажем, новая Llama 4 делала это так приятно, что на LLM Арене заняла второе место после выхода. Правда потом выяснилось, что это просто был тюн под человеческие предпочтения (что говорит многое и про этот релиз Llama 4, и про бенчмарк в целом, и про поведение людей).
В общем, какие выводы?
(1) LLM способны усиливать как человеческий ум, так и человеческую глупость. Второе проще - достаточно выдать ответ в той области, где читающие не являются экспертами. А они и не заметят!
(2) Современные MCP/A2A, как LangChain на стероидах, упрощают интеграцию всевозможных систем c LLM. Поэтому ереси будет встречаться много. А потом срабатывает принцип Альберто Брандолини:
The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.
(3) Если в продукте с LLM под капотом не упоминается слово Accuracy в контексте цифр и доказательств, то это умножитель Даннинга — Крюгера. Бегите.
(4) Хотите, чтобы ответ LLM нравился людям? Попросите отвечать как позитивный подросток с кучей emoji.
Ваш, @llm_under_hood 🤗
На фотографии - McArthur Wheeler, который в 1995 году ограбил два банка. Он это делал даже без маски, т.к. вымазал лицо в лимонном соке и был уверен, что это сделает его невидимым для камер.
Логика? С помощью лимонного сока можно писать невидимый текст на бумаге, значит и человека это тоже сделает невидимым.
Два исследователя так впечатлились этим примером, что провели исследование. Их звали Джастин Крюгер и Дэвид Даннинг, а синдром назвали Эффектом Даннинга — Крюгера: Нас не волнует то, чего мы не знаем.
Если бы это было не так, то люди бы до сих пор сидели на деревьях и боялись спуститься на землю. А вдруг съедят? Но для эволюции имеют значение не те миллионы, которых ожидаемо слопали, а те единицы, которым повезло выжить и оставить потомство.
Какое отношение это имеет к LLM?
LLM - это модели, которые заточены на то, чтобы выдавать наиболее приятные для человека ответы. По смыслу там средняя температура по больнице, главное не вглядываться в детали.
LLM при генерации ответа не волнует, можем ли мы проверить их ответы на ошибки. Языковые модели просто делают свою работу и генерируют правдоподобное полотно текста.
Скажем, новая Llama 4 делала это так приятно, что на LLM Арене заняла второе место после выхода. Правда потом выяснилось, что это просто был тюн под человеческие предпочтения (что говорит многое и про этот релиз Llama 4, и про бенчмарк в целом, и про поведение людей).
В общем, какие выводы?
(1) LLM способны усиливать как человеческий ум, так и человеческую глупость. Второе проще - достаточно выдать ответ в той области, где читающие не являются экспертами. А они и не заметят!
(2) Современные MCP/A2A, как LangChain на стероидах, упрощают интеграцию всевозможных систем c LLM. Поэтому ереси будет встречаться много. А потом срабатывает принцип Альберто Брандолини:
The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it.
(3) Если в продукте с LLM под капотом не упоминается слово Accuracy в контексте цифр и доказательств, то это умножитель Даннинга — Крюгера. Бегите.
(4) Хотите, чтобы ответ LLM нравился людям? Попросите отвечать как позитивный подросток с кучей emoji.
Ваш, @llm_under_hood 🤗
🔥98😁40👍32👏14❤8😢2🤔1🤯1
7 выводов о внедрении AI в бизнес на примерах крупных компаний
TLDR; начинаем со сбора evals
Если кто знает больше всего про то, как внедрять OpenAI в бизнес, так это сама OpenAI. У них есть отчет "AI in the Enterprise" (PDF) про выводы по внедрению AI в 7 очень крупных компаниях.
Самое интересное, на мой взгляд - это их описание парадигмы, которая отличает AI разработку от традиционного софта:
А второе интересное - упор на "Start with evals" в первом выводе по кейсу Morgan Stanley. Начинаем проекты со сбора тестов/бенчмарков для оценки работы моделей.
Отсюда еще следует - если в проекте нельзя просто и быстро протестировать качество системы с LLM под капотом, то следует сильно подумать, стоит ли за такой проект браться.
@sergeykadomsky в комментариях упомянул видео на тему, что разработка систем с LLM под капотом - это reliability engineering, а не capability engineering. Лучше и не скажешь! Video: Building and evaluating AI Agents
Сами выводы (каждый идет с небольшим рассказом о кейсе)
01. Начинайте проект с evals - Morgan Stanley (financial services)
Используйте систематический подход для оценки того, насколько модели соответствуют вашим задачам.
02. Встраивайте AI в свои продукты - Indeed (крупнейший сайт вакансий)
Создавайте новые клиентские сценарии и более персонализированные взаимодействия.
03. Начинайте сейчас и инвестируйте заранее - Klarna (платежная система)
Чем раньше вы начнёте, тем быстрее будет расти отдача от инвестиций.
04. Настраивайте и адаптируйте модели - Lowe’s (home improvement)
Точная настройка моделей под ваши конкретные задачи значительно увеличит их эффективность.
05. Передайте AI в руки экспертов - BBVA (banking)
Люди, непосредственно работающие с процессом, лучше всего смогут улучшить его с помощью AI.
06. Уберите препятствия для разработчиков - Mercado Libre (ecommerce and fintech)
Автоматизация процесса разработки программного обеспечения значительно повысит отдачу от AI.
07. Ставьте амбициозные цели по автоматизации - OpenAI (LLM обучают)
Большинство процессов содержат рутинные задачи, идеально подходящие для автоматизации. Ставьте высокие цели.
Исходный отчет про AI in the Enterprise: PDF
Ваш, @llm_under_hood 🤗
TLDR; начинаем со сбора evals
Если кто знает больше всего про то, как внедрять OpenAI в бизнес, так это сама OpenAI. У них есть отчет "AI in the Enterprise" (PDF) про выводы по внедрению AI в 7 очень крупных компаниях.
Самое интересное, на мой взгляд - это их описание парадигмы, которая отличает AI разработку от традиционного софта:
Использование AI — это не то же самое, что разработка программного обеспечения или развертывание облачных приложений. Наибольшего успеха достигают компании, которые воспринимают AI как новую парадигму. Это ведёт к формированию экспериментального мышления и итеративного подхода, позволяющего быстрее получать результаты и добиваться большей поддержки со стороны пользователей и заинтересованных сторон.
А второе интересное - упор на "Start with evals" в первом выводе по кейсу Morgan Stanley. Начинаем проекты со сбора тестов/бенчмарков для оценки работы моделей.
Отсюда еще следует - если в проекте нельзя просто и быстро протестировать качество системы с LLM под капотом, то следует сильно подумать, стоит ли за такой проект браться.
@sergeykadomsky в комментариях упомянул видео на тему, что разработка систем с LLM под капотом - это reliability engineering, а не capability engineering. Лучше и не скажешь! Video: Building and evaluating AI Agents
Сами выводы (каждый идет с небольшим рассказом о кейсе)
01. Начинайте проект с evals - Morgan Stanley (financial services)
Используйте систематический подход для оценки того, насколько модели соответствуют вашим задачам.
02. Встраивайте AI в свои продукты - Indeed (крупнейший сайт вакансий)
Создавайте новые клиентские сценарии и более персонализированные взаимодействия.
03. Начинайте сейчас и инвестируйте заранее - Klarna (платежная система)
Чем раньше вы начнёте, тем быстрее будет расти отдача от инвестиций.
04. Настраивайте и адаптируйте модели - Lowe’s (home improvement)
Точная настройка моделей под ваши конкретные задачи значительно увеличит их эффективность.
05. Передайте AI в руки экспертов - BBVA (banking)
Люди, непосредственно работающие с процессом, лучше всего смогут улучшить его с помощью AI.
06. Уберите препятствия для разработчиков - Mercado Libre (ecommerce and fintech)
Автоматизация процесса разработки программного обеспечения значительно повысит отдачу от AI.
07. Ставьте амбициозные цели по автоматизации - OpenAI (LLM обучают)
Большинство процессов содержат рутинные задачи, идеально подходящие для автоматизации. Ставьте высокие цели.
Исходный отчет про AI in the Enterprise: PDF
Ваш, @llm_under_hood 🤗
👍59🔥22❤9🤔4🥰3🤗2
Вот это 20 минутное видео я разослал всем командам, которые я курирую в области внедрения AI в бизнес, чтобы они обязательно его посмотрели. YouTube
Я это видео упоминал в прошлом посте, но там оно могло затеряться.
Если кратко, то всякие агенты и прочие архитектуры с LLM под капотом могут очень много. Это обусловливает весь хайп. Достаточно просто сделать на коленке очень классный прототип, который даст правильный ответ на сложный вопрос.
Проблема в том, что бизнесу обычно нужна надежная система, которая будет стабильно давать правильные ответы на сложные вопросы. И разработка такой системы требует совершенно иных подходов. Это уже не capability engineering, а reliability engineering.
Люди, которые работают с распределенными системами знают, что, скажем, очень просто добиться работы серверной системы (аптайма) в 90% или даже 99%. Но требуется совершенно иной инженерный подход для повышения аптайма до 99.999%.
Аналогично и с системами с LLM под капотом. Очень просто сделать чатбота, который сможет правильно ответить на несколько вопросов. Но на порядки сложнее сделать систему, которая будет стабильно корректно отвечать на все разнообразные вопросы пользователей.
Как раз про стабильность систем, способы оценки и рассказывает это видео.
- Evaluating Agents is hard
- Static benchmarks can be misleading
- LLM systems are about reliability engineering, not capability engineering
Очень советую выделить 20 минут времени для его просмотра. Это поможет сэкономить гораздо больше времени на проектах в будущем
https://www.youtube.com/watch?v=d5EltXhbcfA
Ваш, @llm_under_hood 🤗
Я это видео упоминал в прошлом посте, но там оно могло затеряться.
Если кратко, то всякие агенты и прочие архитектуры с LLM под капотом могут очень много. Это обусловливает весь хайп. Достаточно просто сделать на коленке очень классный прототип, который даст правильный ответ на сложный вопрос.
Проблема в том, что бизнесу обычно нужна надежная система, которая будет стабильно давать правильные ответы на сложные вопросы. И разработка такой системы требует совершенно иных подходов. Это уже не capability engineering, а reliability engineering.
Люди, которые работают с распределенными системами знают, что, скажем, очень просто добиться работы серверной системы (аптайма) в 90% или даже 99%. Но требуется совершенно иной инженерный подход для повышения аптайма до 99.999%.
Аналогично и с системами с LLM под капотом. Очень просто сделать чатбота, который сможет правильно ответить на несколько вопросов. Но на порядки сложнее сделать систему, которая будет стабильно корректно отвечать на все разнообразные вопросы пользователей.
Как раз про стабильность систем, способы оценки и рассказывает это видео.
- Evaluating Agents is hard
- Static benchmarks can be misleading
- LLM systems are about reliability engineering, not capability engineering
Очень советую выделить 20 минут времени для его просмотра. Это поможет сэкономить гораздо больше времени на проектах в будущем
https://www.youtube.com/watch?v=d5EltXhbcfA
Ваш, @llm_under_hood 🤗
❤82👍51🔥24🙏4👏1🤣1
Как системно внедрять LLM в бизнес без галлюцинаций? Для engineering leads.
Что делать компании среднего размера, которая попробовала решить несколько проблем при помощи LLM, и результат им понравился. Но сейчас хочется самим внедрять AI для решения других задач. С чего начать и как системно двигаться дальше?
Обычно за этот вопрос отвечает AI R&D департамент, но не у всех компаний он есть в достаточном масштабе. Поэтому вот краткая выжимка советов от стороннего AI R&D отдела [1]
1️⃣ Нужно браться только за бизнес-проблемы, решение которых можно свести к инженерной задаче.
Инженерная задача - когда поиск оптимального решения не зависит от удачи или гениальности архитектора. Удачное решение можно найти методическим перебором вариантов.
Например, Илья победил в Enterprise RAG Challenge r2 “просто” тем, что заранее подготовил тестовый dataset под задачу, методически перебрал варианты пайплайна и использовал наиболее удачный вариант в самом соревновании.
2️⃣ Иногда проблему нужно “покрутить” с разных сторон, чтобы увидеть решение, которое сводится к инженерной задаче.
Например, в компании есть полсотни документов, которые описывают разные SAP процессы. Хочется, чтобы сотрудники могли быстро найти нужный процесс по запросу.
Решение в лоб - загрузить все документы в RAG и задать вопрос в чате - по очевидным причинам у компании “не взлетело”. Иногда ответы правильные, иногда - чушь.
Как быть? А сесть и посмотреть на схожие варианты решений из тех, которые взлетели у других компаний. Выбрать те, для которых можно собрать тестовый dataset с возможностью быстрой оценки.
Какой самый наглядный и близкий пример? Да тот же Enterprise RAG Challenge r2. Поэтому переделываем интерфейс системы из чата - в поисковик. В ответ на запрос пользователя о задаче, система должна найти пару документов, которые содержат ответ, указать на конкретные страницы.
Тестовый dataset - набор запросов пользователей на вход и конкретные страницы, которые нужно найти среди всего этого. Как только его разметим, можно начать перебирать варианты реализации, начиная с того, что попроще и есть под рукой. Начиная с Azure Cognitive Search до Query Expansion и FTS поиска по документам.
3️⃣ Бизнес никогда не будет оглашать весь ассортимент проблем. Они будут озвучивать только те, которые на их взгляд решаются при помощи AI. Чтобы увидеть весь список (и выбрать из него простые задачи) - нужно говорить с бизнесом и экспертами напрямую. Domain-Driven Design и методологии из него в помощь.
4️⃣ Не нужно оптимизировать весь бизнес-процесс целиком. Смотрим на каждый процесс, как на последовательность шагов.
Например, сотрудники маркетинговых отделов собирают все брошюрки местных агенств и выбирают лучшие цены на разные услуги, например печать визиток или флайеров. Хочется, чтобы система могла автоматом проходить по актуальным предложениям и предлагать лучшее из числа доверенных компаний.
Не нужно пытаться делать систему, которая будет “кушать” все PDF и давать ответы на “где будет стоит дешевле распечатать 200 визиток для 10 человек, из них 2 набора на плотной бумаги и с тиснением”. Тут замучаешься как собирать тестовый dataset, так и реализовывать логику с математикой.
Смотрим на процесс в целом и различаем скучную автоматизируемую рутину (mundane) и когнитивно сложные вещи (creative).
Mundane - автоматизировать, Creative - оставить людям.
В данном случае, можно автоматизировать процесс выгрузки всех цен по всем услугам по всем поставщикам в один единственный Excel файл со ссылками. И отдел маркетинга сможет просто искать в нем нужные позиции (по онтологии), сразу видеть цены и условия, а при необходимости и открывать исходные документы для перепроверки.
5️⃣ Обязательно читаем и проникаемся SO / CoT - без этого никуда. Пока его на практике не освоили, ни за какие проекты не беремся. Потом Router + Query Expansion. Logit Bias раскраска - тоже, для вырабатывания интуиции.
Ваш, @llm_under_hood 🤗
[1] Конекст про AI R&D - следующим постом
Что делать компании среднего размера, которая попробовала решить несколько проблем при помощи LLM, и результат им понравился. Но сейчас хочется самим внедрять AI для решения других задач. С чего начать и как системно двигаться дальше?
Обычно за этот вопрос отвечает AI R&D департамент, но не у всех компаний он есть в достаточном масштабе. Поэтому вот краткая выжимка советов от стороннего AI R&D отдела [1]
1️⃣ Нужно браться только за бизнес-проблемы, решение которых можно свести к инженерной задаче.
Инженерная задача - когда поиск оптимального решения не зависит от удачи или гениальности архитектора. Удачное решение можно найти методическим перебором вариантов.
Например, Илья победил в Enterprise RAG Challenge r2 “просто” тем, что заранее подготовил тестовый dataset под задачу, методически перебрал варианты пайплайна и использовал наиболее удачный вариант в самом соревновании.
2️⃣ Иногда проблему нужно “покрутить” с разных сторон, чтобы увидеть решение, которое сводится к инженерной задаче.
Например, в компании есть полсотни документов, которые описывают разные SAP процессы. Хочется, чтобы сотрудники могли быстро найти нужный процесс по запросу.
Решение в лоб - загрузить все документы в RAG и задать вопрос в чате - по очевидным причинам у компании “не взлетело”. Иногда ответы правильные, иногда - чушь.
Как быть? А сесть и посмотреть на схожие варианты решений из тех, которые взлетели у других компаний. Выбрать те, для которых можно собрать тестовый dataset с возможностью быстрой оценки.
Какой самый наглядный и близкий пример? Да тот же Enterprise RAG Challenge r2. Поэтому переделываем интерфейс системы из чата - в поисковик. В ответ на запрос пользователя о задаче, система должна найти пару документов, которые содержат ответ, указать на конкретные страницы.
Тестовый dataset - набор запросов пользователей на вход и конкретные страницы, которые нужно найти среди всего этого. Как только его разметим, можно начать перебирать варианты реализации, начиная с того, что попроще и есть под рукой. Начиная с Azure Cognitive Search до Query Expansion и FTS поиска по документам.
3️⃣ Бизнес никогда не будет оглашать весь ассортимент проблем. Они будут озвучивать только те, которые на их взгляд решаются при помощи AI. Чтобы увидеть весь список (и выбрать из него простые задачи) - нужно говорить с бизнесом и экспертами напрямую. Domain-Driven Design и методологии из него в помощь.
4️⃣ Не нужно оптимизировать весь бизнес-процесс целиком. Смотрим на каждый процесс, как на последовательность шагов.
Например, сотрудники маркетинговых отделов собирают все брошюрки местных агенств и выбирают лучшие цены на разные услуги, например печать визиток или флайеров. Хочется, чтобы система могла автоматом проходить по актуальным предложениям и предлагать лучшее из числа доверенных компаний.
Не нужно пытаться делать систему, которая будет “кушать” все PDF и давать ответы на “где будет стоит дешевле распечатать 200 визиток для 10 человек, из них 2 набора на плотной бумаги и с тиснением”. Тут замучаешься как собирать тестовый dataset, так и реализовывать логику с математикой.
Смотрим на процесс в целом и различаем скучную автоматизируемую рутину (mundane) и когнитивно сложные вещи (creative).
Mundane - автоматизировать, Creative - оставить людям.
В данном случае, можно автоматизировать процесс выгрузки всех цен по всем услугам по всем поставщикам в один единственный Excel файл со ссылками. И отдел маркетинга сможет просто искать в нем нужные позиции (по онтологии), сразу видеть цены и условия, а при необходимости и открывать исходные документы для перепроверки.
5️⃣ Обязательно читаем и проникаемся SO / CoT - без этого никуда. Пока его на практике не освоили, ни за какие проекты не беремся. Потом Router + Query Expansion. Logit Bias раскраска - тоже, для вырабатывания интуиции.
Ваш, @llm_under_hood 🤗
[1] Конекст про AI R&D - следующим постом
🔥74👍41❤6👏6🥰5
История про AI R&D Lab Pass
У меня есть несколько клиентов-компаний, которые внедряют LLM в бизнес в EU/USA. Им хочется иметь доступ к актуальным инсайтам, ресурсам и связям AI R&D отдела, но без затрат времени и денег на создание такого отдела у себя.
По совпадению, я уже веду такой отраслевой AI R&D для бизнеса (Enterprise RAG Challenge, LLM Benchmark или курс по AI Assistants - это все примеры "выхлопа")
Поэтому с некоторыми компаниями мы можем договориться так. В рамках программы Explorer они получают доступ к новым инсайтам из моего отраслевого AI R&D в виде лекций, результатов публичных и приватных бенчмарков и важных новостей. Плюс они могут через меня разместить проблемы в Challenge или стукнуться напрямую к толковым специалистам для найма. Такой вот месячный абонемент в AI-лабораторию по цене одного дня работы внешнего консультанта.
Пост про “Как системно внедрять LLM в бизнес без галлюцинаций?” - это как раз выжимка из последней отгрузки в рамках программы. Я решил поделиться ею после того, как сегодня утром один AI Integration Lead выдал такой отзыв про наболевшее: “Вау, как хорошо, что мы не успели взяться за реализацию чат-бота для помощи по SAP процессам. Потратили бы несколько месяцев впустую. Теперь понятно, что можно сделать проще и быстрее”
Возможно и вам пригодится. А если уж выводы совсем кратко:
(1) осваиваем SO / CoT на практике (о важности чего в данном канале уже не нужно рассказывать)
(2) выбираем только те проблемы и варианты решений, где точность можно измерять при помощи тестовых датасетов. Бенчмарки под задачу - наши лучшие друзья.
(3) Domain-Driven Design и методологии из него - помогут выбрать легко решаемые варианты из всего потенциального набора проблем.
(4) Всегда опираемся на статистику самых успешных паттернов и кейсов в отрасли (см полный список), не повторяем ошибки других команд.
Ваш, @llm_under_hood 🤗
У меня есть несколько клиентов-компаний, которые внедряют LLM в бизнес в EU/USA. Им хочется иметь доступ к актуальным инсайтам, ресурсам и связям AI R&D отдела, но без затрат времени и денег на создание такого отдела у себя.
По совпадению, я уже веду такой отраслевой AI R&D для бизнеса (Enterprise RAG Challenge, LLM Benchmark или курс по AI Assistants - это все примеры "выхлопа")
Поэтому с некоторыми компаниями мы можем договориться так. В рамках программы Explorer они получают доступ к новым инсайтам из моего отраслевого AI R&D в виде лекций, результатов публичных и приватных бенчмарков и важных новостей. Плюс они могут через меня разместить проблемы в Challenge или стукнуться напрямую к толковым специалистам для найма. Такой вот месячный абонемент в AI-лабораторию по цене одного дня работы внешнего консультанта.
Пост про “Как системно внедрять LLM в бизнес без галлюцинаций?” - это как раз выжимка из последней отгрузки в рамках программы. Я решил поделиться ею после того, как сегодня утром один AI Integration Lead выдал такой отзыв про наболевшее: “Вау, как хорошо, что мы не успели взяться за реализацию чат-бота для помощи по SAP процессам. Потратили бы несколько месяцев впустую. Теперь понятно, что можно сделать проще и быстрее”
Возможно и вам пригодится. А если уж выводы совсем кратко:
(1) осваиваем SO / CoT на практике (о важности чего в данном канале уже не нужно рассказывать)
(2) выбираем только те проблемы и варианты решений, где точность можно измерять при помощи тестовых датасетов. Бенчмарки под задачу - наши лучшие друзья.
(3) Domain-Driven Design и методологии из него - помогут выбрать легко решаемые варианты из всего потенциального набора проблем.
(4) Всегда опираемся на статистику самых успешных паттернов и кейсов в отрасли (см полный список), не повторяем ошибки других команд.
Ваш, @llm_under_hood 🤗
❤35🔥22👍12🙏3💯1🤣1
Наш чатбот популярен, но как жить дальше?
Кейс. В одной компании сделали внутреннего чат-бота для крупной организации, он стал популярным, им пользуются каждый день тысячи людей.
Но появился один нюанс - пользователи просят добавлять все больше фич, а архитектура становится все сложнее. Там и работа с разными наборами документов, генерация картинок, интеграция внешних сервисов, возможность раздавать права и делиться работой итп. С каждым месяцем добавляется все больше фич! Сейчас даже прикручивают MCP сервера.
При этом у чат-бота нет нормальных тестов на весь функционал и каждый релиз как лотерея. Просто потому, что фич и сценариев использования так много, что нельзя нормально автоматически оценить качество всех бесед. Да и не понятно, как это делать. Статистика об использовании какая-то собирается, но доступа у команды разработки у ней нет, ибо прода находится в другом контуре безопасности.
А еще, поскольку система гибкая и локальная, то приходится держать GPU на терабайты VRAM для мощных моделей. Счета не радуют.
Как можно двигаться дальше, когда AI прототип понравился, но застрял на уровне игрушки, которую боязно использовать серьезно из-за галлюцинаций? И при этом требует немалых денег.
Сегодня мне понадобилось ровно два часа, чтобы поменять команде этого чат-бота перспективу с "прибыльное, но беспросветное болото" на "уууу, как тут круто можно сделать". Смотрите самое важное.
В “Ринат не делает чат-ботов” я уже описывал возможность попадания в такую ситуацию. Если уж попали, то для движения дальше нужно перевернуть перспективу и пройтись по пунктам из “Как системно внедрять LLM в бизнес без галлюцинаций?”
Достаточно понять, что у нас есть популярный и гибкий инкубатор идей по использованию AI в компании. Люди им пользуются и экспериментируют. Да, он подглючивает, но это не страшно.
Дальше нужно проанализировать те данные, которые у нас уже есть.
Берем историю всех бесед пользователей и смотрим, а какие паттерны использования есть чаще всего? Можно просто прогнать все беседы через классификатор на 100 категорий и посмотреть так.
Потом берем десяток самых популярных паттернов использования и смотрим - на какие из них проще всего собрать тестовый датасет, а само решение превратить в инженерную задачу? Причем у нас есть история всей переписки в данной категории, не нужно будет высасывать тесты нового из пальца. Выкидываем для данного процесса интерфейс чат-бота и получаем специализированный микро-продукт с LLM под капотом.
Заодно можем и оптимизировать промпты под задачу и переключить на модели попроще. У нас же есть тестовый датасет, поэтому тут можно механически перебрать варианты.
Продукт можно выкатить на той же платформе или просто классифицировать запросы пользователей и совпадающие направлять из чата в него.
А теперь смотрим внимательно на финт ушами. Мы взяли самый популярный паттерн использования. Он популярный, а значит - давал много нагрузки на большие модели. И теперь эта вся нагрузка уйдет на специализированный продукт, который использует оптимизированные промпты и модели. Так мы не только сделали фичу более надежной для широкого выкатывания, но и оптимизировали общую загрузку и порезали косты.
Сделали? Заново смотрим на остальные запросы пользователей в истории переписок и выделяем следующий паттерн. А чат-бот можно оставить экспериментальной площадкой для всех новых идей.
Самое интересное, что эта стратегия ложится на существующую концепцию Innovation Incubator, поэтому можно переиспользовать процессы и методологии для организации работы (data-driven product development + lean startups).
А вам приходилось встречать подобные ситуации?
Ваш, @llm_under_hood 🤗
Кейс. В одной компании сделали внутреннего чат-бота для крупной организации, он стал популярным, им пользуются каждый день тысячи людей.
Но появился один нюанс - пользователи просят добавлять все больше фич, а архитектура становится все сложнее. Там и работа с разными наборами документов, генерация картинок, интеграция внешних сервисов, возможность раздавать права и делиться работой итп. С каждым месяцем добавляется все больше фич! Сейчас даже прикручивают MCP сервера.
При этом у чат-бота нет нормальных тестов на весь функционал и каждый релиз как лотерея. Просто потому, что фич и сценариев использования так много, что нельзя нормально автоматически оценить качество всех бесед. Да и не понятно, как это делать. Статистика об использовании какая-то собирается, но доступа у команды разработки у ней нет, ибо прода находится в другом контуре безопасности.
А еще, поскольку система гибкая и локальная, то приходится держать GPU на терабайты VRAM для мощных моделей. Счета не радуют.
Как можно двигаться дальше, когда AI прототип понравился, но застрял на уровне игрушки, которую боязно использовать серьезно из-за галлюцинаций? И при этом требует немалых денег.
Сегодня мне понадобилось ровно два часа, чтобы поменять команде этого чат-бота перспективу с "прибыльное, но беспросветное болото" на "уууу, как тут круто можно сделать". Смотрите самое важное.
В “Ринат не делает чат-ботов” я уже описывал возможность попадания в такую ситуацию. Если уж попали, то для движения дальше нужно перевернуть перспективу и пройтись по пунктам из “Как системно внедрять LLM в бизнес без галлюцинаций?”
Достаточно понять, что у нас есть популярный и гибкий инкубатор идей по использованию AI в компании. Люди им пользуются и экспериментируют. Да, он подглючивает, но это не страшно.
Дальше нужно проанализировать те данные, которые у нас уже есть.
Берем историю всех бесед пользователей и смотрим, а какие паттерны использования есть чаще всего? Можно просто прогнать все беседы через классификатор на 100 категорий и посмотреть так.
Потом берем десяток самых популярных паттернов использования и смотрим - на какие из них проще всего собрать тестовый датасет, а само решение превратить в инженерную задачу? Причем у нас есть история всей переписки в данной категории, не нужно будет высасывать тесты нового из пальца. Выкидываем для данного процесса интерфейс чат-бота и получаем специализированный микро-продукт с LLM под капотом.
Заодно можем и оптимизировать промпты под задачу и переключить на модели попроще. У нас же есть тестовый датасет, поэтому тут можно механически перебрать варианты.
Продукт можно выкатить на той же платформе или просто классифицировать запросы пользователей и совпадающие направлять из чата в него.
А теперь смотрим внимательно на финт ушами. Мы взяли самый популярный паттерн использования. Он популярный, а значит - давал много нагрузки на большие модели. И теперь эта вся нагрузка уйдет на специализированный продукт, который использует оптимизированные промпты и модели. Так мы не только сделали фичу более надежной для широкого выкатывания, но и оптимизировали общую загрузку и порезали косты.
Сделали? Заново смотрим на остальные запросы пользователей в истории переписок и выделяем следующий паттерн. А чат-бот можно оставить экспериментальной площадкой для всех новых идей.
Самое интересное, что эта стратегия ложится на существующую концепцию Innovation Incubator, поэтому можно переиспользовать процессы и методологии для организации работы (data-driven product development + lean startups).
А вам приходилось встречать подобные ситуации?
Ваш, @llm_under_hood 🤗
❤98🔥46👍14🤯14🥰4👏4🤔1🙏1🤗1
Новые LLM в reasoning бенчмарке на бизнес-задачах
- o3-mini и o4-mini очень хороши
- gemini flash preview в thinking режиме заняла третье место
- версии gpt-4.1 (базовая и мини) достаточно хороши, чтобы их использовать из коробки вместо 4o.
OpenAI продолжает лидировать, но Google прямо последовательно дышит в спину. А если учитывать, что OpenAI зависит от NVidia + Microsoft, а Google обучает на своих TPU процессорах, то будущее прямо интересно.
Плюс Google, в отличие от OpenAI, периодически выкладывает открытые модели для использования. За них стоит поболеть отдельно.
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
PPS: А прямо сейчас у меня открыто окно SAP и я выстраиваю reasoning workflow агента для автоматического заполнения Purchase Orders в соответствии с внутренними требованиями компаниями. И шаги из этого процесса пойдут в RPA колонку данного бенчмарка.
- o3-mini и o4-mini очень хороши
- gemini flash preview в thinking режиме заняла третье место
- версии gpt-4.1 (базовая и мини) достаточно хороши, чтобы их использовать из коробки вместо 4o.
OpenAI продолжает лидировать, но Google прямо последовательно дышит в спину. А если учитывать, что OpenAI зависит от NVidia + Microsoft, а Google обучает на своих TPU процессорах, то будущее прямо интересно.
Плюс Google, в отличие от OpenAI, периодически выкладывает открытые модели для использования. За них стоит поболеть отдельно.
Ваш, @llm_under_hood 🤗
PS: Прочитать про мой подход к бенчмаркам можно тут. Там есть и FAQ со всеми вопросами, которые задают последние полтора года. Пожалуйста, прочитайте его, прежде чем оставлять свой первый комментарий.
PPS: А прямо сейчас у меня открыто окно SAP и я выстраиваю reasoning workflow агента для автоматического заполнения Purchase Orders в соответствии с внутренними требованиями компаниями. И шаги из этого процесса пойдут в RPA колонку данного бенчмарка.
❤40🔥23👍14🤯2
Простой пример, почему не так просто добиться стабильной работы агентов/операторов на практике.
Смотрите на вот эту тестовую картинку. Задача у VLM на данном этапе плана - найти место на экране, куда нужно "ткнуть" мышкой, чтобы заполнить поле Lieferant.
NB: Я в курсе про BAPI PO_CREATE1 / SAP Fiori / SAPUI5 / итп. Тут дело не в этом.
Казалось бы просто - отправили в VLM и попросили. Так вот, даже GPT-4o начинает мазать и кликать не под текстом "Lieferant" а направо от него. Почему? ChatGPT объясняется так:
The mistake wasn't laziness, it was bias to SAP defaults + time pressure + separated information.
bias в данном случае можно перевести как "грабли", которые срабатывают внезапно и время от времени. Хотя любой студент без проблем ткнет мышкой не справа от текста, а в текстовое поле под ним.
Что делать в данном случае? См пост про системное внедрение LLM без галлюцинаций. Нужно крутить проблему до посинения, пока не получится решение, которое сводится не к игре в рулетку, а к инженерной задаче и возможности верифицировать качество каждого шага.
Ваш, @llm_under_hood 🤗
PS: А задача в итоге сводится к подобию того, что я описывал в истории разработки своего reasoning.
Смотрите на вот эту тестовую картинку. Задача у VLM на данном этапе плана - найти место на экране, куда нужно "ткнуть" мышкой, чтобы заполнить поле Lieferant.
NB: Я в курсе про BAPI PO_CREATE1 / SAP Fiori / SAPUI5 / итп. Тут дело не в этом.
Казалось бы просто - отправили в VLM и попросили. Так вот, даже GPT-4o начинает мазать и кликать не под текстом "Lieferant" а направо от него. Почему? ChatGPT объясняется так:
The mistake wasn't laziness, it was bias to SAP defaults + time pressure + separated information.
bias в данном случае можно перевести как "грабли", которые срабатывают внезапно и время от времени. Хотя любой студент без проблем ткнет мышкой не справа от текста, а в текстовое поле под ним.
Что делать в данном случае? См пост про системное внедрение LLM без галлюцинаций. Нужно крутить проблему до посинения, пока не получится решение, которое сводится не к игре в рулетку, а к инженерной задаче и возможности верифицировать качество каждого шага.
Ваш, @llm_under_hood 🤗
PS: А задача в итоге сводится к подобию того, что я описывал в истории разработки своего reasoning.
🔥26🤔10👍9❤6🙏1
Когда говорят про AI Coding, люди делятся на два лагеря:
Одни говорят, что вайб кодинг - это невероятно круто. Что Cursor/Windsurf перевернул всю картину мира, их агенты сами пишут код и перетасовывают файлы как надо, а написанные приложения зарабатывают кучу денег.
Другие говорят, что результат работы этих всех агентов - полная ерунда, код с кучей проблем, а все, кто говорят иначе - сами не умеют программировать.
На самом деле лагерей и оттенков гораздо больше, но на поверхность всплывают только яркие и эмоциональные истории. Они не очень конструктивны, но вызывают реакции и желание ими поделиться.
А ведь, если задуматься, все эти AI Coding инструменты - это просто инструменты. Они как молоток. Можно гвозди забивать, можно попадать по пальцам. А при наличии таланта - сломать сам молоток.
Вот простой пример из AI Coding эксперимента для компании (история тут).
Я дал студентам (роли Senior / Lead) задание, которое можно было выполнить любым способом (скриншот иллюстрации интерфейса будет в комментариях):
Самый быстрый результат до рабочего решения был 30 минут с Claude, которому студент дал доступ к Powershell, папке с кодом и чему-то еще. Остальные варианты с агентскими средами заняли больше времени (до двух часов) из-за того, что за ними нужно было постоянно присматривать. Tokens при этом они использовали заметное количество.
Хорошо размялись. Потом мы обсудили результаты, и я дал основное задание:
Студенты пока работают над заданием. У меня же получился промпт на 432 tokens/1833 characters (GPT-4o tokenizer). Он работает стабильно на разных моделях, примеры скриншотов интерфейсов, которые он накодил - приведу в комментарии.
А вы сможете написать такой промпт? Если решите попробовать, засекайте время от начала задания (отсечка на 2 часа), кидайте в чат скриншот финального приложения и количество tokens/characters в промпте, который его накодил.
Если не получилось - тоже пишите. В упражнениях с молотками важнее попытка и практика, нежели результат с первого раза.
Ваш, @llm_under_hood 🤗
PS: Пока самый компактный промпт занимает всего 298 символов и работает стабильно на Claude 3.7. Я потом напишу отдельно пост.
Одни говорят, что вайб кодинг - это невероятно круто. Что Cursor/Windsurf перевернул всю картину мира, их агенты сами пишут код и перетасовывают файлы как надо, а написанные приложения зарабатывают кучу денег.
Другие говорят, что результат работы этих всех агентов - полная ерунда, код с кучей проблем, а все, кто говорят иначе - сами не умеют программировать.
На самом деле лагерей и оттенков гораздо больше, но на поверхность всплывают только яркие и эмоциональные истории. Они не очень конструктивны, но вызывают реакции и желание ими поделиться.
А ведь, если задуматься, все эти AI Coding инструменты - это просто инструменты. Они как молоток. Можно гвозди забивать, можно попадать по пальцам. А при наличии таланта - сломать сам молоток.
Вот простой пример из AI Coding эксперимента для компании (история тут).
Я дал студентам (роли Senior / Lead) задание, которое можно было выполнить любым способом (скриншот иллюстрации интерфейса будет в комментариях):
Реализуйте инструмент с веб-интерфейсом, который сможет отправлять запросы в выбранную вами LLM-модель, добавляя при этом содержимое выбранных файлов к тексту запроса (prompt). Пользователь должен иметь возможность выбирать файлы, которые необходимо добавить к запросу.
Требования:
* Инструмент при запуске получает аргументом путь к директории (например: `node server.js ../../projects/demo-project`)
* При загрузке страницы все файлы из этой директории (рекурсивно) отображаются в левой панели
* При нажатии пользователя на файл он добавляется в правую панель
* При нажатии пользователя на файл в правой панели, он удаляется из неё
* После того, как пользователь вводит prompt и нажимает на кнопку «Submit», содержимое выбранных файлов добавляется к запросу и отправляется в LLM
* Ответ от LLM отображается на экране
Не требуется:
* Поддержка многошаговых диалогов или уточняющих вопросов.
* Сохранение какого-либо состояния. При перезагрузке страницы вся информация может быть потеряна.
Самый быстрый результат до рабочего решения был 30 минут с Claude, которому студент дал доступ к Powershell, папке с кодом и чему-то еще. Остальные варианты с агентскими средами заняли больше времени (до двух часов) из-за того, что за ними нужно было постоянно присматривать. Tokens при этом они использовали заметное количество.
Хорошо размялись. Потом мы обсудили результаты, и я дал основное задание:
А что, если я скажу, что все эти агенты не очень-то нужны в данном задании? Что можно получить аналогичный результат используя обычный чат?
Напишите мне такой промпт, который можно вставить в чат ChatGPT/Claude/Google, который сразу напишет работающий код. Чем меньше промпт, тем лучше.
Подсказка 1: "think bigger"
Подсказка 2: это задание делается за 5-15 минут.
Студенты пока работают над заданием. У меня же получился промпт на 432 tokens/1833 characters (GPT-4o tokenizer). Он работает стабильно на разных моделях, примеры скриншотов интерфейсов, которые он накодил - приведу в комментарии.
А вы сможете написать такой промпт? Если решите попробовать, засекайте время от начала задания (отсечка на 2 часа), кидайте в чат скриншот финального приложения и количество tokens/characters в промпте, который его накодил.
Если не получилось - тоже пишите. В упражнениях с молотками важнее попытка и практика, нежели результат с первого раза.
Ваш, @llm_under_hood 🤗
PS: Пока самый компактный промпт занимает всего 298 символов и работает стабильно на Claude 3.7. Я потом напишу отдельно пост.
🔥91❤26👍21😁1