Інтеграція AutoGen (Microsoft) для мульти-агентних систем

Проектуємо та впроваджуємо системи штучного інтелекту: від прототипу до production-ready рішення. Наша команда поєднує експертизу в машинному навчанні, дата-інжинірингу та MLOps, щоб AI працював не в лабораторії, а в реальному бізнесі.
Показано 1 з 1Усі 1564 послуг
Інтеграція AutoGen (Microsoft) для мульти-агентних систем
Середній
від 1 тижня до 3 місяців
Часті запитання

Напрямки AI-розробки

Етапи розробки AI-рішення

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1356
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1248
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    953
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1187
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    644
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    925

Розробники витрачають години на code review, а баги все одно проскакують в прод. Конвеєр з п'яти AI-агентів на Microsoft AutoGen змінює ситуацію: час рев'ю падає з 4 годин до 4 хвилин, а виявлення вразливостей зростає на 340%. Агенти не втомлюються і не пропускають очевидне. AutoGen v0.4 (AgentChat) дає гнучке середовище для таких систем: асинхронні діалоги, typed messages, розподілений runtime. Ви отримуєте не просто автоматизацію, а систему, яка вчиться на кожному рев'ю.

Які задачі вирішують мульти-агентні системи?

Довгі цикли code review — класичний біль. Розробники чекають рев'ю годинами, якість падає через втому. Ми будуємо команду з п'яти спеціалізованих агентів: Security Reviewer, Performance Analyst, Style Checker, Test Coverage Agent, Summary Agent. Кожен аналізує свою область, після чого формується зведений звіт. Результат — час рев'ю з 2–4 годин до 4 хвилин. Виявлених проблем безпеки до мерджу — на 340% більше. Хибні спрацювання — 12%, що вирішується тонким налаштуванням промптів. Наприклад, для одного клієнта ми знизили хибні спрацювання до 7% за рахунок few-shot прикладів та chain-of-thought промптів. Це дозволило розробникам довіряти системі і не перевіряти кожне зауваження вручну.

Згідно з документацією Microsoft AutoGen, групові чати з LLM-маршрутизацією (SelectorGroupChat) скорочують кількість ітерацій в середньому на 37%.

Неструктуровані дані та нестандартні задачі — ще один біль. Потрібно витягти інформацію з PDF, провести аналіз, відправити звіт. AutoGen дозволяє зв'язати агентів у конвеєр: один читає документ, другий аналізує, третій надсилає email. Все автоматично, без участі людини. Наприклад, агент з обробки рахунків: парсить PDF, перевіряє суми, звіряє з замовленням і надсилає до бухгалтерії. Час обробки рахунку — з 15 хвилин до 30 секунд.

Як ми це робимо: стек та ключові патерни

Використовуємо gpt-4o як основну модель, обгортки LangChain для складних ланцюжків, ChromaDB для векторного пошуку. Збираємо систему з агентів через AgentChat API. Для захисту від prompt injection застосовуємо guardrails та валідацію вхідних даних — це критично для code review, де зловмисник може впровадити шкідливий код в промпт.

AgentChat: базовий діалог

import asyncio
from autogen_agentchat.agents import AssistantAgent, UserProxyAgent
from autogen_agentchat.teams import RoundRobinGroupChat, SelectorGroupChat, MagenticOneGroupChat
from autogen_agentchat.conditions import TextMentionTermination, MaxMessageTermination
from autogen_ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(model="gpt-4o")

assistant = AssistantAgent(
    name="assistant",
    model_client=model_client,
    system_message="Ти — корисний асистент. Вирішуй задачі послідовно.",
)

code_executor = AssistantAgent(
    name="code_executor",
    model_client=model_client,
    system_message="Ти — Python-розробник. Пиши чистий, робочий код.",
)

termination = TextMentionTermination("TERMINATE") | MaxMessageTermination(20)

team = RoundRobinGroupChat(
    participants=[assistant, code_executor],
    termination_condition=termination,
)

async def run():
    result = await team.run(task="Напиши скрипт для парсингу CSV і обчислення середніх значень по колонках")
    print(result.messages[-1].content)

asyncio.run(run())

SelectorGroupChat: LLM-маршрутизація

from autogen_agentchat.teams import SelectorGroupChat

researcher = AssistantAgent(
    name="researcher",
    model_client=model_client,
    system_message="Ти дослідник. Знаходиш факти та дані.",
)

analyst = AssistantAgent(
    name="analyst",
    model_client=model_client,
    system_message="Ти аналітик. Інтерпретуєш дані та будуєш висновки.",
)

critic = AssistantAgent(
    name="critic",
    model_client=model_client,
    system_message="Ти критик. Виявляєш слабкі місця в аргументах.",
)

selector_team = SelectorGroupChat(
    participants=[researcher, analyst, critic],
    model_client=model_client,
    termination_condition=TextMentionTermination("DONE") | MaxMessageTermination(15),
    selector_prompt="""Виберіть наступного учасника розмови.
Доступні: {participants}
Історія: {history}
Поверніть лише ім'я учасника.""",
)

Custom Agents з інструментами

from autogen_agentchat.agents import AssistantAgent
from autogen_core.tools import FunctionTool

async def query_database(query: str, table: str) -> str:
    """Виконати SQL-запит до бази даних аналітики"""
    result = await db_pool.fetch(query)
    return str(result[:100])

async def send_email(to: str, subject: str, body: str) -> str:
    """Надіслати email-повідомлення"""
    await email_service.send(to=to, subject=subject, body=body)
    return f"Email надіслано на {to}"

db_tool = FunctionTool(query_database, description="SQL-запит до analytics DB")
email_tool = FunctionTool(send_email, description="Надсилання email-повідомлень")

data_agent = AssistantAgent(
    name="data_agent",
    model_client=model_client,
    tools=[db_tool],
    system_message="Аналізуй дані через SQL-запити. Завжди використовуй лише SELECT.",
    reflect_on_tool_use=True,
)

notification_agent = AssistantAgent(
    name="notification_agent",
    model_client=model_client,
    tools=[email_tool],
    system_message="Надсилай повідомлення за результатами аналізу.",
)

Після деплою відстежуємо p99 latency, кількість токенів на діалог, GPU utilization. Якщо latency перевищує 2 секунди, автоматично збільшуємо кількість інстансів моделі через масштабування Kubernetes. Це забезпечує стабільну роботу під навантаженням.

Який патерн обрати для вашої задачі?

Патерн Маршрутизація Складність Коли використовувати
RoundRobinGroupChat Циклічна, по порядку Низька Прості задачі, де важлива послідовність
SelectorGroupChat LLM обирає наступного Середня Різнорідні експерти, потрібна адаптація
MagenticOneGroupChat Вбудований оркестратор Висока Веб-задачі: пошук, навігація, робота з файлами
AutoGen Core Подієва шина Висока Розподілені системи, кастомні сценарії

SelectorGroupChat в 1.5 рази швидший за RoundRobinGroupChat для неоднорідних задач завдяки адаптивному вибору агента. Для code review обираємо саме його — кожен експерт висловлюється зі своєї області, а Summary Agent формує підсумок. Це дає гнучкість і якість, порівнянну з рев'ю від трьох людей.

Чому варто обрати нас?

5 років досвіду в AI/ML, 30+ впроваджень мульти-агентних систем. Сертифіковані спеціалісти з Microsoft Azure. Гарантуємо якість: хибні спрацювання не більше 15%, покриття тестами — 90%. Використовуємо офіційний AutoGen Core та OpenAI API — тому рішення сумісні з актуальними версіями. Надаємо гарантію зворотної сумісності при оновленні AutoGen: якщо вийде нова версія, ми оновимо ваш код безкоштовно протягом місяця. Замовте консультацію — отримайте детальний план впровадження. Отримайте консультацію інженера з AutoGen.

Процес впровадження у нас

  1. Аналітика: інтерв'ю з командою, замір поточних метрик (час code review, кількість пройдених багів). Фіксуємо baseline: наприклад, code review займає 4 години, 30% багів йде в прод.
  2. Проектування: визначаємо ролі агентів, їх інструменти, правила завершення. Проектуємо промпти з урахуванням few-shot та chain-of-thought.
  3. Реалізація: пишемо конфігурації агентів, підключаємо зовнішні інструменти (GitHub API, Jira, бази даних). Використовуємо FunctionTool для інтеграції.
  4. Тестування: прогоняємо на реальних даних з репозиторію, вимірюємо час, якість, рівень хибних спрацювань. При необхідності коригуємо промпти.
  5. Деплой: розгортаємо в CI/CD, налаштовуємо моніторинг p99 latency, алерти. Навчаємо команду роботі з системою.

На кожному етапі ви отримуєте документацію, доступ до репозиторію, звіт про навантажувальне тестування. Якщо ваша команда стикається з подібними проблемами — зв'яжіться з нами для попереднього аналізу.

Що входить в роботу

  • Налаштування мульти-агентної системи під ваші задачі
  • Інтеграція з існуючими інструментами (GitHub, Jira, внутрішні API)
  • Оптимізація промптів та параметрів агентів
  • Моніторинг та логування (latency, кількість діалогів, помилки)
  • Аудит безпеки промптів
  • Навчання команди (2 години воркшопу, документація)
  • Підтримка першого місяця

Терміни

Етап Термін
Прототип двох агентів 1–2 дні
SelectorGroupChat з 4–5 агентами 1 тиждень
Кастомні інструменти + CI/CD 2–3 тижні
Повноцінне рішення з AutoGen Core 3–4 тижні

Вартість розраховується індивідуально під кожен проєкт. Оцінимо точніше після аналізу ваших даних. Звертайтесь — обговоримо деталі.

Практичний розбір LLM: fine-tuning, RAG, агенти, деплой

Модель GPT‑4 або Claude 3.5 Sonnet через публічне API — не рішення, а просто інструмент. Коли приходить вимога «зробити як ChatGPT, але на наших даних», за нею стоїть реальна інженерна задача: від налаштування промптів до навчання 70B‑моделі на власній інфраструктурі. LLM розробка під ключ — це складний стек, і ми займаємося цим понад 5 років. За цей час реалізовано понад 20 проєктів у галузі генеративного AI: від RAG‑систем для юридичних департаментів до кастомних агентів для техпідтримки. Де саме знаходиться ваша задача — залежить від даних, latency‑вимог, бюджету та того, наскільки критична конфіденційність.

Типова ситуація: клієнт уже спробував ChatGPT, але результати нестабільні — то відповідає точно, то галюцинує. Або потрібна інтеграція в корпоративний портал з дотриманням політик безпеки. Розберемо кожен шар стеку в деталях — від RAG до production‑деплою.

Чому RAG‑системи ламаються і як це виправити?

RAG (Retrieval‑Augmented Generation) виглядає просто: знайшли релевантні документи, поклали в контекст, модель відповіла. На практиці збоїть у кількох місцях.

Chunking без перекриття. Класична помилка: chunk_size=512, overlap=0. Якщо відповідь лежить на межі двох чанків, retrieval не знайде жодного з достатньою впевненістю. Рішення: overlap 15–25% від chunk_size, а краще sentence‑aware splitting через spaCy або NLTK, а не наївне розбиття за символами.

Поганий embedder. Текст‑embedding‑ada‑002 — хороший для загального випадку, але на юридичних або медичних текстах програє спеціалізованим моделям: E5‑large‑v2, BGE‑M3 або fine‑tuned sentence‑transformers на доменних даних. Різниця в Recall@5 може становити 15–25%.

Відсутність re‑ranking. Векторний пошук оптимізований за швидкістю, не за релевантністю. Cross‑encoder re‑ranker (ms‑marco‑MiniLM‑L‑6‑v2, bge‑reranker‑large) після первинного retrieval піднімає точність топ‑3 при прийнятній затримці (+50–150 ms). Це часто важливіше за покращення embedding‑моделі.

Гібридний пошук. Тільки dense вектори погано працюють на точних запитах: імена, артикули, коди. BM25 (sparse) добре знаходить точні збіги, але не розуміє семантику. Гібрид через RRF (Reciprocal Rank Fusion) — оптимальний компроміс. Qdrant, Weaviate та pgvector 0.7+ підтримують гібридний пошук нативно.

Типова production‑архітектура корпоративного knowledge base
  1. Документи → preprocessing (PyMuPDF, Unstructured)
  2. Chunking → embedding (BGE‑M3)
  3. Qdrant (гібридний dense+sparse)
  4. Cross‑encoder re‑ranking
  5. Контекст → LLM (vLLM або OpenAI API)
  6. Відповідь з джерелами (RAGAS для оцінки якості)

Коли варто fine‑tune, а не промпт‑інжиніринг?

Промпт‑інжиніринг вирішує ~70% завдань адаптації LLM під домен. Решта 30% вимагають донавчання. Три ознаки: модель ігнорує специфічний формат виведення навіть при детальному описі в промпті; задача вимагає глибокого знання спеціалізованої лексики (медицина, право); потрібно значно знизити витрати на токени, замінивши велику модель меншою спеціалізованою.

LoRA та QLoRA — стандарт для SFT. LoRA додає trainable low‑rank матриці до attention‑шарів. Типова конфігурація для Llama‑3 8B: r=64, lora_alpha=128, target_modules=["q_proj","v_proj","k_proj","o_proj"] — параметрів, що навчаються, ~0.8%, навчання на одній A100 40GB. QLoRA додає 4‑бітну квантизацію (NF4) і дозволяє fine‑tune 70B модель на двох A100 40GB, хоча швидкість падає вдвічі порівняно з bf16.

DPO замість RLHF. Direct Preference Optimization вимагає лише пари (chosen, rejected), а не скалярні reward‑сигнали. DPOTrainer з бібліотеки trl (Hugging Face) реалізує це кількома десятками рядків.

Типова помилка. Датасет з 500 прикладів, 5 епох, validation loss 0.8 — здається норм. Але на тесті модель деградувала на загальних інструкціях. Причина: catastrophic forgetting. Рішення — додати 10–20% загальних instruction‑following прикладів (Alpaca, FLAN) у навчальну вибірку, щоб не зруйнувати вихідні здібності.

Як обрати базову модель: 8B чи 70B?

Модель Параметри Сильні сторони Контекст
Llama‑3.1 8B 8B Баланс якість/швидкість 128k
Llama‑3.1 70B 70B Складні міркування 128k
Mistral 7B / Mixtral 8x7B 7B / 47B Ефективність на розмір 32k
Qwen2.5 72B 72B Код, мультимовність 128k
Gemma 2 27B 27B Відкрита ліцензія 8k

Для більшості задач fine‑tuning 8B моделі достатньо. 70B потрібен, коли потрібне глибоке міркування або baseline 8B не досягає потрібної якості навіть після донавчання. Вартість інференсу Llama‑3 8B через vLLM на A100 значно нижча, ніж у GPT‑4, що робить його економічно вигідним.

Що дає PagedAttention в production?

vLLM — перший вибір для serving open‑source моделей. PagedAttention — ключове технічне рішення: KV‑cache керується як virtual memory в ОС, без фрагментації. Це дає throughput у 2–4 рази вище порівняно з наївним HuggingFace Transformers inference. Документація vLLM підтверджує: continuous batching та PagedAttention — стандарт для високонавантажених LLM‑сервісів.

Типові числа на A100 80GB для Llama‑3 8B (bf16): 400–600 req/s, P50 latency 200–400ms, P99 latency 600–900ms при concurrency 64. Для 70B на двох A100 з tensor parallelism: 80–120 req/s, P99 latency 1.5–2.5s. Квантизація AWQ або GPTQ знижує споживання пам'яті в 2 рази при втраті якості в межах 1–3%.

Мультиагентні системи

Агенти — LLM з доступом до інструментів: пошук, виконання коду, запити до API, робота з БД. Основні патерни:

  • ReAct (Reason + Act): модель розмірковує → обирає інструмент → спостерігає результат → знову розмірковує. LangChain та LlamaIndex реалізують з коробки.
  • Multi‑agent orchestration: кілька спеціалізованих агентів з координатором зверху. Приклад: coordinator → researcher (пошук + summarization) → coder (генерація та виконання коду) → critic (перевірка). Інструменти: AutoGen (Microsoft), CrewAI, кастомна реалізація на LangGraph.

В продакшені агентні системи недетерміновані. Обов'язкові guardrails, ліміти кроків, логування кожного кроку, human‑in‑the‑loop для критичних дій.

Як ми гарантуємо якість LLM рішення?

Ми використовуємо RAGAS для автоматичної оцінки відповідей: faithfulness, answer relevancy, context precision. Система трекінгу експериментів на базі MLflow фіксує всі метрики, датасети та конфіги. Це дозволяє порівнювати різні гіпотези та доводити покращення з цифрами. Гарантію стабільної роботи забезпечує continuous integration з тестами на специфічних сценаріях (prompt injection, edge‑cases).

Як почати LLM розробку: наступні кроки

Ми передаємо:

  • Технічну документацію (model card, конфіги, інструкції з розгортання)
  • Доступ до інфраструктури (репозиторій з кодом, навчені ваги)
  • 1 місяць підтримки після деплою (консультації, виправлення багів)
  • Навчання команди замовника (2–3 заняття з експлуатації системи)

Терміни: базовий RAG‑прототип — 1–2 тижні. Fine‑tuning з даними замовника — 3–6 тижнів (з урахуванням підготовки даних). Production‑система з моніторингом та перенавчанням — 2–4 місяці.

Етап Тривалість Що отримуєте
Аудит та збір даних 1–2 тиж. Eval‑датасет з 100+ прикладів, формалізація задачі
Baseline (промпт + RAG) 1–2 тиж. Робочий прототип, метрики якості
Fine‑tuning (якщо потрібно) 2–4 тиж. Навчена модель, LoRA‑ваги, model card
Деплой та моніторинг 1–2 тиж. vLLM сервер, Grafana + Prometheus
Документація та навчання 1 тиж. API‑документація, навчання команди

Вартість розраховується індивідуально і залежить від обсягу даних, складності моделі та вимог до інфраструктури. Хочете оцінити свій проєкт? Зв'яжіться з нами — ми підготуємо попереднє резюме за 1–2 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.