Розробка конвеєра RAG для того, щоб штучні інтелектуальні агенти міркували, а не лише ставили запити.
Канал обробки даних типу RAG для штучних інтелект-агентів має відображати рівень впевненості, різноманітність джерел та охоплення інформацією, щоб агент міг помітити прогалини, здійснити новий запит та пояснити, як він дійшов до своїх висновків.
Джерела: How to Design a RAG Pipeline So AI Agents Reason, Not Just Query It
Агент викликає підхід RAG та отримує список документів. Що відбувається далі?
У більшості сценаріїв використання агентів RAG розглядається як пошукове поле: надсилається запит, береться отриманий результат, і процес продовжується. Агент не може визначити, чи були результати корисними, чи вони охоплювали всі аспекти запитання, чи друга спроба з більш точною гіпотезою могла б виявити щось важливе. Він працює сліпо.
Це має значення, тому що агенти діють на основі неповної інформації. Детектор галюцинацій може виявити вигадані факти, але сліпі місця у процесі пошуку значно важче помітити. Агент впевнено робить висновки на основі неповної карти ситуації, і ніхто не дізнається, що він пропустив. Звичайний цикл розробки — отримання даних, їх пошук та генерація результату — зовсім не містить сигналів зворотного зв’язку.
Зробіть процес пошуку видимим для агента
Рішення полягає у тонкому «поясі» навколо підходу RAG, який зробляє доступними структуровані сигнали, за допомогою яких агент може міркувати, а не лише споживати інформацію.
Замість простого списку документів цей «пояс» повертає більш змістовний об’єкт. Він містить самі документи, показник впевненості, індикатор різноманітності джерел (скільки різних доменів та який діапазон дат), сигнали охоплення, які вказують, які аспекти запиту були розглянуті, а які відсутні, а також метадані пошуку, такі як модель ембеддингу, розмір частинок, параметр top-k та інформація про те, чи виконувався процес переупорядкування результатів.
{
"results": [Document, Document, Document],
"confidence_score": 0.87,
"source_diversity": {"domains": 3, "timestamps": ["2024-01", "2023-11", "2023-09"]},
"coverage_signals": {
"question_aspects_covered": ["technical", "cost"],
"question_aspects_missing": ["compliance", "deployment"]
},
"retrieval_metadata": {
"embedding_model": "text-embedding-3-large",
"chunk_size": 512,
"top_k": 5,
"reranker_applied": true
}
}
Завдяки цьому у агента є канал зворотного зв’язку. Він може бачити, що охоплення є частковим, а джерела — обмеженими. Він може вирішити здійснити пошук з іншого кута, передати справу вищому співробітнику чи зафіксувати недоліки у своїх міркуваннях.
Три рівні
Рівень 1: отримання даних інструментів
Спочатку необхідно зібрати те, що система вже обчислює. Бази даних векторів повертають оцінки схожості, інструменти переранжування видають показники довіри, а фрагменти даних містять часові мітки та URL-адреси джерел. Цей перший рівень збирає ці значення, не змінюючи логіку пошуку: він виконує звичайний запит, отримує оцінки, джерела та часові мітки, усереднює оцінки для отримання приблизного показника довіри та підраховує кількість різних джерел.
def retrieve_with_signals(query: str, top_k: int = 5):
# Standard retrieval
results = vector_db.query(query, top_k=top_k)
# Capture raw signals
similarity_scores = [r.score for r in results]
sources = [r.metadata.get("source") for r in results]
timestamps = [r.metadata.get("timestamp") for r in results]
# Compute confidence as mean similarity
confidence = sum(similarity_scores) / len(similarity_scores)
return {
"results": results,
"confidence_score": confidence,
"source_diversity": {
"domains": len(set(sources)),
"timestamps": sorted(set(timestamps))
}
}
Цей процес є невтручальним, адже ви лише читаєте дані, які вже існували.
Рівень 2: виявлення охоплення
Далі йде рівень, який відновлює отриманий контент у відповідності до початкового запиту. Достатньо легкого семантичного порівняння, і не потрібна повна переранжування.
Розділіть запит на аспекти. Для запиту „Як розгорнути модель з обмеженнями за витратами?“ аспектами можуть бути розгортання, витрати та обмеження. Потім перевірте, які з них зустрічаються у отриманому тексті. Штучний інтелект або простий збір ключових слів може створити список аспектів, а перевірка може полягати у пошуку кожного аспекту в об’єднаному тексті документа. Функція повідомляє, які аспекти були охоплені, які відсутні, та коефіцієнт охоплення.
def detect_coverage(query: str, documents: list) -> dict:
# Extract query aspects (simple approach: use an LLM or keyword extraction)
aspects = extract_query_aspects(query) # ["deployment", "cost"]
# Check document coverage
doc_text = " ".join([d.content for d in documents])
covered = [a for a in aspects if a.lower() in doc_text.lower()]
missing = [a for a in aspects if a not in covered]
return {
"question_aspects_covered": covered,
"question_aspects_missing": missing,
"coverage_ratio": len(covered) / len(aspects) if aspects else 1.0
}
Саме тут агент отримує зворотний зв’язок, на основі якого може діяти. Відсутні аспекти мають спонукати до створення нового запиту. Щоб покращити підхід, під час обробки кожен документ слід позначити аспектами, а під час пошуку — порівняти ці позначки.
Рівень 3: передача агенту
Нарешті, необхідно надати агенту інструмент, який повертає результати пошуку. Цей інструмент приймає запит та необов’язковий аспект, на який потрібно зосередитися, виконує пошук із використанням певних сигналів, додає інформацію про охоплення та надає рекомендацію: здійснити повторний запит, якщо коефіцієнт охоплення опускається нижче 0,7, інакше продовжити роботу.
tools = [
{
"name": "search_with_reasoning",
"description": "Search the knowledge base and receive coverage signals",
"parameters": {
"query": "str",
"aspect_focus": "optional str (e.g., 'deployment' or 'cost')"
}
}
]
def search_with_reasoning(query: str, aspect_focus: str = None) -> dict:
retrieval_output = retrieve_with_signals(query, top_k=5)
coverage = detect_coverage(query, retrieval_output["results"])
return {
**retrieval_output,
"coverage_signals": coverage,
"recommendation": (
"re-query" if coverage["coverage_ratio"] < 0.7 else "proceed"
)
}
Агент отримує цю рекомендацію та може її дотримуватися або проігнорувати, використовуючи свої знання в даній галузі.
Перевірте, чи варто довіряти сигналам
Пристрій має сенс лише тоді, коли його сигнали є точними, тому перевірте три аспекти.
- Точність сигналів. Чи справді показник впевненості передбачає якість пошуку? Виконайте близько двадцяти запитів, оцініть результати вручну від одного до п’яти та порівняйте ці оцінки з показником впевненості. Розумною метою є кореляція понад приблизно 0,75.
- Виявлення охоплення. Вручну позначте, які аспекти кожного запитання відповідають документи, а потім порівняйте це з результатами детектора для близько десяти різних запитів. Метою є точність понад 85%.
- Поведінка агента. Фіксуйте кожне рішення про повторний запит. Якщо часто новий запит створюється через коефіцієнт охоплення нижче 0,7, це означає, що агент звертає увагу на сигнал.
Витрати та обмеження
Додається затримка. Для покриття всіх випадків потрібен другий семантичний аналіз, і під час пошуку п’яти документів може з’явитися додаткові 50–100 мілісекунд. Якщо це занадто багато, необхідно зберігати сигнали в кеші або обчислювати їх асинхронно.
Цей інструмент також передбачає, що шар пошуку є достатньо стабільним для використання. Якщо сховище векторів не повертає оцінки або блоки не містять метаданих, спочатку потрібно налаштувати інструменти вимірювання.
Крім того, сигнали є евристиками. Висока оцінка довіри не гарантує правильного міркування. Інструмент надає агенту кращі, але не ідеальні дані, тому все одно необхідні перевірки на галюцинації на наступних етапах.
Чому це вигідно
Агенти, які можуть бачити процес пошуку, є більш прозорими та надійними. Вони можуть пояснити, чому здійснили ще один пошук, позначити невизначеність та передати завдання людині, коли рівень покриття низький. Ось у чому різниця між пошуковою системою та дослідницьким асистентом: одна повертає результати, а інший — результати та вказує, у чому він не впевнений.
Початок роботи
- Цього тижня виконайте крок 1. Відображайте рівень впевненості та різноманітність джерел, фіксуйте ці дані протягом дня та стежте за патернами.
- Додайте функцію виявлення рівня покриття для найпоширеніших типів запитів та перевірте її вручну на десяти прикладах.
- Інтегруйте цю функцію в агента та вимірюйте, чи здійснює він повторні запити при низькому рівні покриття, а також чи покращується його логіка міркувань.
Як тільки існує кріплення, інші сигнали легко інтегруються: виявлення семантичних змін, перевірка свіжості, інструменти перевірки фактів. Кожен з них надає агенту більше інформації для аналізу. Почніть з малого, створіть канал зворотного зв’язку та дозвольте агенту навчитися його слухати.
Пов’язана література
- Шар за шаром: проектування справжнього каналу отримання даних RAG для AI-агентів — Сплануйте канал RAG за допомогою контрактів SourceDocument та DocumentChunk, функцій часткового розбиття даних, ембеддингів та ChromaDB, усе це через RetrievalService, який забезпечує стабільність агента.