Суть патерна
Research Agent - це патерн, у якому агент проводить кероване дослідження через обмежений пайплайн: search, dedupe, policy-check, read, extract notes з provenance і synthesize відповідь лише з перевірених матеріалів.
Коли потрібен: коли треба зібрати й перевірити факти з кількох джерел, а не дати відповідь без доказової бази.
Це не "просто browse".
Research-пайплайн зазвичай містить:
Search + dedupe URL: прибрати повтори ще до читанняRead у бюджеті: читати сторінки в межах часу і ліміту джерелExtract фактів: зібрати структуровані нотаткиVerify claim/citation: базово перевірити ключові твердженняSynthesize з посиланнями: написати фінальну відповідь із цитуванням
Проблема
Уяви, що ти просиш:
"Дізнайся правила в новому законі і коротко поясни."
Агент "погуглив" і повернув висновок, але без чіткого сліду джерел.
Тоді виникають типові ризики:
- поверхневе читання (відкрито багато, прочитано мало)
- дублікати тих самих матеріалів
- змішання фактів і авторських інтерпретацій
- слабке або хибне цитування
- нульова відтворюваність результату
Дослідження відкритого вебу без процесу швидко стає хаосом: багато кроків, мало доказовості.
У цьому й проблема: без керованого пайплайну складно довести, що висновок побудовано на реальних і перевірених джерелах.
Рішення
Research Agent працює через обмежений пайплайн, а не через "пошукати ще трошки".
Аналогія: це як журналістське дослідження за чеклістом. Спочатку збираєш джерела й нотатки з посиланнями, потім пишеш висновок. Без цього легко змішати факти з припущеннями.
Ключовий принцип: writer отримує право на synthesis тільки після зібраних витягнутих нотаток з походженням.
Керований процес:
- Пошук (
Search): знайти обмежену кількість джерел - Дедуплікація (
Dedupe): нормалізувати URL і прибрати дублікати - Перевірка політики (
Policy Check): пропустити джерела через policy-gate - Читання (
Read): прочитати лише дозволені сторінки - Витяг (
Extract): сформувати нотатки з походженням (url+quote) - Перевірка (
Verify): перевірити ключові твердження - Синтез (
Synthesize): писати відповідь тільки з нотаток
Це дозволяє прикріпити до відповіді:
- які сторінки читались
- які цитати витягнуті
- які твердження перевірено
- чому пайплайн завершився (
stop reason)
Працює добре, якщо:
- крок пошуку (
Search) має чіткі межі (max_urls,max_seconds) - крок читання (
Read) проходить через policy-check - крок витягу (
Extract) містить повне походження - виконання забороняє synthesis без notes
Інакше агент може:
- посилатися на непрочитані джерела
- змішувати неперевірені факти
- вигадувати цитування для переконливості
Саме тому потрібні budget caps, dedupe + cache, захист виконання і stop-rules проти нескінченного search-loop.
Як працює
Критичний принцип: writer не повинен вигадувати джерела. Він працює лише з extracted notes.
Опис повного флоу: Search → Dedupe → Policy Check → Read → Extract → Verify → Synthesize
Пошук (Search)
Один або два контрольовані search-кроки з лімітами за часом і кількістю URL.
Дедуплікація (Dedupe)
URL нормалізуються і дублікати прибираються до читання.
Перевірка політики (Policy Check)
У обробку потрапляють лише дозволені домени, типи контенту та безпечний рівень ризику джерела.
Читання (Read)
Сторінки завантажуються через кеш, щоб не читати повторно той самий контент.
Витяг (Extract)
Факти зберігаються структуровано: url, quote, claims, timestamp.
Перевірка (Verify)
Базова вибіркова перевірка: чи ключові твердження підкріплені цитатами зі сторінок.
Синтез (Synthesize)
Фінальна відповідь пишеться лише на основі нотаток і містить явні посилання-цитування.
У коді це виглядає так
budget = {"max_urls": 10, "max_seconds": 90}
urls = search_once(goal, k=8)
urls = dedupe_and_normalize(urls)[: budget["max_urls"]]
notes = []
for url in urls:
if budget_exceeded(budget):
break
if not policy_allow(url):
continue # stop/skip reason можна логувати
page = fetch_with_cache(url)
note = extract_structured_note(goal, page, url=url)
notes.append(note)
if not notes:
return partial_or_escalate("no_reliable_sources")
verified = spot_check_claims(notes, sample_size=2)
answer = synthesize_from_notes(goal, notes, verified=verified)
return answer
Тут важливі не "красиві промпти", а кероване виконання: budget, dedupe, cache, stop reasons.
Як це виглядає під час виконання
Goal: Які обмеження EU AI Act для систем високого ризику?
Search:
- знайдено 12 URL
- після дедуплікації: 7 унікальних
Read/Extract:
- 5 сторінок успішно прочитано
- 2 відхилено через низьку релевантність
Verify:
- 2 ключові claims пройшли spot-check
Synthesize:
- сформовано короткий підсумок
- додано цитати з 3 джерел
Повний приклад Research агента
Коли підходить — і коли ні
Підходить
| Ситуація | Чому Research підходить | |
|---|---|---|
| ✅ | Зовнішні джерела обов'язкові і потрібне цитування | Research-agent вміє шукати, читати і посилатися на джерела. |
| ✅ | Тема динамічна і внутрішньої бази недостатньо | Пошук у середовищі виконання дістає актуальні дані з відкритого вебу або зовнішніх джерел. |
| ✅ | Потрібне походження висновків | Можна явно показати, звідки взято ключові факти та твердження. |
| ✅ | Є контроль виконання: бюджети і правила інструментів | Обмежене дослідження керує вартістю і зменшує ризик циклу перегляду. |
Не підходить
| Ситуація | Чому Research не підходить | |
|---|---|---|
| ❌ | Дані вже є в RAG | Зовнішній пошук не потрібен, достатньо внутрішнього пошуку. |
| ❌ | Критична затримка | Пошук і читання сторінок зазвичай дорожчі за локальну генерацію. |
| ❌ | Немає безпечного за політиками пайплайну для browse-процесу | Безпечний контроль інструментів і доменів не забезпечений. |
Бо research-режим майже завжди дорожчий за локальну генерацію або RAG.
Чим відрізняється від RAG
| RAG | Research Agent | |
|---|---|---|
| Джерела | Внутрішній індекс/база знань | Open-web або зовнішні джерела |
| Фокус | Швидка заземлена відповідь | Пошук, читання і верифікація фактів |
| Контроль вартості | Відносно стабільний | Потребує жорстких budget caps |
| Головний ризик | Слабкий пошук | Цикли інструментів і фальшиві цитування |
RAG працює на вже підготовленому knowledge layer (шар знань). Research Agent добуває знання зовні у runtime (середовищі виконання).
Коли використовувати Research (vs інші патерни)
Використовуйте Research Agent, коли потрібно зібрати факти з кількох джерел і звести їх у структуровані докази.
Короткий тест:
- якщо потрібно "дослідити тему по кількох джерелах і дати обгрунтований висновок" -> Research
- якщо потрібно "аналізувати вже наданий датасет" -> Data Analysis Agent
Порівняння з іншими патернами та приклади
Швидка шпаргалка:
| Якщо задача виглядає так... | Використовуйте |
|---|---|
| Після кожного кроку треба вирішити, що робити далі | ReAct Agent |
| Спочатку треба розбити велику ціль на менші виконувані задачі | Task Decomposition Agent |
| Потрібно запускати код, перевіряти результати і безпечно ітерувати | Code Execution Agent |
| Потрібно досліджувати дані та повертати висновки на основі аналізу | Data Analysis Agent |
| Потрібне дослідження з кількох джерел зі структурованими доказами | Research Agent |
Приклади:
ReAct: "Знайди причину падіння API: перевір логи -> подивись помилки -> запусти наступну перевірку за результатом".
Task Decomposition: "Підготуй запуск нового тарифу: розбий задачу на підзадачі для контенту, техніки, QA і підтримки".
Code Execution: "Порахуй retention за 12 місяців у Python і перевір коректність формул на реальних даних".
Data Analysis: "Проаналізуй CSV із продажами: знайди тренди, аномалії та дай короткі висновки".
Research: "Збери дані про 5 конкурентів із кількох джерел і зроби порівняльне резюме".
Як комбінувати з іншими патернами
- Research + RAG: перевірені зовнішні знахідки зберігаються у внутрішню knowledge base для наступних відповідей.
- Research + Guarded-Policy: політики обмежують, якими інструментами, доменами і типами даних можна користуватись.
- Research + Fallback-Recovery: при нестабільному search/fetch агент повторює запит або переходить на резервні джерела.
Коротко
Research Agent:
- проводить обмежений пошук і читання джерел
- витягує структуровані нотатки з походженням
- перевіряє ключові твердження перед відповіддю
- дає цитовану відповідь без нескінченних циклів перегляду
Переваги та Недоліки
Переваги
збирає дані з кількох джерел в одному місці
додає посилання, тож відповідь легше перевірити
краще покриває тему, ніж одне джерело
зручно для порівняння фактів і версій
Недоліки
працює повільніше через пошук і читання джерел
без лімітів може витратити забагато ресурсів
якість відповіді залежить від якості джерел
FAQ
Q: Чи можна шукати "до впевненості"?
A: Ні. Рівень впевненості не є умовою зупинки. Потрібні чіткі межі: max_urls, max_seconds і правила stagnation/convergence.
Q: Чому важлива дедуплікація URL?
A: Без неї агент платить за повторне читання того самого контенту і спотворює "кількість джерел".
Q: Чи достатньо просто додати цитати наприкінці відповіді?
A: Ні. Цитати мають походити з extracted notes, а не генеруватися "для вигляду".
Що далі
Research Agent закриває open-world пошук і цитування.
Тепер, коли ти знаєш основні патерни, наступне питання: як поєднати їх у реальну систему? Коли використовувати детермінований workflow, а коли — гнучкого агента? І як вони працюють разом?