Вот это 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❤7👏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
Как одним промптом решить задачу, которую AI coding агенты будут пилить 30-90 минут?
Вот примеры промптов, которые решают упражнение из предыдущего поста, где надо было написать утилиту для удобного выбора и "склеивания" файлов перед отправкой в OpenAI API.
Напомню, что когда я дал эту задачу ребятам из экспериментальной группы по AI Coding, они потратили на нее 30-120 минут используя всякие новомодные Coding Agents и IDEшки. А потом, когда я объяснил, что задача решается за 5-15 минут одним запросом к обычному чату, уже подошли к задаче осознаннее.
Мой вариант - 73 tokens / 322 chars:
Участник экспериментальной группы - 24 tokens and 99 characters (промпт пока не прислал)
@xsl77 - 27 tokens / 132 chars:
А теперь, самое важное. Задачка была просто для тренировки, чтобы прочувствовать пределы и возможности LLM на практике. Чтобы понять, насколько легко сложные инструменты могут создать иллюзию продуктивной работы (по паре часов возни с Windsurf / Cursor.sh у участников), когда задача решается одним промптом в Claude 3.7 Sonnet (или аналоге).
На практике не имеет никакого смысла каждый раз упражняться в знании английского и паковать требования в крохотный малопонятный текст. Достаточно просто осознанно подбирать инструменты под задачу.
Ваш, @llm_under_hood 🤗
PS: А самое забавное, что в моем промпте я забыл уточнить, что приложение должно быть на web. Поэтому Claude 3.7 с первой попытки сделало работающее десктопное приложение на electron. Скриншот в комментариях.
Вот примеры промптов, которые решают упражнение из предыдущего поста, где надо было написать утилиту для удобного выбора и "склеивания" файлов перед отправкой в OpenAI API.
Напомню, что когда я дал эту задачу ребятам из экспериментальной группы по AI Coding, они потратили на нее 30-120 минут используя всякие новомодные Coding Agents и IDEшки. А потом, когда я объяснил, что задача решается за 5-15 минут одним запросом к обычному чату, уже подошли к задаче осознаннее.
Мой вариант - 73 tokens / 322 chars:
node.js application:
- recursively list all files from a directory, passed as CLI argument
- let user add/remove files to include in LLM prompt
- submits user prompt plus file contents prefixed by filenames to gpt-4o
- displays response
UI: left pane with file tree, right pane: prompt, selected files, “Submit”, response
Участник экспериментальной группы - 24 tokens and 99 characters (промпт пока не прислал)
@xsl77 - 27 tokens / 132 chars:
Nodejs web app showing dir (command line param) files tree users select deselect, OpenAI response for prompt input and file contents
А теперь, самое важное. Задачка была просто для тренировки, чтобы прочувствовать пределы и возможности LLM на практике. Чтобы понять, насколько легко сложные инструменты могут создать иллюзию продуктивной работы (по паре часов возни с Windsurf / Cursor.sh у участников), когда задача решается одним промптом в Claude 3.7 Sonnet (или аналоге).
На практике не имеет никакого смысла каждый раз упражняться в знании английского и паковать требования в крохотный малопонятный текст. Достаточно просто осознанно подбирать инструменты под задачу.
Ваш, @llm_under_hood 🤗
PS: А самое забавное, что в моем промпте я забыл уточнить, что приложение должно быть на web. Поэтому Claude 3.7 с первой попытки сделало работающее десктопное приложение на electron. Скриншот в комментариях.
❤75🔥25👍19🤣5
Сегодня каналу LLM под капотом исполняется два года!
За это время мы сделали много всего интересного.
Разобрали кучу кейсов, научились применять SO CoT, запустили один курс, провели дюжину вебинаров и два крутых раунда Enterprise RAG Challenge (ERC).
Во втором раунде приняло участие 350 команд со всего мира и один директор от AI из Intel. В IBM и паре других компаний до сих пор обсуждают результаты ERC и хвалят материалы. Их даже отметил LangChain (195k подписчиков), пару дней назад опубликовав ссылку на GitHub-решение Ильи по ERCr2.
Благодаря нашему комьюнити кто-то нашёл новую работу и запустил интересные проекты, кто-то познакомился с талантливыми сотрудниками и единомышленниками, а в описаниях вакансий стало появляться умение применять Structured Outputs.
Огромное вам спасибо за поддержку, ваши вопросы, советы и живые обсуждения. Именно вы делаете канал особенным и полезным для многих!
Расскажите, что лично вам запомнилось или чем был полезен канал за эти два года!
Ваш, @llm_under_hood 🥳
За это время мы сделали много всего интересного.
Разобрали кучу кейсов, научились применять SO CoT, запустили один курс, провели дюжину вебинаров и два крутых раунда Enterprise RAG Challenge (ERC).
Во втором раунде приняло участие 350 команд со всего мира и один директор от AI из Intel. В IBM и паре других компаний до сих пор обсуждают результаты ERC и хвалят материалы. Их даже отметил LangChain (195k подписчиков), пару дней назад опубликовав ссылку на GitHub-решение Ильи по ERCr2.
Благодаря нашему комьюнити кто-то нашёл новую работу и запустил интересные проекты, кто-то познакомился с талантливыми сотрудниками и единомышленниками, а в описаниях вакансий стало появляться умение применять Structured Outputs.
Огромное вам спасибо за поддержку, ваши вопросы, советы и живые обсуждения. Именно вы делаете канал особенным и полезным для многих!
Расскажите, что лично вам запомнилось или чем был полезен канал за эти два года!
Ваш, @llm_under_hood 🥳
🔥185🎉74❤34👍16👏5
Третье упражнение AI Coding эксперимента - добавим красоты в презентации и посты
- первое упражнение / вариант решения
- второе упражнение / варианты решения
Это упражнение вдохновлено промптом, который Валерий опубликовал у себя в канале.
Задача - написать промпт, который будет по запросу рисовать красивые слайды в едином стиле компании или бренда. Эту красоту потом можно вставлять в посты, сообщения или презентации.
Стиль вы выбираете сами. Можно попросить переиспользовать дизайн OpenAI / Google / Apple или скормить приятный вам сайт/ресурс.
Получившийся промпт нужно вставить в Claude Project, ChatGPT Project или любой другой инструмент, который позволяет удобно переиспользовать шаблон промпта и отображать результат на экране.
Тут не стоит задачи сделать красивую картинку с первого раза. Задача - попробовать с нуля “собрать” простейший инструмент со своим стилем, который за пару минут может сгенерировать симпатичную иллюстрацию к вашему рассказу или посту. А рецепт создания слайдов потом можно будет неспеша “подкрутить” под свой стиль.
Потом нужно этим инструментом сгенерировать пару слайдов и прислать их в комментарии. Я туда выложу пару слайдов, которые сгенерировал на основе стиля TAT.
Ваш, @llm_under_hood 🤗
- первое упражнение / вариант решения
- второе упражнение / варианты решения
Это упражнение вдохновлено промптом, который Валерий опубликовал у себя в канале.
Задача - написать промпт, который будет по запросу рисовать красивые слайды в едином стиле компании или бренда. Эту красоту потом можно вставлять в посты, сообщения или презентации.
Стиль вы выбираете сами. Можно попросить переиспользовать дизайн OpenAI / Google / Apple или скормить приятный вам сайт/ресурс.
Получившийся промпт нужно вставить в Claude Project, ChatGPT Project или любой другой инструмент, который позволяет удобно переиспользовать шаблон промпта и отображать результат на экране.
Тут не стоит задачи сделать красивую картинку с первого раза. Задача - попробовать с нуля “собрать” простейший инструмент со своим стилем, который за пару минут может сгенерировать симпатичную иллюстрацию к вашему рассказу или посту. А рецепт создания слайдов потом можно будет неспеша “подкрутить” под свой стиль.
Потом нужно этим инструментом сгенерировать пару слайдов и прислать их в комментарии. Я туда выложу пару слайдов, которые сгенерировал на основе стиля TAT.
Ваш, @llm_under_hood 🤗
🔥26👍16❤11
Забавный кейс про 700000 строчек дремучего кода
Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.
Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.
Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.
Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.
Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.
Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?
И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).
Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.
Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.
Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.
А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.
Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.
В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.
Ваш, @llm_under_hood 🤗
Я давно не рассказывал про новые кейсы, т.к. проекты в основном встречаются повторяющиеся. В основном это data extraction - извлечение данных из PDF data sheets, purchase orders (с последующей сверкой или интеграцией). Иногда встречается какой-нибудь интересный поиск по документам.
Но вот появился принципиально новый интересный кейс применения LLM. На самом деле, он старый, но я лично с подобными масштабами не сталкивался.
Итак, есть одна компания, которой больше 100 лет. У нее есть своя самописная ERP система. Это система будет помоложе компании, и она написана на языке разработки бизнес-приложений со времен мейнфреймов, которому уже более 40 лет (для сравнения, 1C - моложе). БД в этой среде своя - проприетарная, интерфейс - терминал 80x25. Кода там - 700000 строчек, преимущественно CRUD и бизнес-логика рядом.
Это не IBM AS/400 с DB2, но что-то очень близкое по духу. Но и тут нужно платить дорогие лицензии, а разработчиков найти практически невозможно.
Компания хочет обновить код на что-то посовременнее. Не ради современности, а для того, чтобы были живые разработчики, которых можно нанять. Заодно клиент хочет еще и интерфейс сделать современным, но так, чтобы все горячие клавиши и последовательности символов работали, как раньше.
Соответственно, возник вопрос в системной оценке проекта - можно ли здесь как-нибудь ускорить процесс переписывания при помощи LLM, как вообще подходить к проекту, какие риски могут быть, как их лучше “вскрыть” пораньше?
И если начать копать, то получается интересная картина. В этой формулировке проекта компания смешала две разные задачи в одну кучу. И лучше бы их разделить, чтобы не умножать риски сверх нужды (я видел проекты, которые на этом погорели).
Первая задача - модернизация кода и перенос ERP системы с дремучего языка на JVM, без изменения терминального интерфейса. Функционал остается тот же самый, просто код читаем и не нужно платить адские суммы в год за лицензии.
Вторая задача - берем портированный и вычищенный код и уже свежими силами переписываем терминальный интерфейс на более “красивый” со всяким React/Desktop итп.
Так вот, в такой формулировке меньше всего рисков в первой части, т.к. можно использовать современные модели для ускорения анализа и переноса (Gemini Pro 2.5 очень удачно вышел). Но, самое главное - scope проекта: чтобы все работало точно так же, как и раньше, но только в браузере или в современном терминале.
А у терминальных приложений есть одна приятная черта - их достаточно просто протестировать на работу “точно так же”. Сажаем эксперта за оригинальное приложение, делаем snapshot БД и просим его реализовать какой-то сценарий работы. В процессе записываем каждую нажатую клавишу и состояние буфера экрана. Потом берем новый код, который портировали полуавтоматическим методом, прогоняем те же клавиши и сравниваем экран терминала с эталоном после каждого шага. Если нет совпадения на 100%, значит что-то упустили.
Вторая задача - это уже обычная разработка (там можно использовать обычный инструментарий из AI Coding, но это не принципиально). Тут уже куча рисков, т.к. надо придумывать новый UI, писать под него тесты, отлаживать итп. Тут не просто механическое портирование кода, а думать надо. Но это типичная задача по разработке на достаточно современном языке программирования, ее решение известно. И этим можно заняться после первой задачи.
В общем, получается довольно забавный кейс, где использование LLM/AI - это не самоцель, а просто один из инструментов, который можно достаточно удобно вписать в картинку проекта на системном уровне. Можно даже обойтись и без него, но уж больно людей жалко.
Ваш, @llm_under_hood 🤗
🔥69👍35🤩24❤16😁4💯1
Стоит ли делиться секретами разработки LLM систем с другими?
Когда-то меня спросили:
Все просто. Знания - это ценный ресурс. Они могут транслироваться в конкретную выгоду.
Скажем, если вовремя подсказать команде разработчиков правильный путь или подсветить потенциальные грабли, то можно сэкономить месяцы работы. А это не только финансовые затраты (часовая ставка * размер команды * пара месяцев), но и банально экономия того самого горячего времени, когда нужно ковать.
Знания можно набирать через опыт, исследования и практику, что тратит время. Может получиться так, что необходимо крутиться как белка в колесе только для того, чтобы быть в курсе основных вещей. Причем, если не крутиться, то может выйти так, что знания устаревают быстрее, чем их набираешь.
Чтобы не было такой печальной картины, мы можем использовать другую перспективу: Знания - это ценный ресурс, который должен работать. Их можно вкладывать!
Например, делиться инсайтами по тому, как быстрее и и проще реализовать бизнес-проекты с LLM под капотом. Или какие типы проектов выбирать, чтобы минимизировать риски и повысить отдачу. Рассказывать про SO CoT, тестирование систем и потенциальные проблемы с агентами и чат-ботами.
Это будет создавать среду, куда люди и компании приходят, узнавать новые вещи или закрепить уже услышанное. Некоторые будут даже обмениваться знаниями, приносить свои кейсы, или проблемы. Наш с вами чат, комьюнити наших курсов, группы близких по духу каналов - это как раз источники такой новой информации.
Если все эти разрозненные кусочки информации собирать и структурировать, то из этого будет рождаться уже действительно интересные инсайты и паттерны.
А ведь дальше можно сделать еще больше:
(1) организовывать публичные исследования вроде нашего Enterprise RAG Challenge или пулить ресурсы от нескольких компаний и запускать небольшие R&D проекты с лучшими специалистами по профилю.
(2) системно дополнять информацию о практике разработки систем с LLM под капотом информацией из других необходимых областей.
Когда мы в этом году проводили AI for Good инкубатор Мальты, то я думал, что стартапам будет больше всего нужна помощь с AI/LLM технологиями. Открыл материалы курса, приготовился вдумчиво консультировать.
А потом, когда начали работать со стартапами, то выяснилось, что техническая экспертиза у них уже хорошо закрыта общей насмотренностью и материалами курса. Времени было всего несколько месяцев, и полезнее всего было потратить его на воркшопы в смежных с AI областях - по разработке продуктовой стратегии для AI стартапов, коммуникациям, организации работы над продуктом, общению с инвесторами, выходу на рынок Европы, - и тому подобное.
В итоге мы вложили больше времени на отработку презентаций и навыков питчинга клиентам и инвесторам, нежели на техническую часть с AI/LLM.
В общем, практические знания о разработке систем с LLM под капотом - это ценный ресурс. Но они сами по себе - капля в море. Я считаю, что если над ними трястись и ничего с ними не делать - они просто устареют и растворятся. Куда лучше, если знания будут постоянно вкладываться, дополняться и двигать реальные проекты.
Cталкивались ли вы с ситуациями, когда распространение знаний помогло вам или вашей команде? Или, может быть, вы наоборот считаете, что открытость вредит конкурентным преимуществам?
Ваш, @llm_under_hood 🤗
Когда-то меня спросили:
Ринат, а стоит ли делиться инсайтами о проектах с LLM под капотом? Ведь тогда все это узнают, и ты уже будешь не нужен.
Все просто. Знания - это ценный ресурс. Они могут транслироваться в конкретную выгоду.
Скажем, если вовремя подсказать команде разработчиков правильный путь или подсветить потенциальные грабли, то можно сэкономить месяцы работы. А это не только финансовые затраты (часовая ставка * размер команды * пара месяцев), но и банально экономия того самого горячего времени, когда нужно ковать.
Знания можно набирать через опыт, исследования и практику, что тратит время. Может получиться так, что необходимо крутиться как белка в колесе только для того, чтобы быть в курсе основных вещей. Причем, если не крутиться, то может выйти так, что знания устаревают быстрее, чем их набираешь.
Чтобы не было такой печальной картины, мы можем использовать другую перспективу: Знания - это ценный ресурс, который должен работать. Их можно вкладывать!
Например, делиться инсайтами по тому, как быстрее и и проще реализовать бизнес-проекты с LLM под капотом. Или какие типы проектов выбирать, чтобы минимизировать риски и повысить отдачу. Рассказывать про SO CoT, тестирование систем и потенциальные проблемы с агентами и чат-ботами.
Это будет создавать среду, куда люди и компании приходят, узнавать новые вещи или закрепить уже услышанное. Некоторые будут даже обмениваться знаниями, приносить свои кейсы, или проблемы. Наш с вами чат, комьюнити наших курсов, группы близких по духу каналов - это как раз источники такой новой информации.
Если все эти разрозненные кусочки информации собирать и структурировать, то из этого будет рождаться уже действительно интересные инсайты и паттерны.
А ведь дальше можно сделать еще больше:
(1) организовывать публичные исследования вроде нашего Enterprise RAG Challenge или пулить ресурсы от нескольких компаний и запускать небольшие R&D проекты с лучшими специалистами по профилю.
(2) системно дополнять информацию о практике разработки систем с LLM под капотом информацией из других необходимых областей.
Когда мы в этом году проводили AI for Good инкубатор Мальты, то я думал, что стартапам будет больше всего нужна помощь с AI/LLM технологиями. Открыл материалы курса, приготовился вдумчиво консультировать.
А потом, когда начали работать со стартапами, то выяснилось, что техническая экспертиза у них уже хорошо закрыта общей насмотренностью и материалами курса. Времени было всего несколько месяцев, и полезнее всего было потратить его на воркшопы в смежных с AI областях - по разработке продуктовой стратегии для AI стартапов, коммуникациям, организации работы над продуктом, общению с инвесторами, выходу на рынок Европы, - и тому подобное.
В итоге мы вложили больше времени на отработку презентаций и навыков питчинга клиентам и инвесторам, нежели на техническую часть с AI/LLM.
В общем, практические знания о разработке систем с LLM под капотом - это ценный ресурс. Но они сами по себе - капля в море. Я считаю, что если над ними трястись и ничего с ними не делать - они просто устареют и растворятся. Куда лучше, если знания будут постоянно вкладываться, дополняться и двигать реальные проекты.
Cталкивались ли вы с ситуациями, когда распространение знаний помогло вам или вашей команде? Или, может быть, вы наоборот считаете, что открытость вредит конкурентным преимуществам?
Ваш, @llm_under_hood 🤗
🤝72🔥48👍26❤19🥰6🤗5🤯4😱1💯1
OpenAI Codex - по ощущениям похоже на Deep Research в своих проектах
Подключаешь к Github, даешь доступ к проекту и запускаешь задачи. И оно что-то там крутит и копошится, примерно как o1 pro / Deep Research. Только вместо поиска в сети оно работает с кодом в контейнере - запускает утилиты и пытается прогонять тесты (если они есть). Цепочку рассуждений можно проверить.
По результатам - создает Pull Request с изменениями, который можно просмотреть и отправить обратно в Github.
Потенциально выглядит весьма интересно. Deep Research и планировщику OpenAI я доверяю. А тут прямо можно поставить в очередь ряд задач и переключиться на другие дела.
А как это в сравнении с Cursor.sh?
Как говорят люди, это аналогично по качеству Cursor + Gemini 2.5-pro. Но возможность удобно и легко запускать параллельные задачи - это что-то новое (перевод цитаты с HN):
Ваш, @llm_under_hood 🤗
Подключаешь к Github, даешь доступ к проекту и запускаешь задачи. И оно что-то там крутит и копошится, примерно как o1 pro / Deep Research. Только вместо поиска в сети оно работает с кодом в контейнере - запускает утилиты и пытается прогонять тесты (если они есть). Цепочку рассуждений можно проверить.
По результатам - создает Pull Request с изменениями, который можно просмотреть и отправить обратно в Github.
Потенциально выглядит весьма интересно. Deep Research и планировщику OpenAI я доверяю. А тут прямо можно поставить в очередь ряд задач и переключиться на другие дела.
А как это в сравнении с Cursor.sh?
Как говорят люди, это аналогично по качеству Cursor + Gemini 2.5-pro. Но возможность удобно и легко запускать параллельные задачи - это что-то новое (перевод цитаты с HN):
По ощущениям, это словно младший инженер на стероидах: достаточно указать файл или функцию и описать необходимое изменение, после чего модель подготовит основную структуру пул-реквеста. Всё равно приходится делать много работы, чтобы довести результат до продакшн-уровня, однако теперь у вас как будто в распоряжении бесконечное число младших разработчиков, каждый из которых занимается своей задачей.
Ваш, @llm_under_hood 🤗
❤66👍23🔥5🥰5🤯1🤣1
Проваливается ли Apple в гонке за AI?
@techsparks перепостил заметку, с которой я категорически не согласен:
Нет. Наоборот, Apple, как никто другой понимает важность выпуска стабильного и надежного продукта.
С AI можно такие продукты делать, но (если качество результата важно) это занимает очень много времени. Тестирование, работа с галлюцинациями и стабилизация AI пайплайнов требуют больше усилий, чем кажется. Apple недооценила объем работ, бывает.
И я восхищаюсь их выдержкой. Вместо того, чтобы выкатывать сырой продукт, они сорвали сроки и взяли время на доделку.
Это скорее свидетельствует о том, что они серьезно подходят к продукту и будут стремиться выдерживать планку качества. Всем бы так подходить к продуктам с LLM под капотом.
Ваш, @llm_under_hood 🤗
@techsparks перепостил заметку, с которой я категорически не согласен:
Apple тихо и красиво проваливается в главной гонке десятилетия — гонке за искусственный интеллект. Bloomberg написал длинный текст о том, как всё пошло не так: Siri с якобы встроенным ИИ оказалась всё той же вежливой скрепкой из 2011-го года, просто теперь ошибающейся в большем количестве сценариев (в трети, если быть точным).
Нет. Наоборот, Apple, как никто другой понимает важность выпуска стабильного и надежного продукта.
С AI можно такие продукты делать, но (если качество результата важно) это занимает очень много времени. Тестирование, работа с галлюцинациями и стабилизация AI пайплайнов требуют больше усилий, чем кажется. Apple недооценила объем работ, бывает.
И я восхищаюсь их выдержкой. Вместо того, чтобы выкатывать сырой продукт, они сорвали сроки и взяли время на доделку.
Это скорее свидетельствует о том, что они серьезно подходят к продукту и будут стремиться выдерживать планку качества. Всем бы так подходить к продуктам с LLM под капотом.
Ваш, @llm_under_hood 🤗
❤77👍49🤣44🔥10🤔10😁3
Я пару дней пользовался OpenAI Codex. Это не панацея, но при этом прорывная в своем роде штука.
Codex - это среда для AI + Coding. Сразу предупрежу, что качество работы с кодом примерно сравнимо с тем, что уже можно получить с Cursor + Gemini Pro 2.5. Тут нет ничего нового.
Есть один нюанс. Разработку в Cursor + Gemini Pro 2.5 или Aider надо вести самостоятельно, выдавая задачи, отслеживая проблемы и проверяя результаты. За один раз можно вести один проект.
Есть еще альтернативный подход к разработке - запускать агентов, которые сами будут что-то планировать и копошиться в папке с проектом. Но, как я писал, иногда агенты только создают иллюзию работы, растягивая на 30-120 минут задачи, которые можно решить одним промптом в чате.
А что нового предложил OpenAI Codex?
Они сделали все красиво и удобно. Можно к своему аккаунту подключить несколько github repositories и запускать задачи текстом (примеры ниже). Это похоже на работу DeepResearch, но с кодом. Поставил задачу и пошел по своим делам, а reasoning планировщик от OpenAI проследит за выполнением работы. Он заберет код, прочитает инструкции, сам найдет нужные файлы, попробует изменить их, прогонит тесты итп. А в итоге упакует все изменения в Pull Requests, который можно будет по отдельности просмотреть и принять либо отклонить.
И тут есть две фишки.
Во-первых, планировщик OpenAI работает достаточно хорошо. Примерно треть его Pull Requests можно отправлять прямо в код (половину, если проект простой).
А ведь еще можно допилить проект, чтобы Codex-у было удобнее работать. Докинуть AGENTS.MD с инструкциями, добавить хорошие тесты, модульную архитектуру и комментарии. Все фишки оформления проектов для работы с AI+Coding, про которые мы говорили на вебинарах в прошлом году - тут как раз применимы.
И это все работает стабильно потому, что OpenAI выбрали всего несколько инструментов для своего “агента”, очень хорошо протестировали и отладили все. Это было возможно потому, что у Codex нет кучи инструментов - только консоль и работа с файлами.
Хотя, казалось бы, дай кодексу возможность работать с любыми MCP серверами, как это нынче сделала Microsoft, и получится продукт-бомба. Но OpenAI хорошо понимает, что в таком случае ни о каком покрытии тестами нельзя вести речь. А значит и прощай стабильность и привет галлюцинации.
Во-вторых, в Codex можно запускать одновременно несколько задач. Каждая из них будет запущена в отдельном контейнере. И вот это как раз кардинально меняет весь подход. Можно, скажем, сказать:
(1) добавь мне шифрование паролей с bcrypt
(2) перепиши доступ к БД с sqlite3 на синхронный better-sqlite3
(3) отладь вот эту ошибку в тестах
и сразу в другом проекте, который совершенно не относится к первому:
(4) напиши тесты к wifi_manager component
(5) сделай, чтобы система переподключалась при проблемах с wifi или websocket
и идти пить кофе. А потом вернуться, посмотреть отчеты с Pull Requests и задать новые задачи.
Получился очень классный продукт для разработки. Это как несколько очень усидчивых Джунов, которые могут помогать разрабатывать несколько проектов одновременно.
Понятно, что есть пара нюансов:
(1) OpenAI Codex - не панацея, он дополняет опытных разработчиков, не заменяет
(2) Среда очень ограниченная, и там есть нюансы (например, e2e browser testing я так пока там не смог запустить)
(3) нужна практика, чтобы освоить инструмент и научиться так формировать проекты, что Codex будет с ними хорошо работать.
Ну и самое главное, OpenAI наглядно показали, что агенты могут работать очень хорошо, если собрать правильный продукт, докинуть туда хорошую reasoning модель и обеспечить приемлемое качество. И тут хорошо выстреливает модель - выдал задания и ушел по своим делам/пить кофе.
Теперь осталось подождать, пока другие компании воспользуются этим примером! Особенно будет интересно увидеть подобные решения не в кодинге, а в бизнес-задачах.
Ваш, @llm_under_hood 🤗
PS: Хотите запустить локально без красивого UI? См OpenAI Codex CLI
Codex - это среда для AI + Coding. Сразу предупрежу, что качество работы с кодом примерно сравнимо с тем, что уже можно получить с Cursor + Gemini Pro 2.5. Тут нет ничего нового.
Есть один нюанс. Разработку в Cursor + Gemini Pro 2.5 или Aider надо вести самостоятельно, выдавая задачи, отслеживая проблемы и проверяя результаты. За один раз можно вести один проект.
Есть еще альтернативный подход к разработке - запускать агентов, которые сами будут что-то планировать и копошиться в папке с проектом. Но, как я писал, иногда агенты только создают иллюзию работы, растягивая на 30-120 минут задачи, которые можно решить одним промптом в чате.
А что нового предложил OpenAI Codex?
Они сделали все красиво и удобно. Можно к своему аккаунту подключить несколько github repositories и запускать задачи текстом (примеры ниже). Это похоже на работу DeepResearch, но с кодом. Поставил задачу и пошел по своим делам, а reasoning планировщик от OpenAI проследит за выполнением работы. Он заберет код, прочитает инструкции, сам найдет нужные файлы, попробует изменить их, прогонит тесты итп. А в итоге упакует все изменения в Pull Requests, который можно будет по отдельности просмотреть и принять либо отклонить.
И тут есть две фишки.
Во-первых, планировщик OpenAI работает достаточно хорошо. Примерно треть его Pull Requests можно отправлять прямо в код (половину, если проект простой).
А ведь еще можно допилить проект, чтобы Codex-у было удобнее работать. Докинуть AGENTS.MD с инструкциями, добавить хорошие тесты, модульную архитектуру и комментарии. Все фишки оформления проектов для работы с AI+Coding, про которые мы говорили на вебинарах в прошлом году - тут как раз применимы.
И это все работает стабильно потому, что OpenAI выбрали всего несколько инструментов для своего “агента”, очень хорошо протестировали и отладили все. Это было возможно потому, что у Codex нет кучи инструментов - только консоль и работа с файлами.
Хотя, казалось бы, дай кодексу возможность работать с любыми MCP серверами, как это нынче сделала Microsoft, и получится продукт-бомба. Но OpenAI хорошо понимает, что в таком случае ни о каком покрытии тестами нельзя вести речь. А значит и прощай стабильность и привет галлюцинации.
Во-вторых, в Codex можно запускать одновременно несколько задач. Каждая из них будет запущена в отдельном контейнере. И вот это как раз кардинально меняет весь подход. Можно, скажем, сказать:
(1) добавь мне шифрование паролей с bcrypt
(2) перепиши доступ к БД с sqlite3 на синхронный better-sqlite3
(3) отладь вот эту ошибку в тестах
и сразу в другом проекте, который совершенно не относится к первому:
(4) напиши тесты к wifi_manager component
(5) сделай, чтобы система переподключалась при проблемах с wifi или websocket
и идти пить кофе. А потом вернуться, посмотреть отчеты с Pull Requests и задать новые задачи.
Получился очень классный продукт для разработки. Это как несколько очень усидчивых Джунов, которые могут помогать разрабатывать несколько проектов одновременно.
Понятно, что есть пара нюансов:
(1) OpenAI Codex - не панацея, он дополняет опытных разработчиков, не заменяет
(2) Среда очень ограниченная, и там есть нюансы (например, e2e browser testing я так пока там не смог запустить)
(3) нужна практика, чтобы освоить инструмент и научиться так формировать проекты, что Codex будет с ними хорошо работать.
Ну и самое главное, OpenAI наглядно показали, что агенты могут работать очень хорошо, если собрать правильный продукт, докинуть туда хорошую reasoning модель и обеспечить приемлемое качество. И тут хорошо выстреливает модель - выдал задания и ушел по своим делам/пить кофе.
Теперь осталось подождать, пока другие компании воспользуются этим примером! Особенно будет интересно увидеть подобные решения не в кодинге, а в бизнес-задачах.
Ваш, @llm_under_hood 🤗
PS: Хотите запустить локально без красивого UI? См OpenAI Codex CLI
👍78🔥32❤20😁1
Есть вопросы про Domain-Driven Design и AI?
В нашем комьюнити есть люди, которые слышали про Domain-Driven Design или даже используют методы оттуда. Чаще всего это встречается в сложных областях и больших корпоративных проектах.
Я сам постоянно опираюсь на DDD в проектах. Во-первых, DDD сильно помогает приземлять сложные проекты в реальность, изолировать домены и организовывать работу разных команд (которые не всегда дружат). Во-вторых, DDD - как методология уделяющая особенное внимание языку - очень хорошо помогает в разработке решений с Large Language Models под капотом.
Какие вопросы в рамках темы данного канала вы бы хотели задать Эрику Эвансу - автору Domain-Driven Design?
Ваш, @llm_under_hood 🤗
В нашем комьюнити есть люди, которые слышали про Domain-Driven Design или даже используют методы оттуда. Чаще всего это встречается в сложных областях и больших корпоративных проектах.
Я сам постоянно опираюсь на DDD в проектах. Во-первых, DDD сильно помогает приземлять сложные проекты в реальность, изолировать домены и организовывать работу разных команд (которые не всегда дружат). Во-вторых, DDD - как методология уделяющая особенное внимание языку - очень хорошо помогает в разработке решений с Large Language Models под капотом.
Какие вопросы в рамках темы данного канала вы бы хотели задать Эрику Эвансу - автору Domain-Driven Design?
Ваш, @llm_under_hood 🤗
🔥31❤9🤩5👍2🤝2
Чем отличается OpenAI Codex от Claude Code / Aider / Cursor итп? Одной картинкой.
Можно запустить разные задачи на разных проектах прямо с телефона.
Ваш, @llm_under_hood 🤗
Можно запустить разные задачи на разных проектах прямо с телефона.
Ваш, @llm_under_hood 🤗
🔥47🤔14🤯8❤3👍3🎄1
Человек, который разбирается в DDD, подтвердил, что AI проекты со стороны кажутся слишком непредсказуемыми и сложными для опытных интеграторов.
Но если посмотреть на все с точки зрения статистики успешных кейсов и рабочих паттернов, то начинает вырисовыватся интересная картинка. Просто у них пока не было такой статистики и перспективы.
Будем исправлять.
Ваш, @llm_under_hood 🤗
PS: Ваши вопросы я задать не успел, но они уже пригодились. Спасибо! Я их приберегу на потом.
Но если посмотреть на все с точки зрения статистики успешных кейсов и рабочих паттернов, то начинает вырисовыватся интересная картинка. Просто у них пока не было такой статистики и перспективы.
Будем исправлять.
Ваш, @llm_under_hood 🤗
PS: Ваши вопросы я задать не успел, но они уже пригодились. Спасибо! Я их приберегу на потом.
🤩36👍27🔥8❤6😁6👏3🤝2🤣1
Кейс - локальный ассистент по работе с технической и регламентной документацией.
Это цитата Alex U из нашего чата. Можно посмотреть обсуждение и задать дополнительные вопросы тут.
Ваш, @llm_under_hood 🤗
PS: Если заходите в чат впервые, пожалуйста, не игнорируйте сообщения от бота спам-защиты.
У нас был кейс - ассистент по работе с оборудованием (нефтегаз, upstream). Много технической и регламентной документации. Пайплайн - таксономия по документам и разделам, фильтрация документов и роутинг по запросу, семантический чанкинг, гибридный поиск, LLM Reranker, еще ветка на text2SQL (отдельная экстракция табличных данных), обогащение контекста. Answer relevance финальной генерации рос почти пропорционально размеру модели (Qwen) в экспериментах, где все релевантные чанки были в контексте (recall = 100%). Остановились на 70B. Ниже не устраивало заказчика по качеству, а 70В было еще приемлемо по цене (2xA100). Датасет - несколько тысяч запросов.
Это цитата Alex U из нашего чата. Можно посмотреть обсуждение и задать дополнительные вопросы тут.
Ваш, @llm_under_hood 🤗
PS: Если заходите в чат впервые, пожалуйста, не игнорируйте сообщения от бота спам-защиты.
👍32🔥18❤7
А могут ли современные AI+Coding инструменты справиться с большими проектами? Например, самостоятельно добавить фичу в SaaS продукт?
Такой вопрос мне постоянно задают опытные разработчики. Их скепсис понятен. Если мелкие утилитки и прототипы Claude или Gemini Pro ещё осилят, то вот разрабатывать самостоятельно большие приложения с кучей зависимостей и нюансов - уже сложнее.
Разработчики говорят, что агенты вечно упускают из виду важные нюансы или даже просто несут пургу.
А какой у вас опыт использования AI+Coding инструментов для разработки фич в приложениях?
Ваш, @llm_under_hood 🤗
PS: Тема интересная. Давайте в дискуссии не будем переходить на личности и будем уважительны.
Задача - не доказать что-то, а вместе разобраться.
Такой вопрос мне постоянно задают опытные разработчики. Их скепсис понятен. Если мелкие утилитки и прототипы Claude или Gemini Pro ещё осилят, то вот разрабатывать самостоятельно большие приложения с кучей зависимостей и нюансов - уже сложнее.
Разработчики говорят, что агенты вечно упускают из виду важные нюансы или даже просто несут пургу.
А какой у вас опыт использования AI+Coding инструментов для разработки фич в приложениях?
Ваш, @llm_under_hood 🤗
PS: Тема интересная. Давайте в дискуссии не будем переходить на личности и будем уважительны.
Задача - не доказать что-то, а вместе разобраться.
👍32❤17🔥11😱1💯1
Вайб-кодить стало проще. Мелкие прототипы и утилиты делать с AI - милое дело.
Вообще, чем моложе код, тем лучше с ним справятся AI+Coding инструменты. И это меняет существующий уклад.
Раньше все парадигмы разработки продуктов строились на том, что разработка дорогая и долгая. Поэтому нужно было десять раз поговорить с клиентами, прежде чем запускать разработку одного прототипа.
Сейчас можно запускать MVP и собирать feedback гораздо быстрее. Главное, чтобы были люди, которые умеют работать с продуктовыми гипотезами.
Понятно, если продукт выстрелит, то его потребуется развивать. Новые фичи, масштабирование, безопасность, версионирование БД и API итп. И тогда уже нужен будет опытный старший брат/пастух, который будет присматривать за стадом из AI+Coding агентов, ловить косяки и периодически чистить техдолг.
Чем сложнее и старше система, тем больше там накапливается нюансов и особенностей. Тем больше там граблей, на которые могут наступить агенты.
Поэтому, когда заходит речь про AI+Coding, то мнения про него нередко поляризуются. Кто-то считает, что AI может справиться с любыми задачами. Кто-то считает, что AI галлюцинирует и делает глупые ошибки.
Чаще всего, в первом лагере те люди, которые работают с молодыми продуктами и небольшими прототипами. Во втором лагере те, кто работает с проектами старше нескольких лет от роду, с накопившейся сложностью и техдолгом.
Понятно, что представление про “два лагеря” - упрощенное, для иллюстрации. В реальности спектр проектов поразнобразнее.
Ведь можно за 30 минут нагенерить такую кашу, что этот молодой проект проще закопать сразу. А еще можно взять проект посложнее и поставить там хорошую архитектуру и среду для AI: оптимизировать стэк, разбить проект на модули, обвязать тестами, хорошей документацией и декомпозировать задачи. Тогда нужно будет реже вмешиваться в работу агентов, засучивать рукава и чистить техдолг.
Но в итоге все сводится к одному - чем старше проект, тем хуже работает вайб-кодинг, тем легче там AI+Coding агентам заблудиться без постороннего пригляда.
Ваш, @llm_under_hood 🤗
Вообще, чем моложе код, тем лучше с ним справятся AI+Coding инструменты. И это меняет существующий уклад.
Раньше все парадигмы разработки продуктов строились на том, что разработка дорогая и долгая. Поэтому нужно было десять раз поговорить с клиентами, прежде чем запускать разработку одного прототипа.
Сейчас можно запускать MVP и собирать feedback гораздо быстрее. Главное, чтобы были люди, которые умеют работать с продуктовыми гипотезами.
Понятно, если продукт выстрелит, то его потребуется развивать. Новые фичи, масштабирование, безопасность, версионирование БД и API итп. И тогда уже нужен будет опытный старший брат/пастух, который будет присматривать за стадом из AI+Coding агентов, ловить косяки и периодически чистить техдолг.
Чем сложнее и старше система, тем больше там накапливается нюансов и особенностей. Тем больше там граблей, на которые могут наступить агенты.
Поэтому, когда заходит речь про AI+Coding, то мнения про него нередко поляризуются. Кто-то считает, что AI может справиться с любыми задачами. Кто-то считает, что AI галлюцинирует и делает глупые ошибки.
Чаще всего, в первом лагере те люди, которые работают с молодыми продуктами и небольшими прототипами. Во втором лагере те, кто работает с проектами старше нескольких лет от роду, с накопившейся сложностью и техдолгом.
Понятно, что представление про “два лагеря” - упрощенное, для иллюстрации. В реальности спектр проектов поразнобразнее.
Ведь можно за 30 минут нагенерить такую кашу, что этот молодой проект проще закопать сразу. А еще можно взять проект посложнее и поставить там хорошую архитектуру и среду для AI: оптимизировать стэк, разбить проект на модули, обвязать тестами, хорошей документацией и декомпозировать задачи. Тогда нужно будет реже вмешиваться в работу агентов, засучивать рукава и чистить техдолг.
Но в итоге все сводится к одному - чем старше проект, тем хуже работает вайб-кодинг, тем легче там AI+Coding агентам заблудиться без постороннего пригляда.
Ваш, @llm_under_hood 🤗
❤71👍40🔥22💯9🤔3😁2🤗2