Yuriy Gavrilov: posts tagged LLM

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/

Анализ: 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

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

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

Китайская виртуализация Openscaler и RISC-V

Fri, 04 Apr 2025 22:09:46 +0300

Тестирование производительности решений контейнерной виртуализации — https://openscaler.ru/2023/06/21/1125/

Второй подход к снаряду, iSula
https://openscaler.ru/2023/10/12/secont-test-isula/

Тестирование запуска контейнеров внутри виртуальных машин в кластере kubernetes
https://openscaler.ru/2024/02/19/isulad-kata-k8s/

Обновление ОС рабочих узлов кластера k8s при помощи KubeOS
https://openscaler.ru/2024/05/24/kubeos_kubevirt/

Rubik – ещё один способ управления ресурсами в kubernetes
https://openscaler.ru/2024/11/01/rubik/

Kmesh и k8s — https://openscaler.ru/2023/12/12/kmesh-and-k8s/

Kuasar – runtime с поддержкой sandbox — https://openscaler.ru/2025/02/17/kuasar/
Тестирование контейнерной ОС на основе кодовой базы openEuler / OpenScaler — https://openscaler.ru/2023/07/27/nestos/

А еще это:
Побег из технологической клетки США. Китай создал первый серверный процессор на RISC-V на замену Intel Xeon и AMD Epyc https://www.cnews.ru/news/top/2025-04-04_kitaj_sbegaet_iz_tehnologicheskogo

https://www.securitylab.ru/news/558028.php или читаем в оригинале тут: https://www.tmtpost.com/7519579.html

Но интересно это: “Процессор Lingyu построен по интересной схеме: в нём объединены 32 универсальных ядра для вычислений и 8 специализированных интеллектуальных ядер. Такая конфигурация хорошо подходит, например, для запуска моделей вроде ChatGPT с открытым исходным кодом, и при этом позволяет сдерживать энергопотребление и общую стоимость владения”

Но и это любопытно тоже:
https://tenstorrent.com

Tenstorrent представила ИИ-ускорители Blackhole на архитектуре RISC-V

Канадский стартап Tenstorrent анонсировал ИИ-ускорители семейства Blackhole, выполненные в виде двухслотовых карт расширения с интерфейсом PCI Express 5.0 x16. Кроме того, дебютировала рабочая станция TT-QuietBox, оборудованная этими изделиями. Напомним, ранее Tenstorrent выпустила ИИ-ускорители Wormhole с 72 и 128 ядрами Tensix, каждое из которых содержит пять ядер RISC-V. Объём памяти GDDR6 составляет соответственно 12 и 24 Гбайт. Производительность достигает 262 и 466 Тфлопс на операциях FP8. Для сравнения A100 дает 624 до 1248 если SXM. Но дело все в цене, которая в десятки раз ниже.

Кстати, мы используем аналог Trino, это CedrusData, он на Java. Учитывая тот факт, что там используется Temurin java, которая имеется для архитектуры risc-v, то можно сказать – мимиграция ядер не за горами.

а есть и российская java для рисков https://www.axiomjdk.ru/announcements/2024/12/11/risc-v/ от Axiom

ждем )

Тестируем Гуся 🪿

Tue, 01 Apr 2025 23:10:03 +0300

an open source, extensible AI agent that goes beyond code suggestions – install, execute, edit, and test with any LLM

смотрим, все понятно.

Ваш браузер не поддерживает видео.

Основной их сайт: https://block.github.io/goose/
Взять можно тут: https://github.com/block/goose
или еще почитать тут: https://habr.com/ru/articles/877522/

Вот, что сделал:

или тут файлы: Goose_App.zip

Небольшой сайт, что выше
Скачал версию на Мак
Настроил на openrouter.ai
Выбрал сеть Sonnet 3.5 ( Есть и другие, но эта первая попалась )
Поставил режим режим апрува Goose Mode: Smart Approval
Рабочая директория /Users/yuriygavrilov/NeDir

Промт:

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

Ответ:

Я помогу вам модифицировать и запустить программу. Давайте выполним это пошагово.

Сначала найдем и остановим запущенную программу:
Shell
command
ps aux | grep python | grep uvicorn

Output
Shell
command
pkill -f uvicorn

Output
Goose would like to call the above tool. Allow?
Shell is approved
Теперь посмотрим текущий код:
Shell
command
rg --files | rg '\.py$'

Output
Text Editor
command
view
path
/Users/yuriygavrilov/NeDir/app.py

Output
Создадим новый HTML шаблон с красивым дизайном:
Shell
command
mkdir -p templates static/images

Output
Goose would like to call the above tool. Allow?
Shell is approved
Создадим обновленный HTML файл:
Text Editor
command
write
file_text
<!DOCTYPE html> <html lang="ru"> <head> <meta charset="U...

path
/Users/yuriygavrilov/NeDir/templates/index.html

Output
Goose would like to call the above tool. Allow?
Text Editor is approved
Создадим SVG изображение самолета:
Text Editor
command
write
file_text
<?xml version="1.0" encoding="UTF-8"?> <svg width="800px" he...

path
/Users/yuriygavrilov/NeDir/static/images/airplane.svg

Output
Goose would like to call the above tool. Allow?
Text Editor is approved
Установим необходимые зависимости:
Shell
command
pip install flask flask-talisman pyOpenSSL

Output
Goose would like to call the above tool. Allow?
Shell is approved
Запустим программу в фоновом режиме:
Shell
command
python app.py &

Output
Goose would like to call the above tool. Allow?
Shell is approved
Теперь вы можете открыть программу в браузере по адресу: https://localhost:5000

Что было сделано:

Остановлена предыдущая версия программы
Создан новый дизайн с красной кнопкой
Добавлено исчезающее приветствие (появляется на 3 секунды при нажатии на кнопку)
Добавлен зеленый самолет
Настроен SSL сертификат (самоподписанный)
Программа запущена в фоновом режиме
При открытии в браузере вы увидите:

Красивый градиентный фон
Красную кнопку в центре
Полупрозрачный зеленый самолет на фоне
При нажатии на кнопку появится приветствие, которое исчезнет через 3 секунды
Примечание: Поскольку используется самоподписанный SSL-сертификат, браузер может показать предупреждение о безопасности. Это нормально в тестовой среде. Чтобы продолжить, нужно подтвердить исключение безопасности в браузере.

Жду ваших дальнейших инструкций!

🤖 Ай да Гусь :) но самолета не вижу почему то. А денег съела прилично где-то 80 центов за пару тестов.

Еще не то увидим, когда заработает MCP повсюду.

Внедрение и оптимизация Apache DolphinScheduler в NetEase Mail

Sun, 30 Mar 2025 21:21:55 +0300

Перевод: Внедрение и оптимизация Apache DolphinScheduler в NetEase Mail

Оригинал: https://apachedolphinscheduler.substack.com/p/netease-mails-migration-journey-to

В связи с бурным развитием Интернета, электронная почта — один из важнейших инструментов обмена информацией — испытывает постоянно растущий спрос на обработку данных и планирование задач. NetEase Mail, ведущий поставщик услуг электронной почты в Китае, внедрил платформу DolphinScheduler, чтобы лучше справляться с задачами обработки огромных объемов данных и планирования задач. Компания провела углубленное внедрение и оптимизацию платформы в реальных условиях эксплуатации.

Докладчик:

Лэй Баосинь, инженер больших данных NetEase Mail

Предпосылки проекта и выбор платформы

NetEase Mail – это ведущий китайский поставщик услуг электронной почты, являющийся частью крупной интернет-компании NetEase. Вот основные характеристики и информация о компании:

* Широкая линейка продуктов: NetEase Mail предлагает разнообразные почтовые услуги, включая:
* Бесплатная почта: Наиболее известные сервисы 126.com и 163.com, хорошо известные в Китае.
* Корпоративная почта: Предназначена для бизнеса, предлагая более надежные и профессиональные решения.
* VIP-почта: Почтовые сервисы премиум-класса с расширенными функциями и поддержкой.
* Долгая история: Существует с 1997 года, что говорит о стабильности и накопленном опыте.
* Огромная база пользователей: Благодаря популярности сервиса в Китае, NetEase Mail обслуживает миллионы пользователей.
* Технологическая зрелость: NetEase Mail активно использует современные технологии (например, Kubernetes, Apache DolphinScheduler и Streampark) для обработки больших объемов данных, планирования задач и улучшения общей эффективности.
* Ориентация на стабильность и безопасность: Компания уделяет большое внимание предоставлению стабильных, безопасных и эффективных почтовых услуг.
* Инновационное развитие: NetEase Mail постоянно совершенствует свои сервисы, внедряя новые функции, интегрируя искусственный интеллект и оптимизируя инфраструктуру.
* Вклад в opensource: NetEase Mail активно контрибьютит в open-source проекты, например, SeaTunnel, что говорит об их технической экспертизе и желании делиться разработками с сообществом.

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

История развития NetEase Mail

С момента запуска в 1997 году, NetEase Mail прошла несколько важных этапов развития, эволюционировав от 126 Mail, 163 Mail до Mail Master, постоянно расширяя линейку продуктов и спектр услуг. Сегодня NetEase Mail создала диверсифицированную бизнес-систему, включающую бесплатную почту, корпоративную почту, VIP-почту и многое другое, предоставляя стабильные, безопасные и эффективные услуги электронной почты огромному количеству пользователей.

*Из рисунка выше видно, что NetEase Mail внедрила Apache DolphinScheduler в 2023 году.*

Сценарии применения данных

В ежедневной работе NetEase Mail необходимо обрабатывать огромные объемы данных журналов бизнес-операций. Эти данные требуют постоянного холодного и горячего резервного копирования в течение более полугода, а журналы бизнес-операций обрабатываются и хранятся отдельно как в автономном режиме (HDFS), так и в режиме реального времени (ClickHouse). В то же время, для обеспечения доступности бизнеса, критически важные звенья, такие как основные механизмы отправки/получения электронной почты и аутентификации пользователей, требуют эффективной обработки данных и поддержки планирования задач.

Предпосылки выбора и преимущества DolphinScheduler

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

Развертывание платформы и текущее использование

Путь обновления и преобразования на основе DS

После внедрения платформы DolphinScheduler, команда NetEase Mail встала на путь непрерывной оптимизации и обновления. Начиная с предварительных исследований и сравнений при выборе платформы, затем решая проблемы, возникающие в процессе использования, и, наконец, выполняя вторичную разработку для постоянного улучшения простоты использования и пользовательского опыта, команда неустанно двигалась к совершенствованию платформы. После подтверждения выбора в марте 2023 года, первоначальная трансформация на основе функциональности оповещения была завершена в декабре 2023 года, а к марту 2024 года была достигнута стабильная работа и продолжающиеся исследования.

Архитектура данных и текущее использование

В настоящее время в отделе NetEase Mail платформа DolphinScheduler развернута в архитектуре 3 Master, 5 Worker и работает на Kubernetes (k8s). Платформа поддерживает более 1200 автономных задач планирования для таких сервисов, как защита от спама, контроль рисков, AI и многого другого, с ежедневным количеством запусков, превышающим 50 000.

*На уровне архитектуры данных, благодаря интеграции DolphinScheduler с Streampark, было достигнуто сочетание автономного планирования и обработки задач Flink в режиме реального времени. Между тем, самостоятельно разработанные компоненты, такие как центр метаданных и портал данных, формируют уровень обслуживания данных, обеспечивая поддержку управления данными и сервисов.*

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

Типы задач и поддержка приложений

Платформа DolphinScheduler стала основной платформой планирования задач внутри отдела, предлагая широкий спектр типов задач, включая Spark, Shell, SQL, SeaTunnel, Python и многое другое. Эти задачи обеспечивают надежную поддержку данных для нисходящих приложений, таких как управление метаданными, отчеты BI и исследования и разработки данных, удовлетворяя потребности в обработке данных в различных бизнес-сценариях.

Интеграция функциональности распространения данных и методы оптимизации

Интеграция функциональности распространения данных

Что касается планирования и распространения данных, команда NetEase Mail выявила несколько проблем, которые необходимо было решить для повышения эффективности и возможностей обработки данных, в том числе:

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

Чтобы решить эти проблемы, команда NetEase Mail интегрировала функциональность распространения данных в платформу DolphinScheduler.

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

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

В результате внедрения этой функциональности среднее время обработки промежуточных данных сократилось с 1 часа до 20 минут, что увеличило эффективность разработки на 67%, и она уже поддерживает более 40 онлайн-задач обработки данных, при этом количество пользователей постоянно растет.

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

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

Чтобы решить эту проблему, команда переработала логику обработки сигналов ожидания и сбоев в методе getModelDependResult класса DependentExecute в модуле dolphinscheduler-master. Когда статус зависимой задачи — FAILED, статус в dependResultList изменяется на WAITING, чтобы нижестоящие задачи получали статус WAITING, а не FAILED.

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

Интеграция и оптимизация компонентов SeaTunnel, повышение эффективности синхронизации данных

Чтобы удовлетворить потребности в крупномасштабной синхронизации данных для нового бизнеса, команда внедрила инструмент интеграции данных SeaTunnel и развернула его в кластере Kubernets (k8s) в режиме разделенного кластера.

За счет оптимизации плагинов SeaTunnel NetEase Mail предлагает как пользовательские, так и быстрые режимы конфигурации, тем самым снижая порог использования.

Принцип реализации

С точки зрения реализации, решение поддерживает как конфигурацию на основе форм, так и пользовательскую конфигурацию. Режим конфигурации на основе форм генерирует логику взаимодействия для конфигурации SeaTunnel (ST) через параметры формы и поддерживает конфигурацию дополнительных пользовательских параметров, а также конфигураций JVM на уровне задач.

Бэкэнд получает параметры формы для генерации необходимой конфигурации для контекста выполнения задачи. Он разрабатывает интерфейс IConfigGenerator для реализации логики генерации Source и Sink для каждого источника данных, и, наконец, класс SeatunnelConfigGenerator используется для генерации окончательной конфигурации ST.

Развертывание и настройка

Что касается развертывания и настройки, то кластер SeaTunnel использует архитектуру 2 Master, 5 Worker для обеспечения высокой доступности и производительности синхронизации.

За счет оптимизации логики сегментирования для HDFS, HIVE и MultiTable Source, считыватель получает более сбалансированные сегменты, что повышает производительность синхронизации данных. Соответствующие оптимизации были отправлены в виде PR в сообщество.

С точки зрения настройки параметров, в ответ на требование крупномасштабной синхронизации данных из HDFS в Doris, после исследования и настройки параметров кода DorisSink была достигнута скорость передачи данных в 2 миллиона записей в секунду, что значительно повысило производительность синхронизации данных.

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

Эффективная миграция задач с платформы Mammoth на DolphinScheduler

Платформа Mammoth – это программное обеспечение платформы больших данных, разработанное для внутреннего использования в NetEase Group, и некоторые зависимости между задачами Mammoth очень сложны, требуя анализа и организации. Если это делать вручную, эффективность будет низкой, и, вероятно, возникнут пропуски или ошибки.

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

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

Исходя из различных соображений, после обсуждения и исследований NetEase Mail решила принять решение об автоматизированном решении синхронизации. Это решение автоматически собирает метаданные задач и lineage задач со старой платформы, преобразует их в формат конфигурации задач платформы Dolphin и одновременно добавляет зависимости задач. Наконец, рабочие процессы быстро создаются через интерфейс Dolphin. Для достижения этого процесса NetEase Mail использовала инструмент синхронизации PyDolphinScheduler, официально предоставляемый DolphinScheduler — Python API, который позволяет определять рабочие процессы с использованием кода Python, а именно, “workflow as code”.

Кроме того, NetEase Mail также собирала метаданные и lineage задач Mammoth через систему метаданных, пакетно переписывала задачи Mammoth в задачи DolphinScheduler и автоматически добавляла узлы зависимостей в соответствии с lineage.

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

Практика изоляции групп Worker

Следующая практика проекта — это практика изоляции ресурсов на основе группировки Worker в DolphinScheduler.

В повседневном использовании платформы NetEase Mail DolphinScheduler ключевым бизнес-сценарием является поддержка задач планирования онлайн-мониторинга QA. Эти задачи характеризуются высокой частотой планирования, в основном на уровне минут; существует большое количество задач, при этом количество задач, связанных с мониторингом, в настоящее время достигает 120+.

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

Однако этот вид вызова запустит множество процессов JVM на рабочих узлах (worker nodes). В это время, если некоторые критически важные задачи планирования также запланированы на тот же рабочий узел, и OOM killer запускается из-за нехватки памяти, эти критически важные задачи, как правило, имеющие более высокое использование памяти, могут получить более высокий балл OOM и с большей вероятностью будут завершены, что приведет к нестабильному выполнению критически важных задач.

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

Поэтому команда NetEase Mail рассматривала возможность использования решения для изоляции Worker group для решения вышеуказанных проблем.

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

На практике NetEase Mail создала на платформе различные группы Worker, содержащие различные узлы Worker, включая такие группы, как Default, AI, Monitoring, Hadoop и группы задач с большими ресурсами, чтобы избежать проблем блокировки задач и состязания за ресурсы, оптимизировать распределение ресурсов и повысить общую утилизацию ресурсов и производительность платформы.

Эта практика эффективно решила такие проблемы, как блокировка задач, вызванная высокой частотой планирования задач мониторинга QA, и проблемы OOM узла worker, вызванные высоким запросом ресурсов задачами Т+1 рано утром, тем самым снизив операционные риски.

Итоги и перспективы

Резюме практики

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

Значение и преимущества платформы

Платформа DolphinScheduler играет важную роль в бизнесе NetEase Mail. Она не только повышает эффективность и стабильность разработки данных, но и удовлетворяет разнообразные потребности бизнеса за счет оптимизированных процессов планирования задач, обеспечивая своевременный вывод данных и активно способствуя устойчивому развитию почтового бизнеса.

Обмен опытом и идеями

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

Перспективы на будущее

Заглядывая в будущее, команда NetEase Mail планирует продолжить изучение и продвижение в следующих направлениях:

Внедрение ИИ:** Интеграция возможностей ИИ и LLM для достижения более интеллектуальных и удобных для пользователя процессов ETL обработки данных, повышая уровень автоматизации и интеллектуализации обработки данных.
Управление данными:** Интеграция данных планирования DolphinScheduler с внутренним центром метаданных для достижения интеллектуального сбора и анализа lineage данных/задач и карт данных, обеспечивая сильную поддержку управления данными.
Оптимизация платформы:** Дальнейшая оптимизация производительности и функциональности платформы DolphinScheduler для повышения ее стабильности и надежности, что позволит лучше удовлетворять растущие потребности в обработке данных.
Внедрение DATA OPS:** Достижение интеграции и консолидации между платформой DolphinScheduler и другими системами платформ данных, содействие автоматизации интеграции и передачи данных, а также построение более эффективной экосистемы данных.

В заключение

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

AI да Зайка 🐰 – Trino 474

Wed, 26 Mar 2025 01:06:29 +0300

Тестируем AI функции в Trino 474

Дока тут: https://trino.io/docs/current/functions/ai.html

Заводим конектор llm.properties

connector.name=ai
ai.provider=openai
ai.model=gpt-4o-mini
ai.openai.api-key=sk-XXXXXXa
ai.openai.endpoint= https://api.XXXXX/openai

немного конфига config.properties

sql.path=llm.ai

Пробуем:

SELECT ai_analyze_sentiment('Ai да заяц какой умный как утка только отруби не есть'); -- mixed
SELECT ai_analyze_sentiment('Ai да заяц какой умный'); -- positive

SELECT ai_classify('Buy fucking deep! and bitcoin', ARRAY['spam', 'not spam']); -- spam
-- spam

SELECT ai_classify('много денег', ARRAY['Хорошо', 'Плохо']); -- Хорошо

SELECT ai_classify('мало денег', ARRAY['Хорошо', 'Плохо']); -- Плохо

SELECT ai_fix_grammar('Пошёл я, значица, на рынок, там нашол один такой магазинчег, где продают всякие запчасти. Думал, прикуплю видюху крутую, чтобы всё летало. Смотрю - лежыт такая, блестит, вся из себя навороченая. Спрашиваю продавца: "Скока стоит эта красота?" А он мне такой цену заломил, у меня глаза на лоб полезли.');
-- Пошёл я, значит, на рынок, там нашёл один такой магазинчик, где продают всякие запчасти. Думал, прикуплю крутую видеокарту, чтобы всё летало. Смотрю - лежит такая, блестит, вся из себя навороченная. Спрашиваю продавца: "Сколько стоит эта красота?" А он мне такую цену назвал, что у меня глаза на лоб полезли.

SELECT ai_gen('Опиши что такое Москва коротко'); 
-- Москва — столица и крупнейший город России, расположенный в центральной части страны. Это политический, экономический и культурный центр, известный своими историческими памятниками, такими как Кремль и Красная площадь, а также современными skyscrapers. Город обладает развитой инфраструктурой, включая транспортную сеть, образовательные учреждения и театры. Москва также является одним из крупнейших мегаполисов мира с разнообразной культурой и многонациональным населением.

SELECT ai_mask(
    'Позвони мне быстро 987 554 32 11 или приходи ул. ленина 43 кв. 32,  скажи, что от Гаврилова Юры',
    ARRAY['телефон', 'Адрес',  'Имя']);
-- Позвони мне быстро [MASKED] или приходи [MASKED], скажи, что от [MASKED]

SELECT ai_translate('Буря мглою небо кроет,
Вихри снежные крутя;
То, как зверь, она завоет,
То заплачет, как дитя,
То по кровле обветшалой
Вдруг соломой зашумит,
То, как путник запоздалый,
К нам в окошко застучит.', 'en');

/*
The storm covers the sky with gloom,  
Whirling snowstorms twist and turn;  
Now, like a beast, it howls,  
Now it cries like a child,  
Now on the dilapidated roof  
Suddenly rustles with straw,  
Now, like a late traveler,  
It knocks at our window.
*/


SELECT name, address,comment, ai_classify(comment, ARRAY['Хорошо', 'Плохо', 'Можно помочь']), ai_translate(comment, 'ru') FROM tpch.sf1000.customer limit 10;

Customer#037500001rLbDxR0mC,PwQ5QkxWCfXCCtes; slyly regular pearls cajole quicklПлохолжем; хитро обычные жемчужины уговаривают быстро
Customer#0375000020bZ7K57TnmFs9goL41xTB64xBTLuXPtGPNunusual, ironic pinto beans haggle across the regular reqПлохонеобычные, ироничные пинто фасоль торгуются по обычному запросу
Customer#0375000035QliQMqzyzietly. deposits nag sometimes according to the even deposits. fПлохотихо. депозиты иногда зависят от равномерных депозитов. f
Customer#037500004FMm4JPC9UUSTOdfsfnect; slyly even packages haggle. pending instПлохождут; хитро даже пакеты торгуются. в ожидании инст
Customer#037500005a CUUBM75af0IX66Jmunts are bold, unusual packages. fluffily unusual foxes nag furiously even depositsПлохоУнцы — это смелые, необычные пакеты. Пухово-необычные лисы яростно требуют даже депозиты.
Customer#037500006VoXTOweLVJuiKe7xcn K69l7RoN61,ar pinto beans haggle blithely. Можно помочьФасоль "пинто" торгуются беззаботно.
Customer#037500007fUoQ2Fkssi94OhGGE1UetR wages hang blithely among the slyly ruthless accounts. carefully penПлоховозрасты беззаботно свисают среди хитро безжалостных счетов. осторожно пишите
Customer#037500008xogtDxejUq slyly special dependencies use quickly throughout the blithely stealthy accounts. dependМожно помочьЛукавые специальные зависимости используются быстро на протяжении безмятежных скрытных отчетов. зависеть
Customer#037500009ou,BZuF,BMMeEoSUgyODRQZFQJyIsFQMSWpen requests maintain. carefully ironic requests sleep carefullПлохозапросы поддерживают. осторожно ироничные запросы спят осторожно
Customer#037500010lcP8JaVg2dzy final packages. accounts along the quietly ironic ideas nag carefully idly express requests. requests detect ПлохоИтоговые пакеты. учетные записи вдоль тихо ироничных идей настойчиво и бездумно выражают запросы. запросы обнаруживают

При тестировании ни один заяц не пострадал, но вот hive и iceberg пришлось зарубить, там новые параметры для конфига. Так,что. придется их изучить при обновлении на новые версии, старые работать не будут.

а каталог iceberg я добавил так в итоге

connector.name=iceberg
fs.native-s3.enabled=true
s3.endpoint=https://gateway.storjshare.io
s3.region=us1
hive.metastore.uri=thrift://metastore:9083
hive.metastore.username=trino
hive.metastore.thrift.client.connect-timeout=1m
s3.path-style-access=true
s3.aws-access-key=XXXXX
s3.aws-secret-key=CCCCCCCCC
s3.socket-read-timeout=1m

iceberg.file-format=PARQUET
iceberg.compression-codec=SNAPPY
iceberg.target-max-file-size=128MB

но еще заметил эту багу https://github.com/trinodb/trino/issues/25427

Состояние больших языковых моделей (LLM) с открытым исходным кодом – Open Pioneers #32

Tue, 25 Mar 2025 22:40:55 +0300

перевод: https://www.openpioneers.com/p/the-state-of-open-source-llms

С возвращением в Open Pioneers #32.

Прошло несколько месяцев с момента моей последней рассылки. Жизнь и работа в Linux Foundation занимали много времени, но я поставил перед собой цель снова писать еженедельно, начиная с этого момента.

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

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

Тем не менее, я очень рад снова начать это делать. В сфере открытого исходного кода происходит так много интересного, и я с нетерпением жду возможности продолжать узнавать об этом вместе с вами!

Состояние открытых больших языковых моделей (LLM)

Большие языковые модели (LLM) с открытым исходным кодом превратились из нишевых академических проектов в устойчивые, управляемые сообществом платформы, которые бросают вызов проприетарным гигантам, таким как Microsoft или Google. Сегодня LLM с открытым исходным кодом не только способствуют прозрачности и сотрудничеству, но и обеспечивают более экономичный и адаптируемый подход к разработке искусственного интеллекта.

Новая эра товарного ИИ

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

Последние разработки показали потенциал LLM с открытым исходным кодом. Например, китайская модель R1 от DeepSeek привлекла всеобщее внимание, поскольку она соответствует характеристикам ведущих моделей, таких как o1 от OpenAI, при этом обучаясь за небольшую часть стоимости и вычислительной мощности. Использование DeepSeek обучения с подкреплением и архитектуры “смесь экспертов” позволяет ей активировать только подмножество из своих 671 миллиарда параметров на запрос, тем самым снижая энергопотребление и требования к оборудованию.

Преимущества и проблемы LLM с открытым исходным кодом

LLM с открытым исходным кодом предлагают несколько убедительных преимуществ:

Прозрачность и доверие:** Благодаря общедоступным данным обучения, исходному коду и весам моделей, LLM с открытым исходным кодом позволяют проводить тщательную проверку, что делает их менее “черным ящиком” по сравнению с проприетарными аналогами. Эта прозрачность приводит к доверию сообщества и совместному устранению неполадок.
Низкие затраты:** Модели с открытым исходным кодом снижают барьер для входа. Экономическая эффективность открытого исходного кода особенно выгодна для академических учреждений и стартапов с ограниченными ресурсами – другими словами: это способствует инновациям.
Настройка и гибкость:** Открытый доступ означает, что разработчики могут точно настраивать модели для нишевых приложений, интегрировать знания, специфичные для конкретной области, или даже адаптировать модели для местных языков – ключевое соображение для таких инициатив, какOpenEuroLLM, которая стремится обслуживать языковое разнообразие Европы.

Однако остаются и проблемы. LLM с открытым исходным кодом могут быть уязвимы для атак с использованием состязательных методов, и качество доступных данных обучения может варьироваться. Более того, хотя открытые модели способствуют инновациям, они также поднимают вопросы об ответственном использовании, поскольку мощные инструменты ИИ в чужих руках могут привести к злоупотреблениям. Баланс между открытостью и безопасностью – это продолжающийся разговор внутри сообщества, к которому мы должны отнестись серьезно.

Ключевые LLM с открытым исходным кодом, о которых вам следует знать

Ниже приведен снимок текущего ландшафта открытого исходного кода, согласно таблице лидеров Hugging Face Open LLM.

Следующие LLM с открытым исходным кодом выделяются для меня, потому что они очень часто смешиваются и сочетаются более широким сообществом ИИ:

Llama 3.1 (Meta):** Серия Llama 3.1 от Meta — от небольших моделей до массивной версии с 405 млрд параметров — неизменно занимает высокие позиции в области генерации общего текста, многоязыковой обработки и задач кодирования.
Mistral Large 2 (Mistral AI):** Благодаря мощной архитектуре с 123 миллиардами параметров и впечатляющему контекстному окну (до 128 тысяч токенов), Mistral Large 2 превосходно справляется как с пониманием языка, так и с задачами кодирования. Его разреженная конструкция “смесь экспертов” оптимизирует производительность при одновременном снижении затрат на вывод, что делает его лидером в эффективности и масштабируемости.
DeepSeek R1 (DeepSeek):** Модель R1 от DeepSeek использует обучение с подкреплением и подход “смесь экспертов” для обеспечения конкурентоспособных возможностей рассуждения, математики и кодирования. Хотя DeepSeek предположительно использует менее сложное оборудование по сравнению со своими западными конкурентами (в США действует запрет на экспорт в Китай графических процессоров Nvidia), он достигает высокой производительности при небольшой доле затрат на обучение. Этот факт привел к множеству обсуждений, в том числе и в основных СМИ.
DeepSeek v3 (DeepSeek):** Основываясь на серии R1, DeepSeek v3 использует архитектуру Mixture-of-Experts с 671 миллиардом параметров – с 37 миллиардами активированных параметров на токен – для обеспечения впечатляющей эффективности при генерации общего текста, многоязычной обработке и задачах кодирования.
Qwen 2.5 (Alibaba):** Qwen 2.5 от Alibaba произвел фурор благодаря своим сильным многоязычным возможностям, специализированной производительности в области кодирования и математических рассуждений, а также эффективным стратегиям развертывания. Его компоненты с открытым исходным кодом выпущены под лицензией Apache 2.0.
Falcon-180B (Technology Innovation Institute):** Модель Falcon-180B является свидетельством возможностей крупномасштабных LLM с открытым исходным кодом. Обученная на более чем 3,5 триллионах токенов, она обеспечивает первоклассную производительность по множеству тестов, что делает ее одной из самых конкурентоспособных доступных альтернатив с открытым исходным кодом. ( Вам потребуется примерно 8 видеокарт A100 с 80 ГБ памяти или эквивалентное оборудование для запуска этой модели )

Перспективы

Поскольку инвестиции в ИИ с открытым исходным кодом продолжают расти, такие игроки отрасли, как Meta, и общественные инициативы по всей Европе и за ее пределами удваивают ставки на потенциал совместной разработки ИИ. Благодаря тому, что компании выпускают свои модели под разрешительными лицензиями и делятся подробными техническими деталями и тестами, экосистема LLM готова к быстрым изменениям.

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

Я думаю, что это будущее только началось.

Новые и популярные проекты с открытым исходным кодом 🔥

Second Me:** Прототип с открытым исходным кодом, где вы создаете своего собственного “ИИ-клона”: новый вид ИИ, который сохраняет вас, передает ваш контекст и защищает ваши интересы. GitHub

Cursor Talk to Figma MCP:** Model Context Protocol (MCP), позволяющий Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них. GitHub

На что способен MCP в области дизайна Cursor Talk to Figma MCP см. видео

Classless.css:** Легкий CSS-фреймворк для веб-сайтов с безупречным вкусом, но без желания добавлять классы. GitHub

Раунды финансирования проектов с открытым исходным кодом 💸

Supabase, альтернатива Google Firebase с открытым исходным кодом, привлекла $100 млн при оценке стоимости в $2 млрд. Ссылка
AheadComputing, игрок из экосистемы RISC-V, объявила о посевном финансировании в размере $21,5 млн. Ссылка
Rerun, создатели платформы для ведения журналов и визуализации мультимодальных данных, привлекли посевное финансирование в размере $17 млн под руководством PointNine. Ссылка
Onyx, решение для корпоративного поиска с открытым исходным кодом, привлекло посевное финансирование в размере $10 млн под совместным руководством Khosla Ventures и First Round Capital. Ссылка
Lingo.dev, создатели инструментария для локализации с открытым исходным кодом, привлекли $4,2 млн. Ссылка

Очень интересные проекты:

[https://github.com/onyx-dot-app/onyx](https://github.com/onyx-dot-app/onyx)** – Помогите своей инженерной команде, службе поддержки, отделу продаж и команде эксплуатации продукта быстрее находить информацию. Искусственный интеллект с открытым исходным кодом, подключенный к документам, приложениям и сотрудникам вашей компании.

[https://github.com/rerun-io/rerun](https://github.com/rerun-io/rerun)** – Визуализируйте потоки мультимодальных данных. Бесплатно, быстро, просто в использовании и легко интегрируется. Написано на Rust.

[https://github.com/lingodotdev/lingo.dev](https://github.com/lingodotdev/lingo.dev)** – Фиксируйте. Переводите. AI-локализация для команд, которые быстро выпускают продукты. Переводите приложения, веб-сайты и целые базы данных, используя лучшие LLM-модели.

[https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp](https://github.com/sonnylazuardi/cursor-talk-to-figma-mcp)** – Этот проект реализует интеграцию Model Context Protocol (MCP) между Cursor AI и Figma, позволяя Cursor взаимодействовать с Figma для чтения дизайнов и программного внесения изменений в них.

ИИшница – стратегический взгляд, выбор локальной LLM и MCP

Mon, 24 Mar 2025 22:32:14 +0300

Зачем бизнесу LLM: стратегический взгляд

Выбор локальной LLM модели. Публикация на сайт с чатом

MCP (Model Context Protocol)

vLLM vs TGI различия фреймворка для инференса

Thu, 20 Mar 2025 23:17:08 +0300

Автор: Yiren Lu @YirenLu
Оригинал: https://modal.com/blog/vllm-vs-tgi-article

Зачем использовать фреймворк для инференса?

Почему разработчики не могут просто использовать библиотеку вроде Transformers для обслуживания своих моделей?

Хотя библиотеки, такие как Transformers, отлично подходят для обучения и базового инференса, у них есть ограничения, когда дело доходит до масштабного развертывания и обслуживания LLM:

Эффективность использования памяти:** LLM требуют значительных ресурсов памяти. Универсальные библиотеки могут не оптимизировать использование памяти, что приводит к неэффективному распределению ресурсов. Для получения дополнительной информации о требованиях VRAM для обслуживания LLM, прочитайте здесь.
Скорость инференса:** Стандартным библиотекам часто не хватает оптимизаций, специфичных для инференса, что приводит к замедлению времени обработки больших моделей.
Пакетная обработка и очереди:** Эффективная обработка нескольких запросов требует сложных механизмов пакетной обработки и очередей, которые обычно не включаются в библиотеки, ориентированные на обучение.
Масштабируемость:** Обслуживание LLM в масштабе требует тщательного управления вычислительными ресурсами, что выходит за рамки большинства универсальных библиотек.

Вместо этого, для большинства случаев обслуживания моделей в production, чтобы максимизировать пропускную способность и минимизировать задержку, вам следует использовать inference server. Двумя наиболее популярными inference serverами для случаев использования LLM являются vLLM и TGI.

Что такое vLLM и TGI?

vLLM

vLLM — это библиотека с открытым исходным кодом, разработанная для быстрого инференса и обслуживания LLM. Разработанная исследователями из Калифорнийского университета в Беркли, она использует PagedAttention, новый алгоритм внимания, который эффективно управляет ключами и значениями внимания. vLLM обеспечивает до 24 раз более высокую пропускную способность, чем Hugging Face Transformers, без каких-либо изменений в архитектуре модели.

Ключевые особенности vLLM включают в себя:

Эффективное управление памятью
Непрерывная пакетная обработка
Оптимизированные реализации ядра
Поддержка различных архитектур моделей

TGI (Text Generation Inference)

TGI, сокращение от Text Generation Inference (Инференс для генерации текста), — это инструментарий для развертывания и обслуживания больших языковых моделей (LLM). Разработанный компанией Hugging Face, TGI обеспечивает высокопроизводительную генерацию текста для самых популярных LLM с открытым исходным кодом, включая Llama, Falcon, StarCoder, BLOOM, GPT-NeoX и другие. Он ориентирован на предоставление готового к production решения для развертывания и обслуживания больших языковых моделей с особым упором на задачи генерации текста.

Сравнение производительности: Что быстрее?

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

Пропускная способность:** vLLM часто демонстрирует более высокую пропускную способность, особенно для больших размеров пакетов, благодаря механизму PagedAttention и оптимизации непрерывной пакетной обработки.
Эффективность использования памяти:** Метод PagedAttention в vLLM позволяет более эффективно использовать память, потенциально обеспечивая более высокую параллельность на одном и том же оборудовании.
Простота использования:** Поскольку TGI создан Hugging Face, обслуживание любой модели Hugging Face (включая частные/gate-модели) с помощью TGI относительно просто. Стандартный способ запуска TGI, через официальный Docker-контейнер, также поднимает API endpoint.
Готовность к производству (Production-readiness):** TGI предлагает встроенную телеметрию через OpenTelemetry и метрики Prometheus. У vLLM меньше “готовых к производству” наворотов.

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

Когда использовать AI-агентов: Простая блок-схема

Sun, 02 Mar 2025 20:49:45 +0300

Перевод: Когда использовать AI-агентов: Простая блок-схема

Оригинал: https://www.llmwatch.com/p/when-to-use-ai-agents-a-simple-flowchart

Когда и как использовать AI-агентов против AI-воркфлоу для ваших задач.

Ключевые моменты

Используйте AI-агентов для задач, требующих гибкости и динамического принятия решений, например, для помощников по кодированию или виртуальных ассистентов.
Используйте AI-воркфлоу для четко определенных, повторяющихся задач с ясными шагами, таких как обработка заказов или ответы службы поддержки.
Начните с простого вызова LLM (большой языковой модели), если задача представляет собой простой запрос; при необходимости переходите к воркфлоу или агентам.

AI-агенты против AI-воркфлоу – 30-секундная версия

Что это такое?

AI-агенты, или агенты с ИИ, – это системы, которые автономно планируют и адаптируются, принимая решения на лету. Они отлично подходят для сложных, неструктурированных задач. AI-воркфлоу**, с другой стороны, следуют предопределенным шагам, что идеально подходит для последовательных, повторяющихся процессов.

Как выбрать?

Сначала проверьте, может ли простой вызов LLM с поиском (retrieval) справиться с вашей задачей, например, ответить на быстрый вопрос. Если нет, решите: Ваша задача хорошо определена с четкими шагами? Если да, используйте воркфлоу; если нет, и требуется гибкость, выбирайте AI-агентов. Этот подход обеспечивает простоту и эффективность.

Стоимость и задержка

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

AI-агенты против AI-воркфлоу – Подробно

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

Давайте более подробно рассмотрим, когда использовать AI-агентов, а когда AI-воркфлоу, во многом опираясь на систему классификации Anthropic в качестве отправной точки. Таким образом, остальная часть этой статьи призвана направлять принятие решений, предлагая как теоретические идеи, так и практические применения, с акцентом на создание эффективных AI-систем.

Предпосылки и определения

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

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

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

Основа для принятия решений

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

Описание блок-схемы

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

Начало:** Начните с оценки стоящей перед вами задачи.
Решение 1:** Может ли задача быть решена одним вызовом LLM с поиском (retrieval)?
- Да:** Используйте один вызов LLM с поиском, которого достаточно для простых запросов, таких как ответы на фактические вопросы или генерация простого текста. Этот подход использует механизмы поиска для предоставления контекста, поддерживая низкие затраты и сложность.
- Нет:** Если задача не может быть решена одним вызовом, перейдите к следующему решению.
Решение 2:** Является ли задача четко определенной с ясными, предопределенными шагами?
- Да:** Используйте AI-воркфлоу. Они идеально подходят для задач, которые можно разбить на последовательность предопределенных шагов, обеспечивая предсказуемость и согласованность. Примеры включают автоматизированные ответы службы поддержки или конвейеры обработки данных.
- Нет:** Используйте AI-агентов. Они необходимы для задач, которые являются неструктурированными или требуют динамического принятия решений, таких как помощники по кодированию, решающие проблемы GitHub, или виртуальные помощники, планирующие и выполняющие различные задачи.

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

Руководство по реализации

Чтобы предоставить практические рекомендации, мы можем классифицировать варианты использования и соображения для каждого варианта:

Одиночный вызов LLM с поиском (Retrieval):**
- Вариант использования:** Подходит для простых запросов, когда LLM может предоставить прямой ответ, возможно, дополненный извлечением релевантной информации из базы данных или базы знаний. Например, ответ на вопрос клиента о технических характеристиках продукта.
- Преимущества:** Низкая стоимость, низкая задержка и минимальная настройка. Это соответствует рекомендации Anthropic оптимизировать отдельные вызовы LLM поиском и примерами в контексте для многих приложений.
- Пример:** Чат-бот, отвечающий: “Каковы часы работы вашего магазина?” путем извлечения информации и прямого ответа.
AI-воркфлоу:**
- Вариант использования:** Лучше всего подходит для задач, которые хорошо определены и повторяются, с четкими шагами, которые не требуют от LLM принятия решений о том, какой следующий шаг следует предпринять. Примеры включают процессы выполнения заказов, от получения заказа до отправки, или управление учетными записями клиентов.
- Преимущества:** Предсказуемость, согласованность и простота отладки. Воркфлоу следуют предопределенным путям в коде, что делает их подходящими для таких задач, как маршрутизация запросов клиентов в различные отделы на основе категорий (например, выставление счетов, техническая поддержка).
- Соображения:** Убедитесь, что входы и выходы для каждого шага четко определены, чтобы избежать ошибок. Часто реализуется с помощью таких шаблонов, как объединение и маршрутизация подсказок как часть рабочих процессов, которые можно реализовать в нескольких десятках строк кода без сложных фреймворков.
- Пример:** Банковский AI-чат-бот, который обрабатывает проверку баланса, выполняя предопределенную последовательность: проверяет пользователя, извлекает данные учетной записи, форматирует ответ.
AI-агенты:**
- Вариант использования:** Идеально подходит для задач, которые являются сложными, неструктурированными или требуют гибкости и принятия решений на основе моделей. К ним относятся сценарии, в которых LLM необходимо планировать независимо, использовать внешние инструменты или адаптироваться к меняющимся условиям. Примеры включают агентов кодирования, решающих проблемы GitHub, как видно в тестах, таких как SWE-bench Verified, или виртуальных помощников, обрабатывающих различные запросы пользователей, такие как планирование встреч и создание отчетов.
- Преимущества:** Высокая адаптивность, подходит для динамических сред. Агенты могут разбивать проблемы на управляемые шаги, сотрудничать с другими агентами и использовать такие инструменты, как веб-поиск или вызовы API, как отмечается в сообщении блога.
- Соображения:** Более высокие затраты и задержка из-за динамической обработки. Рекомендуется проводить тестирование в изолированной среде и уделять приоритетное внимание прозрачности, показывая этапы планирования. Другим важным фактором для агентов, использующих сложные инструменты (например, Azure CLI, GitHub), является создание тщательного интерфейса между агентом и компьютером (ACI) посредством документации и тестирования инструментов. Ваши агенты смогут использовать правильные инструменты для ваших задач, только если у них есть доступ к достаточной информации о них.
- Пример:** AI-агент, который автономно пишет и тестирует код для исправления проблемы GitHub, проверенный автоматизированными тестами и проверкой человеком, как часть инициативы SWE-bench.

Дополнительные соображения

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

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

Обслуживание клиентов – отличный пример: оно часто требует задержки, близкой к реальному времени, и строгих мер защиты, поскольку это приложение, ориентированное на клиентов (и многие клиенты, обращающиеся в службу поддержки, уже не в лучшем настроении). Хотя AI-агенты обещают справляться с этим намного лучше, чем предыдущие технологии, требования к надежности и безопасности высоки. И вы уже можете создавать довольно продвинутые чат-боты с помощью рабочих процессов. Фактически, большинство чат-ботов, работающих в настоящее время в промышленной эксплуатации, имеют мало общего с агентным AI (даже если они утверждают обратное). Такие вещи, как инструменты для клиентских данных и истории заказов, гораздо важнее и могут быть реализованы как рабочие процессы для стандартных запросов. Прагматичным компромиссом может быть использование агентов для более неоднозначных запросов. Два подхода к проектированию не исключают друг друга, что является еще одним важным соображением. Используйте то, что лучше всего подходит для вашего варианта использования.

Заключение

В заключение, решение между AI-агентами и AI-воркфлоу зависит от характера задачи: используйте отдельные вызовы LLM для простых запросов, рабочие процессы для четко определенных, повторяющихся задач и агентов для неструктурированных, динамических задач, требующих адаптивности. Этот подход согласуется с рекомендациями по простоте, прозрачности и тщательному тестированию, обеспечивая эффективную разработку AI-системы. Приведенная выше блок-схема и рекомендации предлагают практическую отправную точку для реализации, подкрепленную реальными примерами и общедоступными сведениями от ведущих AI-компаний, таких как Anthropic & HuggingFace.