Александр Мироненко – Инженерия интеллекта от промта к системам ИИ (страница 7)
Твоя задача — подготовить документ для загрузки в базу знаний (RAG).
Разбей текст ниже на смысловые блоки со следующими правилами:
- Каждый блок содержит одну завершённую мысль (примерно 200–400 слов).
- Если мысль длиннее — раздели по логической границе.
- Начинай каждый блок с заголовка раздела, к которому он относится.
- Добавь к каждому блоку 3–5 ключевых тем для последующей фильтрации.
Текст:
[ваш документ]
После нарезки каждый блок отправляется в векторную базу данных.
По состоянию на 2026 год выбор здесь широк:
- легковесные open-source решения вроде pgvector (работает прямо в PostgreSQL) и ChromaDB для прототипов;
- промышленные гибридные системы вроде Qdrant (показывает отличные результаты в бенчмарках облачных решений для 2026 года), Pinecone и Weaviate;
- энтерпрайз-гиганты Elasticsearch и Vespa, предоставляющие комплексные AI-поисковые платформы.
Тип 2: Text-to-SQL — поиск по точным значениям
Векторный поиск бесполезен, если клиенту нужно узнать, «сколько денег вернули Иванову 5 марта». Здесь нужна работа с реляционными базами данных и SQL.
Современные модели (такие как GPT-5.4 или Claude Opus 4.7) отлично пишут SQL-запросы по описанию на естественном языке, но при критически важном условии: они должны знать схему таблиц. Без неё модель начинает угадывать названия столбцов и получает синтаксические ошибки.
База данных со следующей структурой:
Таблица: sales
- id (INT, уникальный)
- date (DATE, формат YYYY-MM-DD)
- product_name (VARCHAR)
- category (VARCHAR, допустимые значения: "Ноутбуки", "Мониторы", "Периферия")
- quantity (INT)
- total (DECIMAL, руб.)
Задача: [ваш вопрос на естественном языке].
Напиши SQL-запрос и одним предложением объясни, что он делает.Указание конкретных значений в категориях (как «Ноутбуки», а не «Ноутбук») устраняет целый класс ошибок, связанных с несовпадением строк в фильтрах.
Есть вопросы, на которые не ответят ни векторный, ни SQL-поиск.
Это вопросы о структуре отношений, и для них существует граф.
Графовая база данных хранит информацию в виде узлов (люди, компании, документы) и рёбер (связей между ними с указанием типа: «является руководителем», «подписал», «аффилирован с»). С ростом сложности корпоративных данных всё более востребованным становится GraphRAG — подход, который объединяет графовые и векторные базы для повышения точности ответов.
На практике в 2026 году популярны Neo4j и специализированные open-source решения вроде Nexus (гибрид графа и векторного поиска для RAG) и OverGraph (встроенная графовая база данных с поиском, работающая прямо внутри процесса). Крупные вендоры,
такие как Memgraph и NebulaGraph, также выпускают собственные GraphRAG-решения.
В реальных бизнес-задачах почти никогда не нужен только один тип поиска. Представьте интернет-магазин: пользователь пишет «ноутбук для дизайнера, бюджет до 150 000». Здесь нужно совместить:
Семантический поиск (векторный), чтобы найти общее описание.
Ключевой поиск (BM25), чтобы не пропустить конкретные модели.
Числовые фильтры, чтобы отсечь всё, что выше 150 000.
Это называется гибридным поиском (Hybrid Search). Результаты объединяются алгоритмом Reciprocal Rank Fusion (RRF): документ, попавший в топ и векторного, и ключевого поиска, получает высший итоговый ранг. В инженерной практике 2026 года стандарт усложнился: после слияния применяется модель-реранкер (часто — специализированная легковесная LLM), которая оценивает пару «запрос-документ» и пересортировывает результат для максимальной релевантности.
Тип 5: Агентный RAG (Agentic RAG) — эволюция 2026 года
До сих пор мы описывали «классический» RAG: один запрос один поиск один ответ. Но передовые исследования 2026 года, принятые на конференции уровня ICLR, активно внедряют концепцию агентного RAG.
Что это значит? Поиск информации превращается из пассивной операции в итеративный процесс. LLM-агент больше не делает один «слепой» запрос к базе. Вместо этого он:
1. Получает сложный вопрос пользователя.
2. Раскладывает его на несколько подзадач и подзапросов.
3. Итеративно ищет информацию, оценивая качество и полноту найденного на каждом шагу.
4. Может решить, что информации недостаточно, переформулировать запрос и найти недостающие звенья.
Такой подход решает две классические болезни: over-search (когда модель ищет то, что и так знает) и under-search (когда модель не ищет там, где нужно). Современные фреймворки, такие как HiPRAG, обучают агентов находить оптимальный баланс между поиском и рассуждением, снижая показатель over-search до 2-3%.
Конец ознакомительного фрагмента.
Текст предоставлен ООО «Литрес».
Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.