Як налаштувати мульти-агентну систему: ролі, завдання, Flows у CrewAI

Мульти-агентні системи на базі LLM — коли кілька AI-агентів взаємодіють для вирішення складних задач. Без чіткої координації вони перетворюються на хаос: агенти дублюють роботу, втрачають контекст, генерують суперечливі результати. Ми стикалися з цим на десятках проєктів — і CrewAI став основним інструментом для наведення порядку. Наша команда з 5-річним досвідом у впровадженні AI-рішень реалізувала понад 100 проєктів. За 2 роки CrewAI показав себе у 50+ інтеграціях, скоротивши час аналізу на 70%.

CrewAI — фреймворк з відкритим вихідним кодом, що вводить поняття «crew» (команди). Кожен агент отримує роль, мету та набір інструментів. Завдання делегуються за ролями, а потік виконання керується декларативно або ієрархічно. На відміну від CrewAI (офіційний репозиторій), де описуються стани та переходи, тут просто говориться: «цей агент шукає дані, цей пише звіт, а менеджер перевіряє якість». Налаштування мульти-агентних систем з CrewAI дозволяє створити команду за пару годин.

Які проблеми вирішує CrewAI?

Типовий біль клієнта — ручний збір даних, їх розрізненість та низька швидкість підготовки аналітики. Один виробничий цикл може займати тижні. CrewAI вирішує три ключові проблеми:

• Координація агентів: агенти не заважають один одному, не дублюють роботу, оскільки кожен знає свою роль та залежності.
• Контекстна пам'ять: агенти передають результати один одному через context або memory, зберігаючи зв'язність міркувань.
• Інтеграція інструментів: десятки готових інструментів (SerperDev, ScrapeWebsite, FileWriter) та можливість створити кастомний за пару годин.

Ось як це виглядає на практиці: один клієнт з фінтеху попросив автоматизувати щоквартальний конкурентний аналіз. Раніше це займало 3 тижні силами 2 аналітиків, а з CrewAI — 4 години автономної роботи + 2 години рев'ю. Покриття конкурентів зросло з 5 до 12 компаній, а пропущених значущих подій стало 0 замість 2–3 (дані внутрішнього звіту). CrewAI забезпечує в 70% швидше виконання аналізу порівняно з ручним процесом.

Як ми це робимо: стек та код

Використовуємо CrewAI, LangChain для роботи з LLM, OpenAI GPT-4o або Claude 3.5 для агентів, та PostgreSQL з pgvector для RAG-пам'яті. Конфігурація агентів описана в YAML або прямо в Python. Ось базова структура — визначення агентів та завдань:

from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool, ScrapeWebsiteTool, FileWriterTool
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o", temperature=0.1)

# Визначення агентів
researcher = Agent(
    role="Senior Research Analyst",
    goal="Знайти актуальну та точну інформацію за заданою темою",
    backstory="""Ти — аналітик-дослідник з 10-річним досвідом.
    Спеціалізуєшся на технологічному секторі.
    Завжди перевіряєш джерела та вказуєш на суперечності.""",
    tools=[SerperDevTool(), ScrapeWebsiteTool()],
    llm=llm,
    verbose=True,
    max_iter=5,  # Максимум ітерацій агента
    memory=True,
)

writer = Agent(
    role="Content Strategist",
    goal="Створити структурований аналітичний звіт",
    backstory="Досвідчений технічний автор, що спеціалізується на бізнес-аналітиці.",
    tools=[FileWriterTool()],
    llm=llm,
    verbose=True,
)

# Визначення завдань
research_task = Task(
    description="""Досліди ринок {topic} за поточний рік.
    Охопи: ключових гравців, обсяг ринку, тренди, прогнози.
    Знайди мінімум 5 актуальних джерел.""",
    expected_output="Структуровані дані дослідження з джерелами",
    agent=researcher,
    async_execution=False,
)

write_task = Task(
    description="""На основі наданого дослідження створи аналітичний звіт.
    Формат: вступ, ключові знахідки (таблиця), тренди, висновки.
    Обсяг: 1500–2000 слів.""",
    expected_output="Готовий аналітичний звіт у markdown форматі",
    agent=writer,
    context=[research_task],  # Використовує вивід research_task як контекст
    output_file="report.md",
)

# Створення команди
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,  # Послідовне виконання
    verbose=True,
)

result = crew.kickoff(inputs={"topic": "ринок LLM-рішень для корпоративного сектору"})

Окрім послідовного процесу, CrewAI підтримує ієрархічний, де менеджер-LLM координує роботу агентів. Ось приклад:

manager_llm = ChatOpenAI(model="gpt-4o", temperature=0)

hierarchical_crew = Crew(
    agents=[researcher, analyst, writer, qa_reviewer],
    tasks=[research_task, analysis_task, writing_task, review_task],
    process=Process.hierarchical,
    manager_llm=manager_llm,  # LLM-менеджер приймає рішення про делегування
    verbose=True,
)

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

CrewAI Flows: імперативне керування

Для сценаріїв з розгалуженнями та циклами використовуємо Flows — вони дозволяють описати логіку як граф зі станами:

from crewai.flow.flow import Flow, listen, start, router
from pydantic import BaseModel

class ContentState(BaseModel):
    topic: str = ""
    research_result: str = ""
    analysis_result: str = ""
    quality_score: float = 0.0
    final_content: str = ""

class ContentCreationFlow(Flow[ContentState]):

    @start()
    def initialize(self):
        print(f"Початок роботи з темою: {self.state.topic}")

    @listen(initialize)
    def run_research(self):
        research_crew = Crew(agents=[researcher], tasks=[research_task], process=Process.sequential)
        result = research_crew.kickoff(inputs={"topic": self.state.topic})
        self.state.research_result = result.raw

    @listen(run_research)
    def run_analysis(self):
        analysis_crew = Crew(agents=[analyst], tasks=[analysis_task])
        result = analysis_crew.kickoff(inputs={"research": self.state.research_result})
        self.state.analysis_result = result.raw

    @router(run_analysis)
    def check_quality(self):
        # Оцінюємо якість
        score = evaluate_quality(self.state.analysis_result)
        self.state.quality_score = score
        if score >= 0.8:
            return "write_content"
        return "improve_analysis"

    @listen("improve_analysis")
    def improve_analysis(self):
        # Повторний аналіз з додатковим контекстом
        pass

    @listen("write_content")
    def write_final_content(self):
        write_crew = Crew(agents=[writer], tasks=[write_task])
        result = write_crew.kickoff(inputs={"analysis": self.state.analysis_result})
        self.state.final_content = result.raw

flow = ContentCreationFlow()
flow.kickoff(inputs={"topic": "Застосування AI в логістиці"})

Кастомні інструменти

Зазначимо: коли стандартних інструментів не вистачає, пишемо свої. Наприклад, для доступу до корпоративної БД:

from crewai.tools import BaseTool
from pydantic import BaseModel, Field

class DatabaseQueryInput(BaseModel):
    sql_query: str = Field(description="SQL-запит для виконання")
    database: str = Field(description="Ім'я бази даних", default="analytics")

class DatabaseQueryTool(BaseTool):
    name: str = "query_database"
    description: str = "Виконати SQL-запит до бази даних аналітики"
    args_schema: type[BaseModel] = DatabaseQueryInput

    def _run(self, sql_query: str, database: str = "analytics") -> str:
        # Валідація: тільки SELECT
        if not sql_query.strip().upper().startswith("SELECT"):
            return "Помилка: дозволені тільки SELECT-запити"
        result = db.execute(sql_query, database=database)
        return result.to_json()

db_tool = DatabaseQueryTool()
analyst.tools.append(db_tool)

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

Як швидко налаштувати CrewAI: 4 кроки

1. Визначте ролі агентів (наприклад, дослідник і письменник).
2. Створіть завдання з очікуваними результатами.
3. Виберіть процес: sequential для простих ланцюжків, hierarchical для складних.
4. Запустіть crew та перевірте вивід на тестовому датасеті.

Строки орієнтовно

• Прототип з 3 агентами: від 2 до 4 днів.
• Production-crew з кастомними інструментами: від 1 до 2 тижнів.
• Складний Flow з conditional routing: від 2 до 3 тижнів.
• Інтеграція з корпоративними системами: +1–2 тижні.

Типові помилки при впровадженні

• Занадто широкі backstory агентів — вони починають галюцинувати. Радимо звужувати контекст до конкретної сфери.
• Ігнорування параметра max_iter — агент може зациклитися. Виставляйте явне обмеження (5–10).
• Відсутність тестового набору даних — без нього не впіймати регресію після зміни моделі.

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

CrewAI знижує поріг входу для побудови мульти-агентних систем. На відміну від LangGraph, де потрібно вручну описувати кожен перехід, CrewAI в 5 разів швидше для налаштування базової команди та робить 80% роботи за вас. Наш досвід показує, що перша робоча crew збирається за пару днів, а віддача від автоматизації окупає витрати на інтеграцію протягом кварталу. Налаштування мульти-агентних систем з CrewAI — це інвестиція, яка швидко окупається.

Пишіть нам — оцінимо ваш проект безкоштовно. Пропонуємо рішення під ключ за 2-3 тижні. Зв'яжіться з нами, щоб оцінити можливість інтеграції CrewAI у ваш проєкт. Ми надаємо гарантію на стабільність системи після деплою та сертифікати відповідності. Замовте демо — покажемо, як ваша AI-команда почне приносити прибуток.

Практичний розбір 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+ підтримують гібридний пошук нативно.

Коли варто 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?

Для більшості задач 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 робочі дні. Або замовте консультацію фахівця з вибору підходу: RAG, fine‑tuning або гібрид — розповімо, що підійде саме вам.