LLM под капотом


Kanal geosi va tili: ko‘rsatilmagan, Ruscha


Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.

Связанные каналы  |  Похожие каналы

Kanal geosi va tili
ko‘rsatilmagan, Ruscha
Statistika
Postlar filtri


Через час на NODES 24 будем рассказывать про text-to-SQL

И еще про text-to-cypher. Идея в том, чтобы сравнить способности разных LLM-ок к генерации запросов для реляционных и графовых баз данных.

Для этого мы взяли модель данных из системы документирования технических и организационных зависимостей в корпорациях (на базе Contexture) и завели список вопросов-ответов. Например вопрос, который требует рекурсии:

If the Customer Relationship Management (CRM) system failed while its maintainer was on vacation, how many other systems that depend on it would be impacted directly and indirectly?


Коллега загрузила эту модель в Neo4j и использовала разные подходы для того, чтобы на основе пользовательских вопросов строить Cypher запросы к БД.

Я сделал аналогичное, но для SQLite. При этом не стал возиться с подходами, а просто попросил ChatGPT написать мне пару разных схем (ведь мы уже с весенних вебинаров знаем про причины галлюцинаций и ошибок в LLM).

На картинке - табличка с тем, как разные модели справлялись с тестовыми задачами в разных ситуациях.

Рассказывать будем про это online через час на конференции neo4j - тут.

Ваш, @llm_under_hood 🤗


История развития State of the Art локальных моделей.

Ловите картинку на базе бенчмарков. Вместо трендов теперь для каждой категории модели отображается нормальный cumulative maximum.

Gemini 1.5 Flash 8B добавлен со звездочкой - его нельзя выкачать и запустить локально. Надо будет ждать, пока не появится открытая модель.

NB: Модели разделены условно на те категории железа, которые я чаще всего вижу у клиентов. Считаем VRAM на запуск с запасом места под контекст и без квантизаций.

На картинке видно, что крупные модели начали появляться относительно недавно, но у них прогресс пока быстрее всего идет.

Маленькие модели, которые влазят в 4090, достаточно долго стагнировали. Gemini 1.5 Flash 8B стал недавно внезапным рывком.

Ваш, @llm_under_hood 🤗


Бенчмарк Claude 3.5 Haiku - дороже и умнее

Новая младшая модель от Anthropic отражает тренд последовательного роста качества небольших моделей. Haiku в среднем подтянула очки по общим показателям, за исключением Code+Eng (*)

А еще у модели почти в два раза выросла способность мыслить! В категории Reason произошел скачок с 35 до 68. Это самое большое значение среди всех моделей Anthropic. Возможно мы видим новую архитектуру следующего поколения моделей?

На смену архитектуры намекает и четырехкратное увеличение стоимости Anthropic Haiku. Теперь она уже не "смышленая и очень дешевая". Можно найти подешевле и умнее. Например, GPT-4o Mini или Google Gemini Flash 1.5 8B.

Но общий тренд роста качества моделей радует. Посмотрим, не проявится ли рост Reason в следующих релизах моделей постарше.

Ваш, @llm_under_hood 🤗

(*) Я переименовал категорию Code в Code+Eng, чтобы точнее отражать наполнение бенчмарков - не только написание кода, но и анализ, review и интерпретация.

PS: Для тех, кто видит эти бенчмарки впервые, напомню - это закрытые продуктовые бенчмарки на основе набора задач из рабочих систем. Мы тестируем не то, как красиво модели болтают, а насколько качественно они выполняют конкретные задачи из продуктов с LLM под капотом. Про структуру и примеры бенчмарков можно прочитать в лабах или на официальном сайте бенчмарков.


Лайфхак для технических продуктов

Если у меня появится время на свой продукт c LLM под капотом, то я обязательно в нем хоть как-то пропишу тему sustainability. Это заметно увеличит его шансы на успех. Сейчас объясню почему.

Пару недель назад, еще до того, как я слег с этой дурацкой простудой, мы провели в Вене два технических Хакатона про LLM/Data Science. Общая тема: Sustainability - про бережливое отношение к окружающему миру. Эта тема, как секретное рукопожатие, открывает многие двери с минимальными усилиями.

Первый Хакатон - Логистический для Walter Group. В нем участники писали алгоритмы, которые управляли маленькими транспортными компаниями в симуляции Европы. Симуляция, помимо всего прочего, учитывала расход топлива, выбросы CO2 и усталость водителей.

Кода для этой части симуляции - около строчек 200 на Python, но этого было достаточно, чтобы на весь хакатон вешать тэг Sustainability. А последнее уже дает плюс для участников и проводящих его компаний. Больше приходит людей (в этот раз - 90), больше сотрудников потом себе находят компании.

Второй - Sustainability RAG Challenge. У коллеги есть Венское DS/ML community, и он решил провести первый Хакатон. Взял за основу Enterprise RAG Challenge, но в качестве документов сфокусировался на Sustainability Reports компаний. Это был осознанный и очень грамотный выбор.

Как только он рассказал про идею в компании, мгновенный ответ был: “Без вопросов! Проводи в головном офисе в выходные. Напитки мы заранее приготовим, на пиццу оставим денег, OpenAI tokens отсыпем с запасом. Что-нибудь еще надо?”. Все дали, все прошло хорошо, думают повторить.

Общая идея обоих мероприятий - взяли базовую концепцию, которая довольно неплоха сама по себе. Но ee подняли на другой уровень, дополнив чуть-чуть тематикой sustainability.

Добавление Sustainability обычно требует не очень больших усилий, но сразу дает огромный буст идее. Всем сразу видно, что авторы стремятся не просто зарабатывать много денег или репутации, а еще и приложили усилия и подумали про изменение мира к лучшему. Таким не жалко дать побольше денег и открыть побольше дверей.

Да и просто приятно работать с проектами, которые не только деньги зарабатывают, но и пытаются мир к лучшему изменить.

Вот еще несколько примеров:

Во время разработки логичистической симуляции мы достаточно легко получили грант как раз на технологии рассчета влияния логистики на окружающую среду. Грант оплатил месяц работы небольшой команды.

Бесплатное приложение с прогнозами погоды MyRadar в 2023 году собрало US$1.65M на запуск пары спутников, чтобы отслеживать пожары и качество воздуха. Ну и качество прогнозов улучшили.

Да и вообще, если взять список всех “хотелок” YCombinator и помаппить на цели бережливого развития ООН (UN Sustainable Development Goals - SDG), то получается интересная картинка: хотелки от YC не только вовсю используют AI/LLM, но и обязательно закрывают по 1-3 SDG.

Напомню, что YCombinator - это кузница крупнейших технических компаний вроде Stripe, Twitch, Airbnb, Reddit и Instacart. Они вложились в 4000+ компаний общей стоимостью US$600B. Их хотелки - это индикатор особенно выгодных коммерческих направлений. Они называются Request For Startups.


Картинку, которая показывает пересечения YCombinator RFS c SDG целями ООН, я закинул 'https://t.me/llm_under_hood/437?comment=27168' rel='nofollow'>в комментарии. А у вас есть проекты, которые тоже с ними пересекаются или могут пересечься?

Ваш, @llm_under_hood 🤗


Лучшие проекты с LLM - это те, которые делают отчеты, а не болтают

Я уже не раз говорил, что я стараюсь не браться за проекты, где клиент хочет себе conversational search или чатбота или что-то еще с текстовым полем "А что вы хотите сделать?"

Причина - у такого продукта слишком много нюансов и переменных. Этот продукт делается для людей, что открывает дверь для субъективщины, непоняток, длинных циклов разработки. В итоге, статистически, получаются длинные проекты и не очень довольные клиенты.

А как тогда быть? Да просто копать в настоящие хотелки клиента и пытаться свернуть продукт туда, где нужно работать с процессами или системами.

Только вчера шло обсуждение нового клиента, который хотел глобальный data warehouse с conversational search и умными ассистентами. Когда я сказал, что это делать совсем не выгодно - поискали альтернативные варианты и нашли пару кейсов с data extraction (пример кейса) или lead generation (пример кейса).

А последние как раз превосходно сводятся к обычным отчетам. Отчеты - сухие, конкретные и часто про деньги. На скриншоте как раз пример демо-отчета, который я только что отправил отделу продаж одного из клиентов. Для запуска этого на проде не нужно никаких хитрых серверов, микросервисов и деплойментов. Достаточно будет небольшую виртуалку и скрипт, который будет крутиться по расписанию.

Отчеты бывают читаемые людьми или для выгрузки в системы. Особый UX там не требуется, а если нужно причесать UI, то хватит и GPT-o1 (дизайн на фотке - его). А еще обычно не нужно ничего патчить, внимательно следить за нагрузками и аптаймом. Customer Support сводится к минимуму, а первые итерации можно просто прогонять у себя в юпитере и присылать файлом клиенту.

В общем, проекты с LLM под капотом, которые сводятся к отчетам - это сплошная красота (по скорости закрытия). И, по моей статистике, большинство клиентских ситуаций как раз можно свести к этому. Достаточно просто вспомнить заветы product-driven development и копнуть поглубже.

Ваш, @llm_under_hood 🤗

6.4k 1 190 42 108

Бенчмарк новой Claude 3.5 Sonnet v2 - лучше прошлой версии, но не TOP 10.

Только что в Anthropic зарелизили Claude 3.5 Sonnet v2. На продуктовом бенчмарке она в TOP 10 не попала, заняв 11ое место в общем зачете.

У новой версии подтянули следование инструкциям и работу с кодом (Code - это не только написание кода, но и анализ, преобразования и рефакторинг).

В целом неплохая модель, но в продуктовых задачах можно получить лучшее качество за меньшие деньги.

Кстати, для тех, кто очень нежно любит качество Claude 3.5 Sonnet в задачах простого написания кода, в комментарии выложу скриншот небольшого бенчмарка для Nodes24 конференции.

Ваш, @llm_under_hood 🤗

PS: Для тех, кто видит эти бенчмарки впервые, напомню - это закрытые продуктовые бенчмарки на основе набора задач из рабочих систем. Мы тестируем не то, как красиво модели болтают, а насколько качественно они выполняют конкретные задачи из продуктов с LLM под капотом. Про структуру и примеры бенчмарков можно прочитать в лабах или на официальном сайте бенчмарков.


Кейс - графовая система организации знаний для завода / корпорации.

На TedAI Vienna я встретился с ребятами, которые пилят Data Context Hub - систему для организации корпоративной системы знаний для заводов и огранизаций. Эта система подгребает под себя разносторонние источники данных и потом выстявляет наружу API для работы с ними.

Например, API для ответа на вопрос, “а сколько гаек X12123 версии 123 было использовано в машинах на последней неделе?” или “а кто может заменить рабочего X, которому надо нарезать 345 гаек X12123 версии 124, но заболел?”

Самое интересное у них:

(1) Они рано поняли, что векторные базы, семантический чанкинг (или любой чанкинг) - это бесполезная и вредная фигня в тех областях, где галлюцинации нам не нужны.
(2) Достаточно быстро поняли, что секретный рецепт для получения точных ответов на разнообразные ответы - “просто надо нормально предобрабатывать и структурировать данные”.
(3) Плюс быстро сообразили, что generic chatbot interface - это тупиковый путь. Лучше выставлять наружу специализированные интерфейсы под конкретные задачи, которые будут работать заведомо лучше (Dedicated Agents с заранее собранным инструментарием и контекстом под задачи)

Но про все это мы и так уже давно говорим в канале. Дальше начинается самое интересное. У них такое разнообразие данных, сущностей и контекстов, что все предобработать автоматически невозможно. А вручную это сделать - не хватит времени.

Поэтому они они после data intake ставят context mapping layer (все читали про Context Map из Domain Driven Design, так ведь?) В нем поток сырых данных размечается, сопоставляется, привязывается к сущностям и контекстам. И эти ребята просто выставили наружу интерфейс, в котором эксперты у клиента сами могут набросать правила преобразования их собственных сырых данных в их собственные размеченные данные. А если что-то не работает - поменять.

Подход похож на knowledge mapping, например из ассистента маркетолога, только в последнем эксперты у нас еще и сами данные раскладывали 😎

Эти данные потом грузятся в графовую базу данных, формируя готовую модель. А когда приходит время отрабатывать конкретные API запросы, то LLM обходит нужные ветки графа, собирая информацию для ответа. При этом будут использоваться правила и подсказки для данного типа API запроса.

Я говорил, что графовые базы данных обычно ведут команды в ложном направлении. Люди не хотят думать и все пытаются сделать автоматическую нарезалку данных, которая мелко нашинкует все на сущности и отношения. Данный кейс - это исключение. Эксперты вручную определяют правила нарезки данных.

Авторы Data Context Hub партнерятся с BMW и Siemens. Судя по всему, точности и гибкости системы хватает для небольших заводиков.

Кстати, забавно, что на сайте в use cases они еще упоминают embeddings, но в самой документации к продукту ни слова про вектора/chunks/embeddings. Возможно, хотят направить не слишком внимательных конкурентов по ложному следу.

Ваш, @llm_under_hood 🤗


На TedAI Vienna. Создатель xLSTM рассказывает про свой новый проект, который не использует трансформеры.

Кто-нибудь ещё пришел сюда?


Я сломал очередной стартап

Ребята с богатым нишевым опытом пилят платформу в EU по автоматизации процессов на базе AI. Они позвали меня в роли technical advisor на созвоны (Advisory Board, Founders + Tech Leads).

Когда созвоны начинались, вопросы были про то, как лучше втыкать RAG + индексацию в их процессы, как бороться с галлюцинациями, как можно реализовать чат-ботов.

Сегодня создатель на созвоне потирал руки со словами:

Ринат, ты мне поломал всю картину мира и упростил стратегию стартапа. Мы же можем взять весь мой опыт и просто захардкодить его как checklists в custom chain-of-thought рутине. Нам не нужно делать сложную платформу, и мы можем клиентам предложить решения вот прямо сейчас. А если сделать NoCode конструктор для формализации этого процесса (с верификацией качества), то вообще…


Что я такого рассказал? В принципе, ничего такого, про что бы не писал в канале или ответах на вопросы в последние два месяца (ищем по словам checklist или structured). Просто на созвонах рассказывал про одно и то же с разных углов и с дополнительными примерами под их ситуацию.

Процесс “поломки мира” занял какое-то время, но сегодня, наконец, все точки соединились! Дальше теперь у них процесс пойдет быстрее и веселее. А это значит, что у меня скоро освободится один слот на Technical Advisory по пол-часа раз в две недели (компании в ЕС и США).

Ваш, @llm_under_hood 🤗

6.9k 1 118 64 133

Бенчмарк Grok-2 от X.AI - 12 место

Это было внезапно. Я от X.AI не ожидал ничего работающего. Но у них Grok-2 неожиданно оказалась настолько хороша по показателям на продуктовом бенчмарке, что заняла место в первой дюжине. Даже Reason не самый стыдный - 58.

У модели в соседях - старые версии GPT-4, но она все же будет пониже, чем локальная Qwen 2.5.

При этом пользоваться ей пока совершенно невозможно - на OpenRouter дикие RateLimits.

Получается, что в топ-20 может вырваться практически любая компания, было бы желание, время, деньги на вычислительные ресурсы и доступ к разнообразным данным. Ждем больше конкурентов, желательно локальных.

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель
🔗 Бенчмарк Google Flash 1.5 8B - Прекрасное далеко

PS: Для тех, кто видит эти бенчмарки впервые, напомню - это закрытые продуктовые бенчмарки на основе набора задач из рабочих систем. Мы тестируем не то, как красиво модели болтают, а насколько качественно они выполняют конкретные задачи из продуктов с LLM под капотом. Про структуру и примеры бенчмарков можно прочитать в лабах или на официальном сайте бенчмарков.


PS: Слайд про подобных агентов из курса. Эту часть я уже записал и переделывать даже не надо)

6.6k 1 88 77 58

OpenAI Swarm - пример мультиагентной системы

OpenAI написали целую статью про организацию агентов и открыли небольшой фреймворк с примерами - Swarm.

Под капотом нет ничего сверхъестественного. Каждый агент - это своя небольшая рутина с собственным контекстом и набором инструментов.


refund_agent = Agent(
name="Refund Agent",
instructions="You are a refund agent. Help the user with refunds.",
tools=[execute_refund],
)

def transfer_to_refunds():
return refund_agent

sales_assistant = Agent(
name="Sales Assistant",
instructions="You are a sales assistant. Sell the user a product.",
tools=[place_order],
)


Для красоты они еще добавляют TriageAgent, который может переключать между нужными агентами:



triage_agent = Agent(
name="Triage Agent",
instructions=(
"You are a customer service bot for ACME Inc. "
"Introduce yourself. Always be very brief. "
"Gather information to direct the customer to the right department. "
"But make your questions subtle and natural."
),
tools=[transfer_to_sales_agent, transfer_to_issues_and_repairs, escalate_to_human],
)


Под капотом простой код, который конвертирует описания активных агентов в промпты, а все переключения между агентами и вызовы их инструментов упаковываются как вызовы стандартных OpenAI tools. В методичке все очень хорошо расписано, а сам код можно посмотреть на Github.

Концепция агентов - простых функций, со своим контекстом и набором инструментов работает очень хорошо. Помните, я в Марте писал про AI Ассистента для международной компании?

Там технически была как раз такая реализация, я построил Knowledge Map для продукта в виде структуры агентов и инструментов, которые необходимы для обработки запросов пользователей.

У каких-то агентов были инструменты в виде FTS поиска, какие-то знали, в каких папках искать, у третьих в контекст был встроен FAQ. А на входе стоял Triage Agent. Но тогда я еще не умел пользоваться tools/structured output, и в коде было много ненужных промптов и костылей. Сейчас это делается еще проще.

А как в ассистенте заранее знать, какие будут вопросы, чтобы подготовить армию агентов? Да просто смотреть на предметную область и задавать вопросы! В своем примере (который основывается на куче опыта) ребята из OpenAI же откуда-то узнали, что нужен TriageAgent/RepairsAgent/SaleAssistantAgent и RefundAgent?

(на самом деле паттерны повторяются из компании в компанию аналогично тому, как в компаниях повторяются должности и организационные структуры)

Кто еще смотрел этот код? Что думаете?

Ваш, @llm_under_hood 🤗

7.3k 4 355 94 68

Аренда H100 за $2 в час - про резкое падение цен на GPU

Очень детальный разбор ситуации есть в новой статье на latent space.

Если кратко, то в прошлом году было сложно арендовать H100 за 8 долларов в час в заметных количествах. В последние месяцы из-за кучи факторов среднаяя стоимость стала падать до двух долларов. См, например, цены на площадке SFCompute.

Плюс люди, наконец, поняли, что обучение моделей с нуля - это не так просто. Нынче легче взять хорошую базовую модель и довести ее напильником (либо нормальными промптами либо тюном). Поэтому все набранные кредиты, неиспользованные часы и кластера выплескиваются на рынок и сбрасывают цены. Плюс на горизонте уже маячат BH200.

Но есть один нюанс. Рынок - не дурак. Относительно дешевые конфигурации H100 - это пока именно, что излишки. Там, скорее всего, не будет InfiniBand, будут медленные хосты, проблемы с сетками или молодой неопытный оператор. Чем ниже цена - тем больше грабель.

Но это только начало тренда. Думаю, что он продолжится в следующем году, делая подобные мощности более доступными для небольших компаний.

Ваш, @llm_under_hood 🤗

6.2k 0 94 11 68

Настал тот момент, когда мы замучались удалять ботов

Поэтому я попросил Claude написать мне бота, который будет верифицировать новых участников нашего чата (там уже более 1300 участников).

Бот только что вышел на стражу. В нем целых 166 строчек кода на golang. Его от Shieldy отличает то, что логику верификации теперь мы можем переписать очень быстро.

Если кто хочет - может попробовать его сломать. У вас есть одна попытка 😎

Ваш, @llm_under_hood 🤗

PS: Бот заменяет старого Shieldy и срабатывает только на момент добавления и верификации. Существующие сообщения модерируются, как и раньше, вручную. В добром чатике банят только за спам, яростный оффтопик и токсичность.


Как может выглядеть checklist?

Например, так, как на картинках. Это скриншоты из бенчмарка, который мы делаем для доклада на NODES '24 (Neo4j dev conference).

Этот бенчмарк оценивает то, как качественно LLM преобразовывает запрос пользователя в запрос по базе данных (SQLite/neo4j).

В данном случае я задаю все вопросы из checkist на каждый запрос пользователя перед тем, как она начнет генерировать финальный ответ. Это все делается одним запросом к LLM.

Добавление такой chain of thought (захардкоженной в виде structured output) улучшает качество ответов с 76 до 81 на этом бенчмарке.

Вы пробовали такой подход? Напишите про результаты!

Ваш, @llm_under_hood 🤗


Бенчмарк Google Flash 1.5 8B - Прекрасное далеко

Помните недавно мы разбирали маленькие локальные модели от Llama 3.2, и там они прямо подвинули State-of-the-art? На этом прогресс не останавливается.

У Google стала доступна новая версия Gemini Flash 1.5 8B, и она показывает очень хорошие результаты на моих продуктовых бенчмарках . Эта модель размера 8B держится на уровне старых GPT 3.5 или Llama 3 70B. Она почти догоняет обычную 1.5 Flash по бенчмаркам.

Основной недостаток этой модели - она закрытая. Пусть размеры и известны, но скачать веса и запустить ее локально не получится.

Зато Gemini Flash 1.5 8B можно использовать очень недорого. Плюс, как это продемонстрировал сам Google - все, что сделала одна компания, другая сможет повторить. Поэтому ждем открытых моделей такого же уровня.

Кстати, официальная страница бенчмарков, наконец, переехала на новое место жительства. Также там добавились бенчмарки за сентябрь и август. Начиная с сентября, таблица стала немного интерактивной - модели можно фильтровать и подсвечивать.

Ваш, @llm_under_hood 🤗

🔗 Бенчмарк GPT o1 - топовая модель
🔗 Бенчмарк Qwen 2.5 - лучшая локальная модель
🔗 Gemini 1.5 Pro 002 - внезапно третье место!


PS: Для тех, кто видит эти бенчмарки впервые, напомню - это закрытые продуктовые бенчмарки на основе набора задач из рабочих систем. Мы тестируем не то, как красиво модели болтают, а насколько качественно они выполняют конкретные задачи из продуктов с LLM под капотом. Про структуру и примеры бенчмарков можно прочитать в лабах или на официальном сайте бенчмарков.


Дайте мне минуту, и я объясню, как связаны котики и RAG-и

Нет, это не связано с Игорем Котенковым, который регулярно приводит новых подписчиков из своего канала - @seeallochnaya.

Мне часто задают вопрос, который звучит примерно так.

Ринат, я хочу сделать поиск/бота для ответов на вопросы по переписке/документам компании/моим заметкам/FAQ-ам службы поддержки/продуктам. Какой RAG лучше начать смотреть?


В этот момент у меня в голове сразу возникает такая куча вопросов, что я обычно замолкаю:

- Почему именно RAG?
- А какую именно проблему мы пытаемся решать?
- Кто будет пользоваться этой системой?
- Какие у пользователей самые частые проблемы?
- А можно ли как-то эти проблемы кластеризовать по тому, какая информация нужна для их решения?
- А какие проблемы выгоднее всего решать?

У меня в истории успешно закрытых бизнес кейсов, случаев с RAG-архитектурой меньше 10%. Обычно решение проблем бизнеса удается свести к более простым специализированным технологиям. А простые решения и делаются быстрее и закрываются чаще.

Поэтому, когда спрашивают про “А какой RAG использовать для поиска ответов?” - это мне сразу напоминает котика с картинки. Он в лоток не ходил два дня, а ему уже хотят промыть желудок. Хотя, быть может, проблема всего лишь в том, что котика не покормили вовремя, и он обиделся.

TLDR; если вопрос стоит “какую RAG технологию использовать для решения какой-то задачи”, то это звучит, что бизнесу решили превентивно устроить карательное промывание желудка. Чтобы неповадно было.

Я бы вместо этого предложил посмотреть поглубже на решаемую проблему. Быть может, там есть решение попроще и понадежнее, без RAG-ов? (например, как это было в первом раунде Enterprise RAG Challenge).

Ваш, @llm_under_hood 🤗


OpenAI Canvas - аналог Claude Artifacts

OpenAI подсуетились и встроили в свой интерфейс режим Canvas. Он сильно похож на вариант от Anthropic и работает на GPT-4o.

В обоих случаях мы можем работать с текстом и кодом. ChatGPT может редактировать код, делать ревью, работать с комментариями и логами. На скриншоте пример, когда я отправил прототип golang http сервера в canvas и попросил сделать review кода.

OpenAI не поленились и вынесли отдельные операции (Code Review, Port to a language итп) прямо в кнопки в интерфейсе. Это хорошо - они наверняка отладили эти промпты на куче тестовых кейсов.

Еще можно выделить кусок текста на экране и попросить ChatGPT изменить его или объяснить. Переключение между версиями есть тоже.

В прошлом, я переключился в ряде задач с ChatGPT на Anthropic только из-за появления таких удобных Artifacts. Сейчас выглядит так, что OpenAI сделали еще больше удобных фич.

Где-то начали беспокойно шевелиться Cursor и аналоги. До их функционала Canvas еще очень далеко. Но если дело будет выгодным, OpenAI ничто не мешает расширить десктопную версию (там, говорят, Canvas уже тоже завезли), чтобы она работала с папками с кодом.

В общем, если у вас есть стартап или свой продукт - избегайте очевидных тропинок, по которым уже идет куча других компаний и могут пойти крупные игроки. Рискованное это дело. Скорость, с которой OpenAI повторили ключевой функционал Anthropic Artifacts это показывает.

Я лично использую Aider (см мой текущий AI Coding setup) для работы проектами на много файлов, и ему ChatGPT конкуренции пока не составляет, только Claude.

Ваш, @llm_under_hood 🤗

PS: А еще Canvas удобен для работы не только с кодом, но и текстом.

7k 2 114 21 61

Самый частый комментарий про исходники решения - победителя Enterprise RAG Challenge звучит примерно так:

Заварил чайник, чтобы сесть разобраться в исходниках. К концу первой кружки удивился, что так мало кода.


Я и сам удивился. Не ожидал, что checklists в сочетании со structured outputs - это настолько мощная связка, что может вытягивать сразу десятки-сотни сущностей из документа за раз.

Удивление было уже давно, целый месяц назад (это вечность по современным меркам 😂). А сейчас уже в ряде проектов у нас сложные пайплайны переделаны под эту связку. Сложными они были раньше, теперь скучные, и это хорошо.

Основная сложность теперь не в написании кода, а в написании такого дерева Structured Output объектов, чтобы оно работало как Checklist, заполняя который последовательно, мы приходим к правильным выводам.

Получается прямо захардкоженный Chain-of-thought, который выполняется одним запросом! Причем в нем можно сразу закладывать ветвления и выделять места для дополнительных рассуждений (см ниже).

Поэтому я сейчас всех консультируемых клиентов с подходящими кейсами тороплю - пробуйте эту связку. Времени она тратит немного, а вот разработку может сократить заметно. Ну и код становится скучным и эффективным. Все, как мы любим.

Пара подсказок сразу:


response = client.beta.chat.completions.parse(
model="gpt-4o-2024-08-06",
messages=messages,
response_format=ChainOfThoughtPydanticClass
)


(1) Не используем function calling syntax для передачи structured output, а передаем response_format

(2) gpt-4o-2024-08-06 работает хорошо. Вроде даже на Azure она уже есть со structured output.

(3) порядок полей очень важен! Они заполняются последовательно. Сначала можно ставить наводящие вопросы или даже давать место для размышлений (например, List[ThinkStep]).

(4) Там, где нужно делать классификацию, используем Literal. Опциональные поля помечаем как Optional, используем смело Dict/List. Ну и вообще знакомимся с фишками из Typing, которые поддерживает OpenAI API.

(5) Optional + вложенный класс - это возможность для GPT в рамках для Chain-of-thought пройтись по опциональной ветке размышлений. Еще есть anyOf, но так далеко с программированием на constrained decoding автомате я пока не заходил 😁

(6) Там, где важен формат ответа, ставим описание и примеры в Field. Это GPT тоже увидит. Можно повторить в названии и в описании. Например:


class Size(BaseModel):
width: float
height: float

size_inches: Optional[Size] = Field(None, description="Dimensions in inches (width, length)")


Понятно, что подход не универсальный. Но в продуктовых задачах для бизнеса такие самодельные ChainOfThought могут решать очень много задач одним запросом.

Тогда получится мой любимый вид продукта с LLM под капотом - когда снаружи он работает на одном уровне с передовыми решениями своего сектора, а то и лучше. Но у него есть маленький секрет - вместо монструозно сложной конструкции из кучи разных технологий (RAG/LangChain/Hybrid search/Agents итп) там просто пара простых и эффективных использований LLM. В итоге AI кода в решении - 5%, а все остальные 95% - это обычные интеграции, интерфейсы.

И такие типы продуктов очень важны для маленьких компаний и стартапов. При необходимости роста не нужно искать и нанимать редких ML специалистов. Код же простой и он на 95% обычен. Тут нужно искать обычных Front-End, Back-End и Full-stack итп. И нанять их можно будет сильно проще, т.к. зовут их не в обычный продукт, а в модный LLM-driven. Выигрывают от этого все.

Только вчера фаундер одного MedTech стартапа сказал, что после такого описания (с приоритизацией кейсов под этот паттерн) у него стратегия развития поменялась кардинально. И теперь pre-seed раунд на пару миллионов евро не выглядит недостижимым.

В общем, паттерн простой и мощный. Особенно, если приоритизировать кейсы, где он сработает хорошо (такие есть в каждой отрасли), а конкурентам оставлять более сложные.

Ваш, @llm_under_hood 🤗

PS: Я писал раньше про кейс с новой AI Platform для клиента. И он тоже теперь сильно использует этот паттерн на "одну кружку чая".

9.2k 4 634 136 113

Исходники 4-х решений из Enterprise RAG Challenge

Месяц назад у нас прошел первый раунд Enterprise RAG Challenge - дружеского соревнования по построению AI ассистентов на годовых отчетах компаний.

Итоги соревнования с кратким разбором победивших архитектур есть тут. Среди участников были и коммерческие системы.

А вот тут лежат исходники 4-х решений из этого списка, включая победившее. Там есть описания подходов и сам код. В некоторых случаях - лог провальных экспериментов.

Код я выпросил реальный - без особого причесывания и украшательства.

Если кратко:
- daniel - решение-победитель на базе checklist + structured outputs. Первое место.
- felix - multi-agent решение на базе ChatGPT-4o. Двенадцатое место.
- maria - assistants API. Тринадцатое место.
- pedro - локальное решение на базе openchat-3.5-0106. Девятое место.

Что будет дальше? Следующий раунд состоится попозже этой осенью в большем составе. Когда - сложно сказать, зависит от отдела маркетинга в TimeToAct, который сейчас очень загружен. Я бы рассчитывал на ноябрь.

Во втором раунде генератор вопросов будет перебалансирован, чтобы:
(1) было меньше вопросов без ответов (c N/A)
(2) было больше вариативности в вопросах, чтобы подход “в лоб” с checklist + structured outputs больше не мог так легко занять топовые места.

Ну и вопросники для участников будут побольше, чтобы мы вместе могли узнать чуть побольше про реально работающие подходы с LLM под капотом.

Ваш, @llm_under_hood 🤗

PS: Если кто-то еще из участников хочет поделиться своим кодом - шлите ссылки на гитхаб, я их добавлю в этот пост.

20 ta oxirgi post ko‘rsatilgan.