Yuriy Gavrilov: posts tagged AI

Действительно ли данные готовы к ИИ

Sat, 14 Mar 2026 00:19:28 +0300

Автор: Джейкоб Мэтсон

https://motherduck.com/blog/bird-bench-and-data-models

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

Теперь они у меня есть.

Все началось с вопроса одного из наших инвесторов: *“Как различные модели справляются с BIRD при использовании MotherDuck MCP?”* Поэтому я провел эксперимент. Три передовые LLM модели (`Claude Opus 4.5`, `GPT-5.2` и `Gemini 3 Flash`), каждая из которых подключена к базе данных через сервер `MotherDuck MCP`, были запущены на наборе данных `BIRD Mini-Dev`.

Пояснение:

MCP (Model Context Protocol):** Стандарт, позволяющий ИИ-моделям безопасно и стандартизировано подключаться к внешним источникам данных и инструментам.

BIRD (BIg Bench for Large-scale Database Grounded Text-to-SQL):** Популярный и сложный бенчмарк (набор тестов) для оценки того, насколько хорошо нейросети умеют переводить естественный язык в SQL-запросы.

Mini-Dev:** Это официальная выборка из 500 вопросов для разработки из бенчмарка BIRD. Она охватывает 11 баз данных в сферах финансов, спорта, образования и здравоохранения.

Модели данных здесь простые. В среднем 7 таблиц на базу данных. Ни в одной нет больше 13 таблиц. Объединения (joins) в основном «один-ко-многим», максимальная глубина — два или три перехода, ноль отношений «многие-ко-многим». Это тот тип схемы, который можно понять за пять минут, прочитав `DDL`.

Пояснение: `DDL` (Data Definition Language) — это часть SQL, используемая для описания структуры базы данных (создание таблиц, колонок, связей).

Результат? 95% точности. Никакого семантического слоя. Никакой истории запросов. Никакого специального контекста. Только схема базы данных.

Но это число требует «звездочки» (примечания), и, честно говоря, эта звездочка — самая интересная часть.

Что на самом деле означают 95%

Вот что я измерял на самом деле.

Бенчмарк BIRD оценивает точность, используя Execution Accuracy (EX): запускается предсказанный SQL и «золотой» (эталонный) SQL, сравниваются наборы результатов, и ставится бинарная оценка «сдал/не сдал». При этих строгих правилах текущий уровень развития технологий (SOTA) составляет около 76. Мои модели набрали 64 на тренировочной выборке и 58 на тестовой.

Звучит плохо. Но у строгой оценки BIRD есть хорошо задокументированная проблема. В статье 2025 года, представляющей метрику `FLEX`, было обнаружено, что точность выполнения (execution accuracy) BIRD совпадает с оценками экспертов-людей только в 62% случаев. Почти 4 из 10 суждений ошибочны, в основном это ложноотрицательные результаты, когда бенчмарк отвергает ответы, которые люди бы приняли.

Эти 62 бросились мне в глаза, потому что они почти точно совпадают с моей смешанной точностью при строгой оценке в 60.5 (64 обучение / 58 тест). То же наблюдение, но с другой стороны. Метрика `FLEX` пришла к этому с помощью проверяющих людей. Я пришел к этому, ослабив условия тестирования.

Подумайте, что это значит для таблицы лидеров. Если бенчмарк согласен с людьми только в 62 случаев, то чтобы набрать выше 62 по строгим правилам, вы должны начать воспроизводить ошибки бенчмарка. Вы перестаете учиться писать правильный SQL. Вы начинаете учиться соответствовать специфической, иногда ошибочной интерпретации каждого вопроса в BIRD. Системы с рейтингом 76 закрепили эти ошибки суждения в своем обучении. Они получают более высокие баллы, становясь *хуже* в выполнении реальной задачи.

Поэтому я построил более реалистичную оценку. Я разделил 500 вопросов на тренировочный набор (151 вопрос) и тестовый набор (349 вопросов).

Я использовал тренировочный набор (train) для калибровки оценки: вручную пересматривал ошибки, создавал исправленные «платиновые» ответы там, где «золотой» SQL BIRD был ошибочным, и настраивал правила частичного совпадения. Тестовый набор (test) был контрольным.

Вот как выглядит точность, если смягчать критерии оценки уровень за уровнем:

Уровень оценки (Scoring Tier)	Train	Test	Что добавляется
Только совпадение с Gold (≈ офиц. BIRD)	64.0	58.2	Строгое равенство наборов результатов
+ Платиновые ответы	73.1	58.5	Исправляет известные ошибки в «золотом» SQL BIRD (см. примечание ниже)
+ Допуск форматирования	78.8	65.5	Различия в `DISTINCT`, лишние колонки, округление
+ Судья LLM	94.9	94.4	“Принял бы человек этот ответ?”

Примечание: «Платиновые» исправления существуют только для тренировочного набора, так как я вручную проверил эти 151 вопрос. Вот почему уровень «Платина» почти не меняется на тесте +0.3 pp против +9.1 pp на тренировке). Но посмотрите на уровень с судьей: 94.9 на тренировке и 94.4 на тесте. Разница всего в половину процентного пункта. Оценка держится на контрольной выборке даже без моих исправлений вручную.

Результаты тренировочной выборки (151 вопрос, все 3 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	68.2	94.0	1.80	3 / 6 / 9
`Claude Opus 4.5`	64.9	95.4	26.37	4 / 6 / 9
`GPT-5.2`	58.9	95.4	6.87	4 / 7 / 12

Результаты тестовой выборки (349 вопросов, 2 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	60.7	94.6	3.96	4 / 6 / 9
`GPT-5.2`	55.6	94.3	15.32	4 / 7 / 11

*Примечание: `Claude Opus` не запускался на тестовом наборе. После того как все три модели сошлись на ~95% на тренировке, тратить еще 60+, чтобы доказать то же самое на 349 вопросах, показалось нецелесообразным.*

Медианная модель делает 6-7 вызовов инструментов MCP на вопрос при лимите в 10 итераций. Типичный вопрос выглядит так: изучить схему, просмотреть некоторые колонки, набросать запрос, проверить результаты, уточнить, готово. Некоторые модели, такие как `GPT-5.2`, делают несколько вызовов инструментов за итерацию, поэтому его показатель P95, равный 12, превышает лимит итераций.

Все три модели достигают 94-95% при реалистичной оценке, независимо от того, где они начинают при строгой оценке. На тренировочной выборке разрыв между «лучшим» и «худшим» сокращается с 12.6 процентных пунктов до 1.4. На тесте — с 5.1 до 0.3. Берите любую передовую модель.

Бенчмарк иногда ошибается

BIRD — хороший бенчмарк. Но в нем есть баги. Только в тренировочном наборе (151 вопрос) я нашел 49 случаев, где «золотой» SQL явно неверен. Я не проверял вручную тестовый набор, поэтому реальное число для всех 500 вопросов, вероятно, выше.

Вот пример, который мне запомнился. Вопрос просит список школ, чей совокупный балл превышает 1500. «Золотой» SQL проверяет `count` (количество) студентов, набравших более 1500 баллов. Совершенно другой запрос, совершенно другой ответ. Вы читаете вопрос, читаете «правильный» ответ и думаете: подождите, но спрашивали-то не об этом.

Я создал исправленные «платиновые» ответы для этих случаев. В среднем около 14 из 151 вопроса тренировочной выборки для каждой модели совпали с платиновым ответом вместо золотого, добавив 9.1 процентных пунктов.

Людей не волнует форматирование

На тренировочной выборке еще +5.7 pp получается за счет принятия результатов, которые верны по существу, но не проходят проверку на строгое равенство:

Лишние колонки (30 случаев): Модель вернула запрошенные данные плюс дополнительный контекст. Человек сказал бы «спасибо, это полезно». Бенчмарк говорит «провал».
Несовпадения `DISTINCT` (41 случай): Модель использовала `SELECT DISTINCT`, когда в золотом ответе этого не было, или наоборот. Уникальные значения совпадают идеально. Человек бы даже не заметил.
Различия в округлении (3 случая): Золотой ответ 24.67, ответ модели 24.6667. То же число, разная точность.

Ни один из этих ответов не является неверным. Это различия в форматировании, которые важны только для функции сравнения строк.

Человек (LLM)-в-петле (The LLM-in-the-Loop)

Оставшийся разрыв (16 pp на тренировке, 29 pp на тесте) закрывается судьей LLM. Я использовал `Gemini 3 Flash` для проверки каждого «проваленного» ответа с вопросом: *действительно ли этот SQL отвечает на вопрос?*

На тестовой выборке судья выполняет больше тяжелой работы, потому что там нет «платиновых» исправлений для предварительного отлова багов бенчмарка. Что именно он спасал?

Причина	Кол-во	Что произошло
Больше отфильтровано (Missing rows)	57	Модель отфильтровала строже, чем золотой стандарт, но это обоснованно.
Лишние строки (Extra rows)	33	Модель интерпретировала вопрос более широко.
Близкие значения (Values close)	19	Числовые результаты в пределах допуска.
Пустой результат	14	Модель ничего не вернула, но логика была верной (данных нет).
Пропущенные колонки	11	Возвращено меньше колонок, но ответ на вопрос дан.

Это оценочные суждения. Должен ли запрос «перечислите все школы в районе» включать чартерные школы? Разумные люди могут не согласиться. Строгий бенчмарк выбирает одну интерпретацию и наказывает за все остальные. Судья просто спрашивает, можно ли обосновать интерпретацию модели.

Если вы создаете ИИ-аналитику, это важно. Никто не выпускает продукт text-to-SQL, где пользователь видит сырые результаты без этапа проверки. Всегда есть человек или LLM, проверяющий выходные данные. Эти 94-95% отражают то, как эти продукты работают на самом деле. 58-64% отражают то, как работают бенчмарки.

А как насчет контекста?

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

Я протестировал это. Те же 500 вопросов, все модели, с комментариями к колонкам каждой таблицы и без них.

Схема	Train	Test
Без комментариев	94.9	94.4
С комментариями	96.0	94.6
Дельта	1.1 pp	0.2 pp

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

Если разбить по базам данных, становится интересно. Чем сложнее схема, тем больше помогают комментарии (усредненно по train и test):

База данных	Базовая точность	Эффект комментариев
`debit_card_specializing`	85.5 (самая сложная)	8.7 pp
`european_football_2`	93.2	3.4 pp
`california_schools`	95.7 (самая легкая)	2.9 pp

Комментарии помогают, когда схема действительно запутанная. Таблица `debit_card_specializing` (попробуйте угадать, как выглядит эта схема) получила самый большой прирост. Но схемы с интуитивными названиями и очевидными связями? Там комментарии сделали только хуже. У моделей уже сформировалась правильная ментальная модель, а комментарии внесли шум.

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

Почему простые модели данных работают

Базы данных BIRD — это не корпоративные хранилища данных. Они простые:

7 таблиц в среднем.
9 внешних ключей в среднем, в основном «один-ко-многим».
Ноль связей «многие-ко-многим».
Глубина join макс. 2-3 перехода, нет глубоких иерархий.

LLM читают эти схемы так же, как опытный аналитик читает DDL. Они видят таблицу `schools` с колонками `school_name`, `district` и `enrollment`, и они знают, что делать. Внешний ключ от `schools` к `scores`? Они знают, как их соединить (join). Никому не нужен семантический слой, чтобы объяснить, что “enrollment” означает «количество студентов».

Хорошее моделирование данных — это и есть семантический слой. Когда ваши таблицы названы хорошо, а объединения прямолинейны, у LLM есть всё необходимое.

Во что я бы инвестировал в первую очередь

Каждая среда уникальна, но вот как бы я расставил приоритеты, основываясь на том, что увидел:

Начните с модели данных. Чистые таблицы, понятные названия, простые объединения. Если опытный аналитик может посмотреть на вашу схему и понять ее за несколько минут, то и LLM сможет.
Затем добавьте целевой контекст. Комментарии к колонкам и метаданные, но только там, где действительно существует путаница. Документируйте таблицы типа `debit_card_specializing`, а не `schools`.
История запросов идет следом. Она становится важнее по мере усложнения предметной области, особенно для обнаружения недокументированных бизнес-правил (вроде “abnormal GOT > 60”). Базы данных BIRD имеют простые правила. Но я работаю над (проектом) `DABstep`, у которого простая модель данных, но очень сложные правила предметной области. Тот вид знаний, который живет в головах людей, а не в названиях колонок. Там история запросов и подобранный контекст будут значить гораздо больше. Но даже тогда чистая модель данных стоит на первом месте.

Наконец, не беспокойтесь о формальном семантическом слое. Если ваша модель данных чиста, а контекст целенаправлен, это почти ничего не добавляет для сценариев использования ИИ. На самом деле, кажется, что это даже мешает, так как ИИ отлично пишет SQL, но менее хорош в работе с другими инструментами.

Начните сейчас

Планка для «данных, готовых к ИИ», ниже, чем вам говорит индустрия.

Вам не нужен “движок контекста”, семантический слой, годы истории запросов или специализированная платформа метаданных. Вам нужна чистая модель данных и LLM. Найдите домен, который готов к этому, и начните там.

Разрыв между «точностью бенчмарка» и «примет ли это человек?» составил 31 pp на тренировочной выборке и 36 pp на тестовой. Это огромный разрыв, и он закрывается в тот момент, когда вы включаете человека или LLM в цикл проверки. Именно так и работает любой продукт ИИ-аналитики.

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

***

Итоги статьи

Проблема: Принято считать, что для работы ИИ с базами данных (Text-to-SQL) нужны сложные семантические слои, история запросов и контекст.
Эксперимент: Автор протестировал работу современных LLM (Claude, Gemini, GPT) на известном наборе данных BIRD.
Открытие 1: Формальные бенчмарки занижают качество работы ИИ. Они требуют строгого совпадения SQL-запросов, хотя люди принимают ответы с правильными данными, но другим форматированием (лишние колонки, другой порядок сортировки). Истинная (“реалистичная”) точность моделей достигает 95%, тогда как бенчмарк показывает около 60%.
Открытие 2: “Готовность данных к ИИ” сводится к понятной структуре базы данных. Чистые таблицы, внятные названия колонок и простые связи работают лучше, чем нагромождение комментариев.
Открытие 3: Дополнительные комментарии (контекст) нужны только для реально запутанных схем. В простых случаях они даже мешают, создавая шум.
Вывод: Не тратьте ресурсы на сложные семантические надстройки. Инвестируйте в чистоту модели данных (понятные имена таблиц и полей). Хорошая модель данных — это и есть лучший семантический слой для ИИ.

Data Stack 2.0: Закат Lambda-архитектуры и восход Fluss с Lance

Fri, 13 Feb 2026 01:59:35 +0300

Data Stack 2.0: Закат Lambda-архитектуры и восход Fluss с Lance

В мире инфраструктуры данных происходит “тектонический сдвиг”, описанный в отчетах a16z.com. Индустрия отходит от сложной Lambda-архитектуры (где batch и streaming живут отдельно) к унифицированным решениям, которые называют Streamhouse.

Два ключевых игрока, меняющих правила игры в этом переходе:

Apache Fluss — управляемое хранилище для потоковой обработки (Streaming Storage).
Lance — формат данных нового поколения для AI и Data Lake.

1. Проблема: Почему одной Kafka больше недостаточно?

Долгое время Apache Kafka была стандартом де-факто для передачи данных. Однако, как отмечают эксперты Ververica в статье Мир без Kafka, Kafka была спроектирована как *распределенный лог*, а не как база данных.

Перевод есть тут, у меня: https://gavrilov.info/all/mir-bez-kafka-pochemu-kafka-ne-podhodit-dlya-analitiki-realnogo/

Фундаментальные ограничения брокеров сообщений (Kafka/Pulsar) для аналитики:

Слабая работа с обновлениями (Updates): Kafka — это `append-only` система. Реализация `UPDATE` или `DELETE` требует использования *Compact Topics*, что не дает гарантий мгновенной консистентности и сложно в эксплуатации.
Медленное чтение истории: Чтобы найти запись годичной давности, вам часто нужно прочитать весь лог последовательно (Scan). Сложность операции — $O(N)$.
Row-based природа: Данные хранятся строками (Message bytes). Для аналитики (OLAP), где нам нужен средний чек по столбцу `price`, системе приходится распаковывать и читать *все* поля сообщения, что неэффективно.

2. Apache Fluss: Недостающее звено для Flink

Apache Fluss создан, чтобы решить проблему “разделения” между потоком и таблицей. Это нативное хранилище для Apache Flink, которое поддерживает концепцию Fluss.

Архитектурные прорывы:

Гибридная модель чтения (Stream-Table Duality): Fluss позволяет читать данные и как бесконечный поток (Log), и как изменяемую таблицу с первичными ключами (Primary Key Table). Это делает реализацию CDC (Change Data Capture) тривиальной: обновления перезаписывают старые значения по ключу.
Колоночная проекция (Columnar Projection): В отличие от Kafka, Fluss может отдавать аналитическому движку (Flink) только нужные колонки. Это снижает нагрузку на сеть (`I/O`) в разы.
Real-Time Lookups: Fluss поддерживает точечные запросы (Point Lookup) по первичному ключу с задержкой порядка миллисекунд.
$$Latency_{Fluss} \ll Latency_{Kafka Scan}$$
Это позволяет использовать его как *Serverless State* для приложений, избавляясь от необходимости ставить рядом Redis или RocksDB.
Tiered Storage в Data Lake: Fluss работает в паре с Apache Paimon (ранее Flink Table Store). Горячие данные живут в Fluss (на быстрых дисках/RAM), а по мере устаревания автоматически конвертируются в формат Lakehouse (Paimon/Parquet/ ну или Iceberg) и уходят в S3.

3. Lance: Новый стандарт для AI в Data Lake

Если Fluss отвечает за доставку и горячее состояние, то Lance меняет подход к хранению холодных данных для задач машинного обучения (ML).

Традиционный формат Parquet великолепен для аналитики (сканирование больших диапазонов), но ужасен для AI, где требуется случайный доступ (Random Access) для формирования батчей обучения.

Lance решает эти проблемы:

Случайный доступ:** Lance позволяет извлекать строки по индексу в ~100 раз быстрее Parquet.
Векторный поиск:** Это формат со встроенным векторным индексом (IVF-PQ). Вы можете хранить эмбеддинги прямо в файлах на S3 и выполнять поиск ближайших соседей (ANN) без отдельной VectorDB (вроде Pinecone или Milvus).
Zero-Copy версионирование:** Эффективное управление версиями датасетов без дублирования данных.

4. Сборка пазла: Как это работает вместе

Современный Streamhouse (см. примеры архитектуры]

выглядит как-то так:

Схема потока данных (Workflow):

Ingestion:
Приложения (на Go, Java, Python) пишут данные.

Важно:* Поскольку Fluss совместим с протоколом Kafka, можно использовать существующие Kafka-клиенты в Go-сервисах для записи в Fluss, не дожидаясь нативных библиотек. Но это пока только теория. Сходу я не нашел примеров быстро, но можно использовать GO и Arrow Flight SQL.

Streaming Storage (Fluss):
Fluss принимает данные, индексирует первичные ключи и хранит “горячее” окно (например, 24 часа).

Flink* выполняет `JOIN` и агрегации прямо поверх Fluss, используя `Lookup Join` (обогащение данных без сохранения большого стейта внутри Flink).

Archiving & AI (Paimon/Lance):
Исторические данные сбрасываются в S3.

Для классической BI-аналитики используется формат Apache Paimon или Iceberg.
Для ML-задач данные конвертируются или хранятся в Lance.

Unified Analytics (Trino):
Движок Trino позволяет делать SQL-запросы ко всем слоям одновременно. Аналитик пишет один `SELECT`, а Trino забирает свежие данные из Fluss, а исторические — из S3 (Lance/Parquet/iceberg).

Пример интеграции (концептуальный)

Поскольку прямого клиента Go для Fluss нет, использование в микросервисах чаще всего выглядит как работа через Kafka-протокол или HTTP-прокси, а основная логика ложится на Flink (Java/Python/ или еще чего):

// Flink SQL example: Создание таблицы, управляемой Fluss
CREATE TABLE user_behavior (
    user_id BIGINT,
    item_id BIGINT,
    action STRING,
    ts TIMESTAMP(3),
    PRIMARY KEY (user_id) NOT ENFORCED
) WITH (
    'connector' = 'fluss',
    'bootstrap.servers' = '...:9092', // Fluss совместим с Kafka-адресацией
    'table.log.consistency' = 'eventual' // Оптимизация под высокую пропускную способность
);

Надо пробовать и тестировать... все таки еще инкубационный и это только теория.

5. Выводы и рекомендации

Не используйте Kafka как базу данных. Если вашей архитектуре требуются частые обновления (`UPSERT`) и точечные запросы (`Lookup`), Apache Fluss — это более подходящий инструмент в экосистеме Flink.
Lance для AI. Если вы строите RAG (Retrieval-Augmented Generation) или RecSys, рассмотрите формат Lance вместо связки “Parquet + внешняя VectorDB”. Это упростит инфраструктуру.
Следите за совместимостью. Интеграции Lance с Trino и Fluss с не-JVM языками (например, Go, Rust или еще чего) находятся в активной разработке. Используйте проверенные пути (Kafka Protocol для Ingestion, DataFusion/Java/Python для Querying).

Полезные ресурсы для изучения:

ИИ в 2025 году: Чему нас научили 100 триллионов токенов?

Sat, 13 Dec 2025 00:02:25 +0300

Как на самом деле мир использует искусственный интеллект: от смерти чат-ботов к рождению агентов

Долгое время наше понимание того, как люди используют нейросети, строилось на опросах и догадках. Компания OpenRouter провела масштабное эмпирическое исследование, проанализировав 100 триллионов токенов (единиц информации), прошедших через их платформу за последний год (по декабрь 2025). Эти данные рисуют картину, кардинально отличающуюся от маркетинговых обещаний техногигантов.

Вот небольшой обзор того, как изменился ландшафт ИИ.

Ссылка на оригинал исследования:
State of AI: An Empirical 100 Trillion Token Study with OpenRouter

1. Конец эпохи «Вопрос-Ответ». Наступление эры «Думающих машин»

Самый главный сдвиг 2025 года — это переход от простой генерации текста к агентному инференсу (agentic inference).

Если раньше пользователь просил: «Напиши письмо», то теперь запрос звучит как: «Проанализируй эти файлы, напиши код, проверь его и выдай результат».
Доля использования моделей, способных к «рассуждению» (reasoning models, таких как o1, Gemini 2.5, DeepSeek R1), выросла с близких к 0% значений в начале года до более чем 50% к концу 2025-го.
Запросы стали сложнее: средняя длина промпта (входных данных) выросла в 4 раза. ИИ перестал быть собеседником и стал исполнителем, встроенным в сложные цепочки задач.

2. «Эффект хрустальной туфельки»: почему пользователи хранят верность

Исследование выявило удивительный феномен, названный «Эффектом хрустальной туфельки Золушки».
Рынок ИИ характеризуется огромной текучкой: пользователи постоянно пробуют новые модели и бросают их. Однако существуют «фундаментальные когорты» (foundational cohorts) — группы ранних пользователей, которые остаются с конкретной моделью навсегда.

Это происходит, когда новая модель первой решает конкретную, ранее невыполнимую задачу пользователя (как туфелька, которая подошла только Золушке).
Как только этот «пазл» складывается, пользователь встраивает модель в свои рабочие процессы и перестает искать альтернативы, даже если выходят более дешевые аналоги.
Если модель на старте не находит свою «боль», которую она лечит лучше всех, она обречена на забвение, даже будучи качественной.

3. Программирование поглощает ИИ

Миф о том, что ИИ — это в первую очередь генератор текстов и картинок, разрушен данными.

Программирование стало доминирующей категорией, превысив 50% от всего объема токенов к концу 2025 года.
Это самая конкурентная сфера: здесь идет ожесточенная битва между Anthropic (Claude), OpenAI и новыми игроками вроде Qwen.
Код — это драйвер сложности: именно задачи по программированию требуют самых длинных контекстов и глубокого рассуждения.

4. Скрытая жизнь Open Source: Ролевые игры и Китай

Рынок четко разделился на две части: закрытые модели (Closed Source) и открытые (Open Source).

Баланс сил:** Открытые модели теперь занимают около 30% рынка.
Китайский прорыв:** Модели из Китая (DeepSeek, Qwen) совершили рывок с 1.2% до почти 30% доли рынка в пиковые недели. Они обновляются невероятно быстро, предлагая качество уровня GPT-4 бесплатно или очень дешево.
Для чего используют Open Source? Более 50% трафика открытых моделей приходится на **Roleplay (Ролевые игры). Люди используют их для создания персонажей, интерактивных историй и развлечений, где важна свобода от цензуры и творческая гибкость. В то же время, закрытые модели (Claude, GPT) доминируют в бизнесе и программировании.

5. Размер имеет значение: «Средний» — это новый стандарт

В 2024 году рынок состоял из гигантских дорогих моделей и маленьких слабых. В 2025 году сформировался класс «Medium» (от 15 до 70 миллиардов параметров).

Маленькие модели вымирают.
Средние модели (например, Qwen Coder 32B) стали «золотой серединой»: они достаточно умны для сложных задач, но достаточно дешевы для массового использования.

6. Цена больше не определяет спрос

Анализ показал слабую эластичность спроса.

Пользователи делятся на два лагеря. Одни готовы платить любые деньги (30-40$ долларов за миллион токенов) за премиум-интеллект (модели OpenAI, Anthropic) для критически важных задач.
Другие выбирают «эффективных гигантов» (DeepSeek, Google Flash), где цена стремится к нулю, для обработки огромных массивов данных.
Просто «быть дешевым» недостаточно. Дешевые модели без уникальных способностей игнорируются рынком.

7. Глобализация интеллекта

ИИ перестает быть «западной» технологией.

Доля Азии в потреблении ИИ выросла с 13% до 31%.
Азия теперь не только потребляет, но и производит передовые модели, которые конкурируют на равных с Кремниевой долиной.

Основные выводы и тренды

Смерть «простого чат-бота»: Будущее за агентами, которые умеют планировать, писать код и использовать инструменты (браузер, терминал).
Дуополия задач: Рынок кристаллизовался вокруг двух мега-сценариев — Программирование (для работы) и Ролевые игры (для развлечения). Все остальное (перевод, юриспруденция, наука) занимает нишевые доли.
Битва экосистем: Нет «одной нейросети, чтоб править всеми». Разработчики комбинируют закрытые дорогие модели для «мозгов» и открытые дешевые модели для рутины.
Удержание важнее хайпа: Успех модели теперь измеряется не пиком скачиваний, а способностью создать «фундаментальную когорту» пользователей, чью уникальную проблему она решила первой.

Итог

Данные за 2025 год показывают, что индустрия перешла от фазы экспериментов к фазе прагматичной интеграции. Мы больше не спрашиваем ИИ «кто президент США?». Мы поручаем ему: «Напиши приложение, исправь баги и разверни его на сервере». ИИ стал новой вычислительной инфраструктурой, где код и креативность являются главными валютами.

Dino v3 🦖

Sat, 16 Aug 2025 11:04:40 +0300

https://github.com/facebookresearch/dinov3

Новая вижн моделька

Экосистема инструментов для Data Science и AI: От Дашбордов до Продвинутого MLOps

Sun, 10 Aug 2025 23:40:36 +0300

Все это можно быстро и просто запустить тут: https://www.ploomber.io

В современной науке о данных и разработке искусственного интеллекта недостаточно просто создать модель в Jupyter Notebook ( о нем вы уже знаете ) . Настоящая ценность раскрывается, когда результатами можно поделиться, когда модели становятся интерактивными и когда они надежно развернуты в производственной среде. Для решения этих задач появилось множество фреймворков, каждый со своими сильными сторонами и философией.

В этой статье мы рассмотрим и оценим ключевые инструменты, которые позволяют дата-сайентистам и ML-инженерам создавать веб-приложения, чат-ботов, API, отчеты и управлять жизненным циклом моделей.

Категория 1: Фреймворки для создания веб-приложений и дашбордов

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

Streamlit

GitHub Stars: 40.8k+
Официальный сайт: streamlit.io
GitHub Repo: streamlit

Описание и назначение: Streamlit — это, возможно, самый популярный фреймворк для быстрого создания data-приложений. Его философия — превратить скрипты в красивые веб-интерфейсы с минимальными усилиями. Приложение работает по простой модели: скрипт выполняется сверху вниз при каждом взаимодействии пользователя, что упрощает управление состоянием.

Особенности и оценка:

Сильные стороны: Невероятная простота и скорость разработки. Идеально подходит для создания прототипов, демо и внутренних инструментов medium.com. Отличная документация и большое сообщество.
Слабые стороны: Модель “перезапуска всего скрипта” может быть неэффективной для сложных приложений с большим количеством состояний. Кастомизация интерфейса за пределами стандартных компонентов может быть сложной задачей ai.gopubby.com.

Dash

GitHub Stars: 23.9k+
Официальный сайт: plotly.com/dash
GitHub Repo: github.com/plotly/dash

Описание и назначение: Dash от создателей Plotly — это мощный фреймворк для создания аналитических веб-приложений. Он использует Flask, Plotly.js и React.js под капотом, предоставляя Python-разработчикам доступ к современным веб-технологиям.

Особенности и оценка:

Сильные стороны: Высокая степень кастомизации и контроля. Идеален для корпоративных дашбордов и сложных приложений, требующих уникального дизайна и функциональности. Отличная интеграция с экосистемой Plotly.
Слабые стороны: Более высокий порог вхождения по сравнению со Streamlit. Концепция “коллбэков” требует времени для освоения.

Solara

GitHub Stars: 2.1k+
Официальный сайт: solara.dev
GitHub Repo: github.com/widgetti/solara

Описание и назначение: Solara позволяет создавать веб-приложения на чистом Python, используя компонентный подход, похожий на React. Он построен на базе Ipywidgets и может работать как в Jupyter Notebook, так и в виде самостоятельных приложений.

Особенности и оценка:

Сильные стороны: Компонентная архитектура способствует созданию чистого и переиспользуемого кода. Хорошо подходит для создания масштабируемых приложений корпоративного уровня ai.gopubby.com.
Слабые стороны: Менее известен, чем Streamlit или Dash, что означает меньшее сообщество и меньше готовых решений.

Gradio

GitHub Stars: 39.4k+
Официальный сайт: gradio.app
GitHub Repo: github.com/gradio-app/gradio

Описание и назначение: Gradio создан для невероятно быстрого создания демо для моделей машинного обучения. Всего за несколько строк кода можно обернуть любую Python-функцию (например, предсказание модели) в простой веб-интерфейс.

Особенности и оценка:

Сильные стороны: Максимальная простота для демонстрации моделей. Поддерживает различные типы ввода/вывода (текст, изображения, аудио). Легко встраивается в Jupyter/Colab и генерирует публичные ссылки для демонстрации.
Слабые стороны: Не предназначен для создания сложных, многостраничных дашбордов. Фокус смещен на “вход -> модель -> выход”. Структура приложения `app.py` часто используется для бэкенда при создании мультимодальных инструментов ai.plainenglish.io.

Shiny for Python & Shiny Express

GitHub Stars: 1.6k+ (Python)
Официальный сайт: shiny.posit.co/py
GitHub Repo: github.com/posit-dev/py-shiny

Описание и назначение: Shiny, легендарный фреймворк из мира R, теперь доступен и для Python. Он использует реактивную модель программирования, где изменения во входных данных автоматически вызывают пересчет связанных с ними выходных данных. Shiny Express — это его более легковесная версия в стиле Streamlit, позволяющая создавать приложения декларативно.

Особенности и оценка:

Сильные стороны: Мощная реактивная модель позволяет создавать очень эффективные приложения. Отличная интеграция с инструментами от Posit (ранее RStudio).
Слабые стороны: Сообщество в Python пока меньше, чем у аналогов. Реактивная модель требует особого подхода к мышлению.

Panel

GitHub Stars: 5.4k+
Официальный сайт: panel.holoviz.org
GitHub Repo: github.com/holoviz/panel

Описание и назначение: Panel — это мощный фреймворк из экосистемы HoloViz. Его главная особенность — совместимость практически с любой библиотекой для визуализации в Python. Он позволяет объединять виджеты и графики в гибкие макеты.

Особенности и оценка:

Сильные стороны: Непревзойденная гибкость и совместимость с другими библиотеками. Отлично подходит, если вы уже используете инструменты HoloViz (hvPlot, HoloViews).
Слабые стороны: Может показаться более многословным и сложным для простых задач по сравнению со Streamlit.

Другие интересные фреймворки UI

Chainlit (10k+ звезд): Специализированный фреймворк для быстрого создания чат-интерфейсов для LLM-агентов и приложений на базе LangChain/LlamaIndex.
Hyperdiv (900+ звезд): Предлагает новый подход: Python-код выполняется на сервере и мгновенно синхронизирует UI в браузере. Компоненты объявляются в простом, декларативном стиле.
Vizro (3k+ звезд): Конфигурационный фреймворк поверх Dash. Позволяет создавать дашборды через YAML или Pydantic-модели, что упрощает разработку.
Voilà (5.8k+ звезд): Превращает Jupyter-ноутбуки в самостоятельные веб-приложения, скрывая код и оставляя только виджеты и выводы ячеек.

---

Категория 2: Бэкенд и MLOps (Развертывание и управление)

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

FastAPI

GitHub Stars: 88.2k+
Официальный сайт: fastapi.tiangolo.com
GitHub Repo: github.com/tiangolo/fastapi

Описание и назначение: FastAPI — это современный, высокопроизводительный веб-фреймворк для создания API на Python. Он стал де-факто стандартом для развертывания моделей машинного обучения в виде REST API благодаря своей скорости, автоматической документации и использованию стандартных аннотаций типов Python.

Особенности и оценка:

Сильные стороны: Невероятная производительность. Автоматическая интерактивная документация (Swagger UI, ReDoc). Простота использования благодаря Pydantic и аннотациям типов.
Слабые стороны: Это бэкенд-фреймворк. Для создания UI его нужно использовать в связке с фронтенд-технологиями.

vLLM

GitHub Stars: 54.8k+
Официальный сайт: vllm.ai
GitHub Repo: github.com/vllm-project/vllm

Описание и назначение: vLLM — это не UI-фреймворк, а высокопроизводительная библиотека для инференса (выполнения) больших языковых моделей (LLM). Ее главная цель — максимально увеличить пропускную способность при обслуживании LLM.

Особенности и оценка:

Сильные стороны: Значительно ускоряет работу LLM благодаря инновационным техникам, таким как PagedAttention. Совместимость с моделями Hugging Face. Становится стандартом для быстрого self-hosting LLM.
Слабые стороны: Узкоспециализированный инструмент для инференса LLM.

MLflow

GitHub Stars: 21.5k+
Официальный сайт: mlflow.org
GitHub Repo: github.com/mlflow/mlflow

Описание и назначение: MLflow — это платформа с открытым исходным кодом для управления полным жизненным циклом машинного обучения. Он включает в себя компоненты для отслеживания экспериментов (Tracking), упаковки кода (Projects), управления моделями (Models) и их развертывания (Registry).

Особенности и оценка:

Сильные стороны: Комплексное решение для MLOps. Помогает стандартизировать и воспроизводить ML-эксперименты. Интегрируется с большинством ML-библиотек.
Слабые стороны: Требует настройки и внедрения в рабочий процесс. Может быть избыточным для небольших проектов.

---

Категория 3: Интерактивные вычисления и отчетность

Эти инструменты меняют представление о статических отчетах и ноутбуках, делая их интерактивными и воспроизводимыми.

Quarto

GitHub Stars: 4.7k+ (CLI)
Официальный сайт: quarto.org
GitHub Repo: github.com/quarto-dev/quarto-cli

Описание и назначение: Quarto — это система публикации научных и технических документов нового поколения от Posit. Она позволяет создавать динамические документы и презентации из Jupyter-ноутбуков или простого Markdown, смешанного с кодом на Python, R или Julia.

Особенности и оценка:

Сильные стороны: Поддерживает множество форматов вывода (HTML, PDF, DOCX, презентации и др.). Языковая агностичность. Позволяет создавать красивые, профессиональные и воспроизводимые отчеты.
Слабые стороны: В первую очередь это инструмент для публикации, а не для создания интерактивных real-time приложений.

Marimo

GitHub Stars: 15.3k+
Официальный сайт: marimo.io
GitHub Repo: github.com/marimo-team/marimo

Описание и назначение: Marimo — это реактивная среда для Python, которая решает многие проблемы традиционных Jupyter-ноутбуков. В Marimo ноутбук — это интерактивное веб-приложение. Изменение в одной ячейке автоматически обновляет все зависимые ячейки.

Особенности и оценка:

Сильные стороны: Реактивность обеспечивает консистентность состояния. Встроенные UI-элементы. Ноутбуки легко экспортируются в виде приложений.
Слабые стороны: Новый инструмент с растущим, но пока небольшим сообществом. Отличается от привычного рабочего процесса в Jupyter.

---

Как выбрать подходящий инструмент?

Для быстрого прототипа или демо модели: Streamlit или Gradio.
Для сложного, кастомизированного корпоративного дашборда: Dash или Solara.
Для создания бэкенда и API для вашей модели: FastAPI.
Для максимальной производительности при развертывании LLM: vLLM.
Для построения полноценного MLOps-цикла: MLflow.
Для создания чат-бота на базе LLM: Chainlit.
Для создания красивых, воспроизводимых отчетов и статей: Quarto.
Если вы хотите попробовать реактивный, state-of-the-art ноутбук: Marimo.
Если вы из мира R или вам нравится реактивная парадигма: Shiny for Python.

Тетрадки наше всё – marimo.io и уточкаdb

Thu, 07 Aug 2025 22:34:19 +0300

marimo is an open-source reactive notebook for Python — reproducible, Git-friendly, AI-native, SQL built-in, executable as a script, shareable as an app.

Ставим скорее..

pip install marimo && marimo tutorial intro

Ну и small data тоже любит тетрадки https://duckdb.org/docs/stable/guides/python/marimo

в общим долго рассказывать, но штука модная и крутая :) потом еще расскажу

про bi as a code можно посмотреть тут: https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

А тут есть пример использования iceberg каталога R2 c Marimo https://developers.cloudflare.com/r2/data-catalog/get-started/

А так в него можно добавить AI

UW PICO 5.09                          File: /Users/yuriygavrilov/.config/marimo/marimo.toml                             

[completion]
activate_on_typing = true
copilot = "custom"
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

и чуть ниже так..

[ai.open_ai]
api_key = "sk-GIkXXXXXXXXXX"
model = "openai/o1"
base_url = "https://openai.api.proxyapi.ru/v1"

Но как полечить это я еще не разгадал:

[E 250811 22:03:05 tools:173] Failed to get MCP tools: mcp is required for MCP server connections.

а пока усложняем задачу.

Хех, работает :)

Кстати уже писал про Bi as Code тут https://gavrilov.info/all/samye-populyarnye-instrumenty-biznes-analitiki-na-osnove-koda-ob/

Но будет полезно еще почитать по WASM контейнеры и запуст их в браузере, так как вся эта история на них хорошо работает, Evidence.dev например.

UPD: https://a.gavrilov.info/my_app2/dist/ – тут можно посмотреть экспортированную демо тетрадку в формате wasm с хостингом на s3

Экспортируются тетрадки так:

uv run  marimo export html-wasm markdown-format1.md -o my_app2/dist --include-cloudflare --mode run

Потом просто надо загрузить папку my_app2 в нужную директорию в все будет работать.

А вот еще пример генерации кода c ИИ

Тут можно посмотреть пример барчата https://a.gavrilov.info/my_app3/dist/

OpenAI OSS: можно качать

Tue, 05 Aug 2025 21:40:28 +0300

https://openai.com/open-models/

Для большой модели надо h100, а маленькая попроще и требует всего 16gb.

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

А вот квенчик красавчик: ai molodca)

но он знал ))

почти

trinking...

...
But the trick is that when "А" fell, it becomes "а" (lowercase?), but maybe not. Wait, another angle: in Russian, the phrase "А упала" could be a pun. Because "упала" means fell, but "а" is also the word for "and" in some contexts, but here it's the letter. Wait, maybe the answer is that only the "и" (which means "and") is left? Because the sentence is "А и Б сидели на трубе": A and B were sitting on the pipe. So the letters A, the word "и" (and), and B. So if A fell and B disappeared, then the "и" is left. Because the "и" is part of the phrase. Wait, that's a common riddle. Let me confirm.
...

LLM в продуктивной среде – Yadro’нные технологии

Sun, 03 Aug 2025 23:48:27 +0300

Недавняя статья компании YADRO на Хабре, “Где живут LLM”, стала редким и ценным окном в реальную практику построения корпоративного инференс-кластера. Команда не только поделилась своей архитектурой, но и честно рассказала о проблемах, что делает их опыт вдвойне полезным. Спасибо им за это!

🚀🚀🚀 https://habr.com/ru/companies/yadro/articles/930304/

Их кейс можно брать за основу, давайте разберем его и проведем небольшой анализ стека для работы с LLM — от низкоуровневых движков на GPU до low-code платформ для конечных пользователей. Этот разбор покажет, почему определенные технологические решения становятся стандартом и что необходимо для построения не просто работающей, а по-настоящему эффективной и масштабируемой AI-экосистемы.

Фундамент: Архитектура инференс-кластера

В основе кластера YADRO лежат проверенные и мощные компоненты, ставшие индустриальным стандартом:

Оборудование: Серверы с NVIDIA H100.
Оркестрация: Kubernetes.
Движок инференса: vLLM.

Ключевым и очень показательным решением стал выбор vLLM вместо, казалось бы, более нативного для NVIDIA Triton Inference Server. Аргументация YADRO проста и прагматична: с vLLM «намного проще добавлять новые модели», и он «изначально предоставляет OpenAI-совместимые REST API».

Это идеально отражает главный тренд в LLM Serving. Triton — это универсальная рабочая лошадка, мощная, но требующая серьезной подготовки: конвертации моделей в форматы вроде TensorRT и часто создания дополнительной «обвязки» для предоставления удобного API. vLLM, напротив, это специализированный инструмент, заточенный именно под LLM. Благодаря своей ключевой инновации — PagedAttention, которая кардинально оптимизирует управление памятью для KV-кэша, — он обеспечивает высочайшую пропускную способность и простоту использования «из коробки».

Средний слой: Production-ready операции и масштабирование

Переход от тестов к эксплуатации всегда вскрывает «узкие места». Опыт YADRO — прекрасное тому подтверждение.

Проблема шлюза (Gateway): Команда обнаружила, что популярный прокси LiteLLM, хотя и удобен для старта, становится узким местом при нагрузке выше 50 одновременных запросов. Их решение — разработка собственного `LLM Gateway` на Go — является абсолютно верным шагом для высоконагруженных систем. Такой шлюз берет на себя аутентификацию, логирование, rate-limiting и, что самое главное, умную маршрутизацию запросов. Для тех, кто не готов к собственной разработке, в экосистеме появляются готовые решения, такие как vllm-router, специально созданные для балансировки нагрузки между фермами vLLM-инстансов. https://docs.vllm.ai/en/stable/deployment/integrations/production-stack.html

Продвинутое масштабирование в Kubernetes: В статье упоминается горизонтальное автомасштабирование (HPA) по CPU. Для GPU-сервисов это неэффективно. Современный подход требует более точных триггеров:
- Масштабирование по GPU:** Использование `DCGM Exporter` от NVIDIA для сбора метрик утилизации GPU и настройка HPA или KEDA (Kubernetes Event-driven Autoscaling) по этим данным.
- Масштабирование по очереди:** vLLM предоставляет метрику `vllm_requests_waiting` (количество запросов в очереди). Это лучший показатель реальной нагрузки: как только очередь растет, система добавляет новые поды с моделями.

Мониторинг (Production Metrics): Для стабильной работы 24/7 критически важно отслеживать специфичные метрики vLLM в реальном времени через Prometheus и Grafana:
- Производительность:** Time to First Token (TTFT) и Time per Output Token (TPOT).
- Нагрузка:** `vllm_requests_running` (в обработке) и `vllm_requests_waiting` (в очереди).
- Состояние памяти:** `vllm_gpu_cache_usage_perc` (процент использования KV-кэша). Рост этой метрики — прямой предвестник ошибки нехватки памяти (OOM).

Верхний уровень: Платформы и интерфейсы для пользователей

Самый мощный бэкенд бесполезен без удобного доступа. YADRO упоминают, что предоставили пользователям интерфейсы через Dify и собственный WebUI, что выводит нас на уровень приложений и пользовательского опыта.

Dify: Low-code платформа для создания AI-приложений. Dify — это не просто чат, а открытая LLM Ops платформа, позволяющая быстро создавать и развертывать AI-приложения. С помощью визуального конструктора даже нетехнические специалисты могут собирать сложные воркфлоу, включая чат-ботов, RAG-системы (поиск по базам знаний) и AI-агентов. Dify подключается к инференс-кластеру по OpenAI API и служит мостом между мощным бэкендом и конечными бизнес-задачами.

Open WebUI: Персональный и безопасный доступ к моделям. Если Dify — это конструктор приложений, то Open WebUI — это универсальный и безопасный «кабинет» для прямого взаимодействия с моделями. Как отмечается в документации, это «расширяемая, многофункциональная и удобная платформа для самостоятельного хостинга, предназначенная для работы полностью в автономном режиме» docs.vllm.ai). Open WebUI предоставляет привычный интерфейс в стиле ChatGPT, но с расширенными возможностями: работа с локальными документами (RAG), веб-браузинг в чатах и управление доступом для команд — всё это в защищенном контуре компании https://www.repocloud.io/details/?app_id=271.

Инструменты для разработчиков: Интеграция в рабочий процесс

Чтобы LLM стали повседневным инструментом, их нужно встроить в рабочую среду разработчиков. YADRO верно отмечают ключевые компоненты этого уровня:

Continue.dev: Open-source расширение для VS Code/JetBrains, которое превращает внутренний инференс-кластер в полноценного AI-ассистента, работающего прямо в IDE.
OpenAI SDK и LiteLLM: Использование этих библиотек на стороне клиентских приложений — золотой стандарт. Они позволяют разработчикам абстрагироваться от деталей реализации бэкенда и работать с унифицированным, удобным API.

Кстати у litellm.ai есть демка их прокси сервера заходим Username: admin Password: sk-1234
https://demo.litellm.ai/ui

Итоги и выводы

Опыт YADRO — это отличный срез современной инженерной практики в области LLM. Его комплексный анализ позволяет сформировать полную картину production-ready AI-экосистемы, которая состоит из нескольких ключевых слоев:

Бэкенд: Специализированные движки (vLLM) на Kubernetes стали де-факто стандартом для высокопроизводительного инференса.
API и Ops: OpenAI-совместимый API — это универсальный «язык» для всех компонентов системы. Для масштабирования необходим кастомный Gateway/Router (как у YADRO) и продвинутое автомасштабирование по метрикам GPU и длине очереди.
Приложения и GUI: Low-code платформы (Dify) позволяют быстро создавать бизнес-решения, а интерфейсы вроде Open WebUI или LibreChat предоставляют сотрудникам безопасный и многофункциональный доступ к моделям.
DevX (Developer Experience): Интеграция в IDE (Continue.dev) и использование стандартизированных SDK делают LLM по-настоящему удобным инструментом для разработчиков.

Таким образом, создание «дома для LLM» — это далеко не только развертывание моделей на GPU. Это выстраивание целостной, многоуровневой системы, где каждый слой решает свою задачу, обеспечивая производительность, надежность и, в конечном итоге, ценность для бизнеса.

Ссылки Основная: https://habr.com/ru/companies/yadro/articles/930304/

Эволюция и будущее оркестрации ИИ

Thu, 03 Jul 2025 00:53:08 +0300

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

Оригинал тут: https://unionailoop.substack.com/p/the-evolution-and-future-of-ai-orchestration
2 июля 2025 г. – Кетан Умаре — генеральный директор и соучредитель Union.ai. Ранее он занимал несколько руководящих должностей в Lyft, Oracle и Amazon, работая с облачными технологиями, распределенными системами хранения данных, картографией и системами машинного обучения.

Термин “оркестрация” значительно эволюционировал за последнее десятилетие. То, что начиналось как способ упорядочивания микросервисов и задач обработки данных, превратилось в ключевой фактор для современных приложений, охватывающий системы от традиционных бэкендов до высокодинамичных, интеллектуальных рабочих нагрузок на агентах.

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

Настоящим узким местом являются не модели или вычисления – это мы.

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

1. Зарождение оркестрации: ETL и микросервисы

2012 – ETL
Оркестрация впервые появилась для обеспечения ETL (извлечение, преобразование, загрузка), где планировщики, такие как Airflow, управляли приемом и преобразованием данных на больших хранилищах данных.

Диаграмма: Процесс ETL

Извлечение:** Извлекает и проверяет данные из различных источников.
Преобразование:** Обрабатывает и организует извлеченные данные, чтобы сделать их пригодными для использования.
Загрузка:** Перемещает преобразованные данные в репозиторий данных.

2014 – Микросервисы
Поскольку использование постоянно растущих объемов данных стало более критичным для инноваций, возникла потребность в оркестрации микросервисов, где системы, такие как AWS Step Functions или Cadence, обеспечивали надежное выполнение вызовов сервисов и повторные попытки в транзакционных системах.

На ранних этапах оркестрация в основном сосредоточивалась на упорядочивании или определении, когда и как вызывать функцию, запускать скрипт или запускать контейнер. Трудоёмкие вычисления перекладывались на традиционные вычислительные движки, такие как Spark, AWS Batch, GCP Cloud Run или, позже, K8s. Оркестрация не касалась вычислений, и ей это было не нужно.

2. Машинное обучение: оркестрация встречается с вычислениями

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

В отличие от микросервисов или пакетного ETL, рабочие процессы ML представляют собой долгосрочные процессы, тесно связанные с инфраструктурой. Графические процессоры, на которые сейчас в большей степени полагаются, особенно для нужд обучения ML, являются более дорогими, чем центральные процессоры. Обучение моделей, их оценка, настройка гиперпараметров — все это требует динамического распределения ресурсов GPU или CPU. А поскольку эти процессы занимают гораздо больше времени, отказоустойчивое восстановление после сбоев стало гораздо важнее.

Эти потребности породили оркестраторы ML-конвейеров, такие как Flyte, которые до сих пор являются открытыми решениями для оркестрации, на которые полагается большинство команд.

2021 – Управляемая оркестрация ML
По мере того как оркестрация ML становилась более сложной, она ложилась более тяжелым бременем на команды ML, данных и платформ, которым нужно было поддерживать инфраструктуру. Им нужны были системы оркестрации, которые определяли DAG (ориентированный ациклический граф), выделяли ресурсы, управляли жизненным циклом задач и чисто масштабировались до нуля.

Платформы оркестрации, такие как Union.ai, Prefect и Airflow, появились для снятия инфраструктурной нагрузки с оркестрации. С появлением эпохи ИИ они стали гораздо популярнее для команд, создающих рабочие процессы ИИ/ML, как критически важную часть своей работы.

3. Агентные системы: оркестрация в эпоху ИИ

2025 – ИИ и агентная оркестрация
Сейчас мы вступаем в новую фазу: оркестрацию интеллектуальных агентов и систем ИИ.

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

Они зависят от интеграций. Агенты часто полагаются на внешние инструменты (API, базы данных, модели), и эти взаимодействия должны управляться.
Они принимают динамические решения. Агенты часто уточняют результаты за несколько проходов, подобно настройке гиперпараметров или рекурсивному исключению признаков в ML.
Они делегируют. Один агент может вызывать другого, который может разветвляться на новые инструменты или рабочие процессы.
Они требуют вычислений. Рассмотрим агентов, которые решают парсить веб или выполнять код. Если мы думаем об агентах как о программистах, то быстро понимаем, что оркестрация без доступа к вычислениям ограничивает их автономию.

Современные платформы разработки ИИ должны быть способны оркестрировать эти стохастические системы от начала до конца и динамически, а не статически. В противном случае мы лишаем агентов свободы действий.

Это отражает идеи Anthropic: создание эффективных агентов означает управление инструментами, адаптацию стратегий и надежное оркестрирование долгосрочных фоновых задач. Оркестрация здесь — это не статический DAG. Это динамический цикл.

Будущая инфраструктура разработки ИИ

“По некоторым оценкам, более 80% проектов ИИ терпят неудачу – это вдвое превышает процент неудач проектов в области информационных технологий, которые не связаны с ИИ”. – RAND

По мере созревания ML и агентных систем в 2025 году и далее, команды, создающие их, обнаруживают, что общие потребности в разработке ИИ выходят на первый план. Это не гипотетические проблемы. Мы видели их вживую у реальных клиентов и в продуктах, которые они создают.

Динамические рабочие процессы:** в отличие от статических DAG, динамические рабочие процессы позволяют агентам и системам ИИ принимать решения на лету во время выполнения.
Гибкая интеграция инфраструктуры:** оркестрация должна происходить по облакам и кластерам, в некоторых случаях динамически переключаясь на источник наиболее доступных вычислений.
Кросс-командное выполнение:** эти платформы должны объединять отдельных лиц, команды и агентов в единой среде разработки совместно, безопасно и надежно.
Наблюдаемость, надежность и управление:** агенты и рабочие процессы могут работать автономно в черном ящике. Платформы разработки ИИ должны обеспечивать прозрачность для рассуждений, сбоев, происхождения данных и использования ресурсов.
Масштаб:** большие данные становятся больше. Вычислительная мощность востребована как никогда. Платформы должны надежно справляться с требованиями к масштабированию, присущими этим системам.

Заключение:

Слой инфраструктуры разработки ИИ

Мы вступаем в мир, где оркестрация — это не просто “что запускается дальше”, но “что думает дальше”.

Эволюция от статических ETL-конвейеров к динамическим ML-рабочим процессам теперь совпала с ростом автономных агентов, и это сближение раскрывает фундаментальную истину.

Агенты и современные ML-системы требуют нового слоя в наших технологических стеках: инфраструктуры разработки ИИ.

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

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

Будущее оркестрации обеспечивает основу для слоя инфраструктуры разработки ИИ, будучи:

Динамичной** – адаптирующей структуру рабочего процесса на основе условий выполнения.
Эфемерной** – запускающей и останавливающей ресурсы по мере необходимости в рабочих процессах.
Мультиагентной и мультичеловеческой** – оркеструющей сотрудничество между автономными системами и командами.
Надежной и наблюдаемой** – обеспечивающей видимость и восстановление для систем, которые работают автономно.
Безопасной** – управляющей доступом и выполнением в различных распределенных рабочих нагрузках.

Оркестрация становится центральной нервной системой систем ИИ, питая этот новый слой инфраструктуры разработки ИИ в наших технологических стеках.

Вопрос больше не “как запустить этот конвейер?”, а “как позволить системам решать, что запускать, когда запускать и как делать это надежно в масштабе?”

Анализ: Orange Pi AI Studio Pro vs. NVIDIA DGX Spark (Project DIGITS)

Sun, 22 Jun 2025 18:29:39 +0300

Битва персональных AI-суперкомпьютеров ( подготовил DeepSeek 😁 и спасибо ему за это )
Если чего, то эти игрушки для подходят для запуска средних моделей у себя дома. Железа должно хватит.
Впрочем битва только начинается. посмотрим, что еще выйдет. А пока наслаждаемся тем, что есть.

Введение: Эра доступного AI-железа

Революция генеративного ИИ сместила фокус с облачных кластеров на персональные устройства. В 2025 году два решения претендуют на звание «AI-суперкомпьютер на столе»: NVIDIA DGX Spark (ранее Project DIGITS) и Orange Pi AI Studio Pro. Оба обещают экзафлопсную производительность, но с разной философией. Разберем их детально, используя данные из официальных анонсов, тестовых обзоров и сообществ https://habr.com/ru/companies/bothub/news/872002 и https://www.reddit.com/r/LocalLLaMA/comments/1im141p/orange_pi_ai_studio_pro_mini_pc_with_408gbs.

1. Аппаратная платформа: Архитектура и Производительность

NVIDIA DGX Spark

Чипсет: GB10 Grace Blackwell Superchip – гибрид 20-ядерного ARM-процессора (Cortex-X925 + Cortex-A725) и GPU Blackwell с Tensor Core 5-го поколения .
Память: 128 ГБ LPDDR5X с единым адресным пространством (CPU+GPU), что критично для обработки моделей до 200B параметров без перегрузок .
Производительность: 1 PFLOPS при FP4 с поддержкой спарсности. Для моделей >200B параметров два устройства связываются через ConnectX-7, достигая 405B .
Энергоэффективность: Потребляет ~120–240 Вт, работает от розетки 220 В .

Orange Pi AI Studio Pro

Чипсет: Huawei Ascend 310s с NPU, заявленная производительность – 352 TOPS (INT8) в Pro-версии .
Память: До 192 ГБ LPDDR4X (в конфигурации Pro), но без унификации. Пользователи Reddit отмечают проблемы с пропускной способностью при загрузке LLM >70B параметров .
Масштабируемость: Нет аналога NVLink. Для больших моделей требуется ручная оптимизация через swap-файлы .
Охлаждение: Инженерные образцы склонны к перегреву при длительной нагрузке, что требует дополнительного кулера .

Резюме: DGX Spark выигрывает в балансе памяти и вычислений, Orange Pi предлагает сырую мощность TOPS, но страдает от архитектурных ограничений.

---

2. Программная экосистема: Готовность к работе

NVIDIA

Стек: Полная предустановка DGX OS + CUDA, NeMo, RAPIDS, поддержка PyTorch/Jupyter. Бесшовная интеграция с NGC-каталогом и облаком DGX .
Развертывание: Локальная тонкая настройка (fine-tuning) моделей до 70B параметров с последующим деплоем в дата-центр без переписывания кода .
Для разработчиков: Поддержка Windows через WSL2, что упрощает миграцию с ПК .

Orange Pi

ПО: Базовые образы Ubuntu/OpenEuler. Для работы AI требуется CANN-Toolkit (только через Docker), установка которого занимает 5–6 часов из-за зависимостей .
Поддерживаемые фреймворки: ONNX, TensorFlow, Caffe. Нет поддержки PyTorch напрямую! Экспорт LLM (например, Whisper) возможен только через ONNX с ручной конвертацией .
Сообщество: Документация – преимущественно на китайском. Англоязычные гайды фрагментарны, а на Reddit жалуются на сложность отладки .

Резюме: NVIDIA предлагает enterprise-решение «из коробки», Orange Pi требует экспертных знаний и времени для настройки.

---

3. Сценарии использования: Для кого эти устройства?

NVIDIA DGX Spark:
- Исследователи: Локальный запуск Llama 3 70B или GPT-4-class моделей.
- Корпорации: Разработка edge-приложений для робототехники (Isaac) или медвизуализации (Clara) с гарантией совместимости .
- Стартапы: Прототипирование агентов ИИ с помощью NIM-микросервисов .

Orange Pi AI Studio Pro:
- Энтузиасты: Эксперименты с компьютерным зрением (YOLO) на дешевом железе.
- Нишевые проекты: Развертывание специфичных моделей (например, для обработки сенсорных данных), где не нужна интеграция с облаком.
- Китайский рынок: Альтернатива Jetson Orin для вузов и госпредприятий .

---

4. Цена и Доступность

NVIDIA: От $3000, доступен с мая 2025 через партнеров (например, Dell, Supermicro) .
Orange Pi: Цена не объявлена, но аналоги (Atlas 200I DK) стоили ~$500. Ориентировочно Pro-версия – $700–$1000. Важно: нет глобальных поставок; покупка только через AliExpress .

Итоговая таблица сравнения

Критерий	NVIDIA DGX Spark	Orange Pi AI Studio Pro
----------------------------	------------------------------------------	--------------------------------------
Аппаратная мощность	1 PFLOPS (FP4), 128 ГБ RAM	352 TOPS (INT8), 192 ГБ RAM
Поддержка LLM	До 405B параметров (2 устройства)	До 70B (с оговорками)
Программная готовность	Полный стек AI Enterprise	Ручная настройка CANN-Toolkit
Экосистема	CUDA, PyTorch, облачная интеграция	ONNX/TensorFlow, изолированность
Целевая аудитория	Enterprise, исследователи	Энтузиасты, нишевые разработчики
Цена	От $3000	~$700–$1000 (оценка)

Заключение: Что выбрать?

NVIDIA DGX Spark – выбор для тех, кому нужен промышленный инструмент с минимумом настройки. Идеален для команд, внедряющих ИИ в продукты с последующим масштабированием. Демократизация без жертв .
Orange Pi AI Studio Pro – экспериментальная платформа для тех, кому важен TOPS/$ и кто готов бороться с китайской документацией. Подойдет для R&D в условиях санкционных ограничений или бюджетных проектов .

Тренд: Оба устройства подтверждают сдвиг ИИ в сторону edge-вычислений. Но если NVIDIA ведет к «персонализации суперкомпьютеров», то Orange Pi остается хардварным хаком для избранных. Ориентируйтесь на задачи: для стартапа или лаборатории – DGX Spark; для образовательных целей или кастомных задач – Orange Pi, если вы готовы к боли.

*«AI будет мейнстримом в каждом приложении для каждой индустрии»* (Дженсен Хуанг, NVIDIA ). В 2025 это звучит как констатация факта, а не прогноз.

Почитать подробнее можно тут:
https://www.nvidia.com/en-us/products/workstations/dgx-spark/
или тут
http://www.orangepi.cn/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-AI-Studio-Pro.html

WAIC 2025 – World Artificial Intelligence Conference

Fri, 06 Jun 2025 00:09:25 +0300

WAIC (World Artificial Intelligence Conference) — это крупнейшая международная конференция по искусственному интеллекту, проходящая в Китае. Её ключевые аспекты:

300 000 посетителей 😱 и 1300 спикеров 😱 https://www.worldaic.com.cn – программу не ищите, ее просто нет. еще.

pdf тут http://a.gavrilov.info/data/posts/WAIC2025.pdf

Фокус на инновациях:
- Демонстрация прорывных технологий, включая робототехнику и Embodied AI (физические роботы, заменяющие людей в локальных сценариях). Например, на WAIC 2024 было представлено [более 50 роботов], многие из которых дебютировали именно здесь.
- Участие ведущих компаний (включая Alibaba, SenseTime), даже тех, кто не специализируется исключительно на ИИ.

Глобальное управление ИИ:
- Конференция служит площадкой для обсуждения этических норм и международного регулирования ИИ. В 2025 году запланирован [высокоуровневый саммит по глобальному управлению ИИ с участием политических деятелей (например, министра иностранных дел Китая Ван И).

Бизнес-экосистема:
- Стартапы (например, SenseTime, разработчик систем распознавания лиц) привлекают многомиллионные инвестиции через WAIC.
- Выставки и нетворкинг объединяют инвесторов, разработчиков и корпорации.

Тренды:
- Акцент на практическом применении ИИ в промышленности, здравоохранении и повседневной жизни.
- Рост темпов развития не только программных, но и аппаратных решений (роботы, сенсоры).

⚠️ Не путать с Western Association of Independent Camps WAIC https://www.waic.org — это отдельная организация, не связанная с ИИ.

Как же захотелось в Шанхай :)

Их сайт https://online2025.worldaic.com.cn у меня с компа не открылся :( вроде должна быть возможность платного участия, но онлайн.

Транскрибация аудио python на faster-whisper

Tue, 27 May 2025 22:15:27 +0300

Все достаточно легко

Подготовка

python3 -m venv ./whisper

Активация и установка этого https://github.com/SYSTRAN/faster-whisper

source ./whisper/bin/activate
pip install faster-whisper

Сам код

import sys
import os
import time
from faster_whisper import WhisperModel

# --- Конфигурация модели Whisper ---
model_size = "large-v3"
# Выберите свою конфигурацию:
# model = WhisperModel(model_size, device="cuda", compute_type="float16") # Если есть GPU и CUDA
# model = WhisperModel(model_size, device="cuda", compute_type="int8_float16") # Если есть GPU и CUDA с INT8
model = WhisperModel(model_size, device="cpu", compute_type="int8") # Для CPU (как в вашем примере)
# -----------------------------------

def transcribe_mp3_to_text(mp3_filepath):
    """
    Транскрибирует MP3 файл и сохраняет результат в текстовый файл.
    """
    if not os.path.exists(mp3_filepath):
        print(f"Ошибка: Файл MP3 не найден: {mp3_filepath}")
        return False

    if not mp3_filepath.lower().endswith(".mp3"):
        print(f"Ошибка: Файл '{mp3_filepath}' не является MP3 файлом. Пропускаем.")
        return False

    # Извлечение имени файла без расширения
    filename_without_ext = os.path.splitext(os.path.basename(mp3_filepath))[0]
    output_txt_filepath = os.path.join(os.path.dirname(mp3_filepath), f"{filename_without_ext}.txt")

    print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] Начинаем транскрипцию '{mp3_filepath}'...")
    print(f"Результат будет сохранен в '{output_txt_filepath}'")

    try:
        segments, info = model.transcribe(mp3_filepath, beam_size=5)

        detected_language_msg = f"Detected language: '{info.language}' with probability {info.language_probability:.2f}"
        print(detected_language_msg)

        # Сохранение транскрипции в текстовый файл
        with open(output_txt_filepath, 'w', encoding='utf-8') as f_out:
            f_out.write(f"--- Транскрипция для: {os.path.basename(mp3_filepath)} ---\n")
            f_out.write(f"{detected_language_msg}\n\n")
            
            full_text = [] # Для сбора всего текста, если нужно вывести в конце

            for segment in segments:
                segment_line = f"[{segment.start:.2f}s -> {segment.end:.2f}s] {segment.text}"
                print(segment_line) # Выводим в консоль для отладки
                f_out.write(f"{segment.text}\n") # Записываем только текст в файл, по сегментам
                full_text.append(segment.text)

            # Если вы хотите сохранить всю транскрипцию одним блоком в конце файла или отдельный файл
            # f_out.write("\n\n--- Полный текст ---\n")
            # f_out.write(" ".join(full_text))

        print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] Транскрипция успешно завершена! Результат в '{output_txt_filepath}'")
        return True

    except Exception as e:
        print(f"Ошибка при транскрипции файла '{mp3_filepath}': {e}")
        # Вы можете добавить логирование ошибки в отдельный файл, если нужно
        return False

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Использование: python process_mp3.py <путь/к/вашему/файлу.mp3>")
        sys.exit(1)

    mp3_file_path_arg = sys.argv[1] # Это будет полный путь к MP3 файлу, переданный из Automator/Bash
    transcribe_mp3_to_text(mp3_file_path_arg)

Итоги запуска

(whisper) (base) yuriygavrilov@MacBookPro fastwhisper % python whisp.py            
Detected language 'ru' with probability 0.998883
[0.00s -> 4.96s]  Раз, два, три, привет, как дела?
[5.94s -> 8.54s]  Все хорошо, а у тебя как?
[9.54s -> 10.78s]  И у меня все хорошо
[10.78s -> 12.98s]  Спасибо, пока
(whisper) (base) yuriygavrilov@MacBookPro fastwhisper %

тестовый файл тут

test.mp3

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

Буду делать через приложении на маке automator

Как то примерно так :)

осталось прикрутить это а действие к папке

кажись заработало :)

Создалась транскрипция сама

получилось в итоге вот так: Открываем Automator, настраиваем действие и все.

работает так: кидаем файл в папку тест, скрипт запускается, транскрипция появляется рядом. Все.

Проверим качество модели на этом:

AA_Cat_2025_v1.mp3

почти идеал 🤘

Второй раз чуть иначе, но почти точно.

Неплохое приложение для распознания голоса

Sun, 25 May 2025 23:17:46 +0300

Но только для мака и есть локальные модели

https://superwhisper.com

недавно появилось приложение для ИОС

https://apps.apple.com/us/app/superwhisper/id6471464415

Тестируем Suno 4.5 🎸🤘

Mon, 19 May 2025 08:29:28 +0300

В целом нейронка показывает себя достойно, почти как 4.0 но чуть качественнее и может создавать треки по 8 минут. 4 могла только до 4 минут.

Пара экспериментов

Жрецы данных :) 🤣🤘🎸

Priests_of_Data_(Жрецы_Данных)_2025_v24.mp3

А вот по заказу в стиле кровостока 🤣 от Александра Баракова, но пожалуй надо текст переписать

Priests_of_Data_(Жрецы_Данных)_2025_v25.mp3

Priests_of_Data_(Жрецы_Данных)_2025_v26.mp3

Другой текст 🙉

Priests_of_Data_(Жрецы_Данных)_2025_v46.mp3

Это то как нейронка понимает dmbok и предлагает исполнение, от себя я не добавлял ничего. Но был интересный опыт в первом промте я попросил нейронку дать рекомендации, не только для меня но и для другой нейронки. ( deepseek был первый, вторая flash 2.5 preview )

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

Анна Ахматова

AA_Cat_2025_v1.mp3

Ремикс на песню apologies onerepublic

Apologize_by_me_2025_v5.mp3

Кстати нейронка теперь лучше защищает авторские права, ее нельзя попросить спой как Киркоров, идет проверка по названиям треков и исполнителям. Но можно другую нейронку попросить переделать песню. Вот как например эта:

Этот трек переписала другая нейронка, но с сохранением смысла. Использовала Flash 2.5 preview.

Apologize_by_me_2025_v2.mp3

4.5 сейчас платная, стоит 10 $ в месяц
Еще в бесплатных версиях они начали портить чуть треки, что ты купил их.

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

В версии 4.5 появился функционал генерации кусочков, то есть если песня вам нравится, а только некоторые слова или окончание надо поправить, то это можно сделать. Заменить можно примерно любые 6 секунд.

Немного профильных треков:

The_One_S7_Community_analysts_BD_2025.mp3

Evolving_Data’s_Path_(Code_of_High)_2025_v12.mp3

Для сравнение этот трек сделан на версии 4.0:

EDP_2025.mp3

А тут немного личного :) такое нейронка пишет на после анализа чатов, ну почти 🙈🥹

In_the_Fog_of_Love_2025_v1.mp3

Все тексты делал тут: http://openrouter.ai в основном Gemini Flash 2.5 либо DeepSeek R1

Практическое руководство построения Агентов ИИ

Sun, 20 Apr 2025 14:09:40 +0300

Инструкция оригинал тут

Потом еще свой код покажу, но он работает в версии 1.65, надо бы обновить.

Документ представляет собой руководство по разработке автономных систем (агентов) на базе языковых моделей (LLM). Основные темы:

Определение агентов: системы, выполняющие задачи от имени пользователя с высокой степенью автономии.
Ключевые компоненты: модели LLM, инструменты (API, функции), инструкции, защитные механизмы (guardrails).
Оркестрация: подходы к управлению агентами (одиночные и мультиагентные системы).
Guardrails: механизмы безопасности для контроля рисков.
Практические рекомендации: выбор моделей, проектирование инструментов, обработка исключений, интеграция с людьми.

Ниже не полный перевод. Раздел Guardrails очень интересный!

Практическое руководство по созданию агентов

Автор: OpenAI

---

Содержание

Введение
Что такое агент?
Когда следует создавать агента?
Основы проектирования агентов
Выбор моделей
Определение инструментов
Конфигурация инструкций
Оркестрация
- 8.1. Системы с одним агентом
- 8.2. Мультиагентные системы
Защитные механизмы (Guardrails)
Заключение

---

1. Введение

Крупные языковые модели (LLM) становятся всё более способными решать сложные многошаговые задачи. Достижения в области логических рассуждений, мультимодальности и использования инструментов открыли новую категорию систем на базе LLM — агентов.

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

После прочтения вы узнаете:

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

---

2. Что такое агент?

Агенты — системы, которые самостоятельно выполняют задачи от имени пользователя.

Ключевые характеристики:

Использование LLM
- Управление рабочими процессами.
- Корректировка действий при ошибках.
Доступ к инструментам
- Взаимодействие с API, базами данных, внешними системами.

Примеры задач:

Обработка запросов в службе поддержки.
Бронирование ресторана.
Генерация отчётов.

Не являются агентами:

Простые чат-боты.
Системы без управления рабочими процессами.

---

3. Когда следует создавать агента?

Агенты подходят для задач, где традиционные правила и детерминированные системы неэффективны.

Сценарии для внедрения:

Категория	Примеры задач
Сложные решения	Одобрение возврата средств.
Сложные правила	Проверка безопасности поставщиков.
Неструктурированные данные	Анализ страховых случаев.

Перед созданием агента:

Убедитесь, что задача требует неоднозначных решений.
Если задача простая, используйте детерминированные методы.

---

4. Основы проектирования агентов

Агент состоит из трёх компонентов:

Компонент	Описание
Модель	LLM для логики и принятия решений.
Инструменты	API, базы данных, внешние системы.
Инструкции	Правила и ограничения поведения.

Пример кода (Agents SDK):

weather_agent = Agent(  
    name="Weather agent",  
    instructions="Вы помощник, который отвечает на вопросы о погоде.",  
    tools=[get_weather],  
)

---

5. Выбор моделей

Рекомендации:

Начните с самой мощной модели для базового уровня производительности.
Заменяйте её на более лёгкие модели, где это возможно.

Примеры задач:

Простые запросы → Маленькие модели (например, `gpt-3.5`).
Сложные решения → Мощные модели (например, `gpt-4`).

---

6. Определение инструментов

Инструменты расширяют возможности агентов через API.

Типы инструментов:

Тип	Примеры
Данные	Запросы к CRM, чтение PDF.
Действия	Отправка email, обновление CRM.
Оркестрация	Агент возвратов, исследовательский агент.

Пример кода:

search_agent = Agent(  
    name="Search agent",  
    instructions="Помогите пользователю искать в интернете.",  
    tools=[WebSearchTool(), save_results],  
)

---

7. Конфигурация инструкций

Рекомендации:

Используйте существующие документы (например, инструкции службы поддержки).
Разбивайте задачи на шаги.
Определяйте чёткие действия для каждого шага.
Учитывайте крайние случаи.

Пример генерации инструкций:

prompt = """  
Вы эксперт по созданию инструкций для агентов.  
Преобразуйте документ в нумерованный список без неоднозначностей.  
Документ: {{help_center_doc}}  
"""

---

8. Оркестрация

8.1. Системы с одним агентом

Один агент управляет всеми задачами.
Простота внедрения и обслуживания.

Пример работы:

await Runner.run(agent, [UserMessage("Столица США?")])

8.2. Мультиагентные системы

Менеджер-агент координирует специализированных агентов.
Децентрализованные агенты передают задачи друг другу.

Пример менеджер-агента:

manager_agent = Agent(  
    name="Менеджер переводов",  
    tools=[spanish_agent, french_agent],  
)

---

9. Защитные механизмы (Guardrails)

Цель: Предотвращение рисков (утечки данных, вредоносные запросы).

Типы защит:

Классификатор релевантности → Фильтрация не относящихся к делу запросов.
Фильтр PII → Защита персональных данных.
Модерация → Блокировка вредоносного контента.

Пример кода:

@input_guardrail  
async def churn_detection(ctx, input):  
    # Проверка риска оттока клиентов  
    ...

---

10. Заключение

Ключевые принципы:

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

Агенты открывают новые возможности для автоматизации сложных рабочих процессов.

OpenAI — компания, занимающаяся разработкой ИИ. Наша миссия — обеспечить, чтобы искусственный интеллект приносил пользу человечеству.

Свежее по классификации подвезли – mistral

Wed, 16 Apr 2025 23:08:56 +0300

🔥 Classifier Factory от Mistral

Classifier Factory — это интуитивно понятное руководство для создания и обучения собственных моделей классификации на базе компактных LLM от Mistral AI.

С его помощью — как через веб‑интерфейс La Plateforme, так и через API — можно быстро разворачивать решения для модерации контента, детекции намерений, анализа тональности, кластеризации данных, обнаружения мошенничества, фильтрации спама, рекомендательных систем и других задач

Таким образом, Classifier Factory упрощает весь цикл работы с custom‑классификаторами: от подготовки данных до развёртывания готовой модели в продакшене.

Еще они обнвоили доку.

🔜 Docs
🔜Cookbook: Moderation Classifier
🔜Cookbook: Intent Classification
🔜Cookbook: Classification of Food

@ai_machinelearning_big_data

#Mistral #api

Немного актуального про NPU чипы

Wed, 16 Apr 2025 21:43:53 +0300

https://habr.com/ru/companies/recognitor/articles/898152/

Как навести порядок в хаосе данных: стратегия для бизнеса

Tue, 15 Apr 2025 21:13:12 +0300

Любопытная статья про порядок и знания. Раньше к этому стремились большие компании, может даже инвестиционные, а сегодня это под силу даже мелким.

Основное это RAG, втаскивание смысловых значение и аккумулирование всего в виде FAQ.

https://telegra.ph/Kak-navesti-poryadok-v-haose-dannyh-strategiya-dlya-biznesa-03-31

chat.z.ai – три модельки open source

Tue, 15 Apr 2025 16:14:22 +0300

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

https://chat.z.ai/ – пробуем тут

https://bigmodel.cn/ – или тут

https://huggingface.co/collections/THUDM/glm-4-0414-67f3cbcb34dd9d252707cb2e или сами запускаем отсюда.

Zhipu AI открывает код своих моделей: в 8 раз быстрее конкурентов с уникальной технологией размышления

🔍 Что произошло?
Zhipu AI объявила о полном открытии кода своей технологической цепочки, включая:
• GLM-4-32B-0414 — базовая модель с улучшенной работой инструментов (код, поиск)
• GLM-Z1-32B-0414 — рекордная эффективность (аналог 671B модели на 32B параметрах)
• GLM-Z1-Rumination — первый ИИ с полным циклом исследования (поиск → анализ → проверка)

Также доступны облегчённые 9B-версии (GLM-4-9B-0414, GLM-Z1-9B-0414)

Все модели распространяются по лицензии MIT.

💡 Что умеет “Размышляющая” модель:

Самостоятельно ищет информацию
Анализирует данные
Проверяет гипотезы
Формирует выводы

Например, модель можно запросить сформировать отчет о рынке серверных операционных систем в Китае.

⚙️ Технические детали:
▸ Рекордная скорость генерации до 200 токенов/сек
▸ Сопоставимая с DeepSeek-R1 производительность при меньшем размере
▸ Поддержка HTML/CSS/JS/SVG с интерактивным выполнением кода прямо в чате
▸ Оптимизация для consumer-GPU (например, RTX 4090)
▸ Три версии API: скоростная, бюджетная и бесплатна

Такие модельки не сильно прожорливые и думаю вполне себе потянет такая железка OrangePi AIPro (20T) 24Гб за 40тс рублей https://onpad.ru/catalog/cubie/orange_pi/orage_pi/3698.html

AI да Китай

Вопрос: А и Б сидели на трубе, А упала Б пропала, кто остался на требе?

Ответ:

“А и Б сидели на трубе”: История, смысл и решение старинной русской загадки

Введение

Старинные русские загадки, передающиеся из уст в уста, представляют собой не только забавную головоломку, но и отражение народной мудрости, языковых тонкостей и культуры. Одна из самых известных и популярных загадок, которая流传 в русскоязычной среде, звучит так: “А и Б сидели на трубе, А упала, Б пропала, кто остался на трубе?” В данном исследовании我们将深入探讨 эту загадку, её происхождение, смысл и, конечно, правильный ответ.

История загадки

Загадка “А и Б сидели на трубе” имеет давнюю историю и является классическим примером языковой головоломки, которая проверяет внимательность и сообразительность. Она передаётся из поколения в поколение, оставаясь актуальной и популярной в русскоязычной культуре. Эта загадка относится к категории загадок, которые кажутся сложными на первый взгляд, но имеют простое решение, основывающееся на игре с языком.

Смысл загадки

Для понимания смысла загадки有必要 разобрать её по частям:

“А и Б сидели на трубе” – здесь подразумеваются три элемента: А, “и” (что в русском языке означает “и”), и Б.
“А упала” – подразумевает исчезновение или удаление первого элемента.
“Б пропала” – подразумевает исчезновение или удаление третьего элемента.
“Кто остался на трубе?” – вопрос, который задаётся для определения, что осталось после исчезновения А и Б.

Решение загадки

Правильный ответ на загадку “А и Б сидели на трубе, А упала, Б пропала, кто остался на трубе?” – это “и” (что в русском языке означает “и”).

Этот ответ можно объяснить следующим образом:

В оригинальной фразе “А и Б сидели на трубе” присутствуют три символа: А, “и”, Б.
Если А “упала” (то есть исчезла), а Б “пропала” (также исчезла), то на трубе остается только “и”.
В русском языке “и” – это отдельное слово, обозначающее “и”, и именно это слово остается на трубе после исчезновения А и Б.

Этот ответ подтверждается несколькими источниками:

“Согласно указанной загадке на трубе находилось три буквы – это а, и, б. Поскольку две буквы (а, б) с трубы куда-то пропали, то на трубе осталась только буква ‘и’.” [[11](https://uchi.ru/otvety/questions/a-i-b-sideli-na-trube-a-upalo-b-propalo-kto-ostalsya-na-trube)]
“Эта загадка связана с игрой букв(А,И,Б), а раз присутствует ИГРА БУКВ, то...” [[10](https://proza.ru/2016/10/06/1316)]

Вариации загадки

В русскоязычной культуре существуют различные вариации этой загадки, которые сохраняют её суть, но меняют детали:

“А, И, Б сидели на трубе. А упала. Б пропала. Кто остался на трубе?” [[10](https://proza.ru/2016/10/06/1316)]

“А и Б сидели на трубе. А упало, Б пропало, что осталось на трубе?” [[13](https://otvet.mail.ru/question/54546059)]

“А и Б сидели на трубе, А уехал за границу, Б чихнул и... кто остался на трубе?” [[15](https://uchi.ru/otvety/questions/a-i-b-sideli-na-trube-a-uehal-za-granitsu-b-chihnul-i-lyog-v-bolnitsu-kto-ostalsya-na-tru)]

Эти вариации демонстрируют гибкость загадки и её способность адаптироваться к разным контекстам, сохраняя при этом суть.

Языковые особенности

Эта загадка демонстрирует несколько интересных языковых особенностей русского языка:

Игра с буквами: Загадка основана на игре с отдельными буквами русского алфавита (А, И, Б).

Символическое представление: Каждая буква представляется как отдельное существо, которое может “сидеть”, “упасть” или “пропасть”.

Слогovость: Русский язык, будучи слоговым, позволяет такую игру с отдельными буквами, что делает загадку возможной.

Краткость и изящность: Ответ на загадку – всего одна буква “и”, что делает его особенно элегантным и удивительным.

Cultural context

Эта загадка отражает народную мудрость и любовь к языкознанию в русскоязычной культуре. Она часто используется для развития логического мышления и внимательности у детей, а также для развлечения взрослых. Загадка демонстрирует, как важны детали и как有时候 решение может быть проще, чем кажется.

Modern interpretations and references

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

В детских садах и школах её используют для развития языковых навыков
В интернет-форумах и социальных сетях она часто появляется в разделах с загадками
В некоторых видеороликах для детей эта загадка используется как образец традиционной русской головоломки [[12](https://www.youtube.com/watch?v=ZhVvZn6vkzc)]

Conclusion

Загадка “А и Б сидели на трубе, А упала, Б пропала, кто остался на трубе?” представляет собой яркий пример традиционной русской головоломки, основывающейся на игре с буквами. Её суть заключается в том, чтобы понять, что после исчезновения А и Б на трубе остаётся “и”. Этот простой, но изящный ответ демонстрирует тонкости русского языка и народной мудрости.

Эта загадка не только забавляет, но и развивает языковое мышление, что делает её ценным элементом русскоязычной культуры. Она напоминает нам о важности деталей и о том, как有时候 решение может быть проще, чем кажется.

References

[10] А и Б сидели на трубе... (Исаков Олег) / Проза.ру. https://proza.ru/2016/10/06/1316

[11] а и б сидели на трубе. а упало б пропало кто остался на трубе?. https://uchi.ru/otvety/questions/a-i-b-sideli-na-trube-a-upalo-b-propalo-kto-ostalsya-na-trube

[12] Считалочка – загадка – А и Б сидели на трубе – YouTube. https://www.youtube.com/watch?v=ZhVvZn6vkzc

[13] А и Б сидели на трубе А упала, Б пропала, что осталось на трубе?. https://otvet.mail.ru/question/54546059

[15] А И Б СИДЕЛИ НА ТРУБЕ А УЕХАЛ ЗА ГРАНИЦУ Б ЧИХНУЛ И ... https://uchi.ru/otvety/questions/a-i-b-sideli-na-trube-a-uehal-za-granitsu-b-chihnul-i-lyog-v-bolnitsu-kto-ostalsya-na-tru

Основные тезисы статьи “AI Index 2025: State of AI in 10 Charts

Wed, 09 Apr 2025 18:27:46 +0300

Оригинал: https://hai.stanford.edu/news/ai-index-2025-state-of-ai-in-10-charts

Основные тезисы статьи “AI Index 2025: State of AI in 10 Charts” :

Улучшение небольших моделей ИИ
- Модели с меньшим числом параметров достигают уровня крупных. Например, Microsoft Phi-3-mini (3.8 млрд параметров) в 2024 году показала результаты, сравнимые с моделью PaLM (540 млрд параметров) 2022 года. Это сокращение параметров в 142 раза за два года.

Снижение стоимости использования ИИ
- Стоимость обработки запросов для моделей уровня GPT-3.5 упала с $20 до $0.07 за миллион токенов (снижение в 280 раз за 18 месяцев). Цены на оборудование снижаются на 30% ежегодно, а энергоэффективность растет на 40%.

Китай сокращает разрыв с США
- США создали 40 значимых моделей ИИ в 2024 году, Китай — 15. Однако разрыв в качестве между американскими и китайскими моделями сократился до минимума на тестах MMLU и HumanEval. Китай лидирует по публикациям и патентам в области ИИ.

Рост проблемных инцидентов с ИИ
- Зафиксировано 233 инцидента, связанных с ИИ (+56.4% за год), включая дипфейки и случаи кибербуллинга.

Прогресс ИИ-агентов
- В коротких задачах (2 часа) ИИ превосходит людей в 4 раза, но при увеличении времени до 32 часов люди демонстрируют вдвое лучшие результаты.

Рекордные инвестиции в ИИ
- 78% компаний внедрили ИИ в 2024 году (рост с 55% в 2023). Частные инвестиции США составили $109.1 млрд, Китая — $9.3 млрд.

Медицинские устройства с ИИ
- FDA одобрило 223 ИИ-устройства в 2023 году против 6 в 2015.

Регуляторная активность в США
- Число законов штатов, связанных с ИИ, выросло до 131 в 2024 году (в 2016 — 1).

Региональный оптимизм
- В Китае, Индонезии и Таиланде более 77% населения видят в ИИ больше пользы, чем вреда. В США, Канаде и Нидерландах этот показатель ниже 40%.

Глобализация разработки ИИ
- Модели создаются в новых регионах: Ближний Восток, Латинская Америка, Юго-Восточная Азия.

---

Синтез

Статья демонстрирует динамичное развитие ИИ в 2024 году:

Технологический прогресс: Малые модели стали эффективнее, а стоимость их использования резко снизилась, что делает ИИ доступнее .
Интеграция в общество: ИИ активно применяется в медицине, транспорте (например, 150 тыс. поездок Waymo в неделю) и бизнесе, где 78% компаний используют технологии для повышения продуктивности .
Инвестиции и геополитика: США сохраняют лидерство, но Китай усиливает позиции. Глобальные инвестиции в генеративный ИИ достигли $33.9 млрд .
Этические вызовы: Рост инцидентов и нехватка стандартов оценки безопасности ИИ требуют усиления регулирования. Правительства, включая ЕС и ООН, разрабатывают новые рамки .

---

Выводы

Доступность и эффективность ИИ растут, но сохраняется разрыв между регионами в инфраструктуре и образовании (например, 81% учителей в США не готовы преподавать ИИ) .
Регулирование отстает от технологий: несмотря на рост законов, стандарты оценки рисков остаются редкими .
Оптимизм vs. скептицизм: В Азии выше доверие к ИИ, тогда как на Западе преобладают опасения, связанные с этикой и заменой рабочих мест .
Будущее за гибридными решениями: ИИ-агенты уже превосходят людей в узких задачах, но для сложных когнитивных процессов требуется симбиоз с человеком .

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