Розширені можливості RAG у практичному застосуванні: архітектура, інструменти та їх переваги та недоліки.

Retrieval-Augmented Generation поєднує крок пошуку з мовною моделлю. Документи завантажуються та індексуються заздалегідь, коли надходить запит, беруться відповідні фрагменти, а модель формує свою відповідь на основі цих даних. Однак у реальних системах RAG рідко є просто векторною базою даних плюс LLM. Справжні системи включають структуровану обробку документів, розбиття на частини з урахуванням структури, пошук за щільними значеннями та ключовими словами, переурочування рейтингів, створення контексту, оцінку та можливості моніторингу.

У наступному опису розглядаються інструменти, які широко використовуються у реальних системах, а експериментальні методи залишаються поза увагою.

Огляд процесу

Практичний розгорнутий підхід починається з отримання даних, їх обробки та очищення, потім — розділення на частини, створення метаданих, використання ембеддингів та індексування. Під час запиту виконуються розуміння запиту, гібридний пошук, об’єднання результатів та їх переранжування, далі — стиснення контексту, генерація тексту з посиланнями, а наостанок — оцінка та моніторинг. Конкретний набір інструментів залежить від типу документів, масштабу, цілей щодо затримки, правил конфіденційності, бюджету та стандартів якості.

Отримання даних

Локальні файли. Python з бібліотеками pathlib, PyPDF, python-docx, openpyxl та pandas дозволяє ефективно обробляти PDF-файли, документи Word, таблиці, CSV-файли та простий текст, що легко підходить для пакетних завдань. Однак кожен формат вимагає власного парсера; скановані та складні PDF-файли потребують спеціалізованого вилучення даних, а великі обсяги даних — паралельної обробки та поступового їх оброблення.

Зберігання об’єктів. Amazon S3, Google Cloud Storage та Azure Blob Storage забезпечують надійне, масштабоване зберігання великих колекцій та ідеально підходять для асинхронного отримання даних. Ви оплачуєте витрати на налаштування хмарних сервісів, контроль доступу, а також витрати на зберігання та передачу даних, які зростають у міру масштабування.

Веб- та API-джерела. інструменти на кшталт requests чи httpx, BeautifulSoup, Playwright та Firecrawl підтримують актуальність бази знань шляхом отримання даних з веб-сайтів, API та динамічних сторінок. Веб-сайти змінюють свою структуру, сторінки з великою кількістю JavaScript потребують автоматизації браузером, а скролінг призводить до обмежень швидкості, дублікатів сторінок та нерівномірної якості контенту.

Аналіз та вилучення даних

Unstructured підтримує PDF, Word, HTML, PowerPoint, зображення та інше, а також витягує елементи на кшталт заголовків, абзаців та таблиць, що робить його хорошим універсальним інструментом. Він працює повільніше, ніж простий метод витягування тексту, а складні документи все одно можуть потребувати спеціальної обробки.

PyMuPDF швидко витягує текст та метадані з PDF-файлів у текстовому форматі та легко інтегрується в код на Python. Це не повна система для розуміння документів, тому скановані файли потребують OCR, а складні макети чи таблиці — додаткової обробки.

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

OCR та витягування на основі зору

Tesseract є програмним забезпеченням з відкритим кодом, працює локально та добре справляється зі звичайним друкованим текстом. Рукописний текст та складні макети знижують точність, а неякісні скан-зображення потребують попередньої обробки.

PaddleOCR пропонує потужну систему для виявлення та розпізнавання тексту багатьма мовами, що підходить для сканованих документів та структурованого вилучення інформації. Складні документи все одно можуть потребувати післяобробки макету, а їх впровадження може вимагати додаткових залежностей моделей.

Моделі зі здатністю розуміння тексту та зображень, такі як моделі класу GPT-4, Gemini та сімейство Qwen-VL, розуміють текст, зображення, діаграми та макет сторінки, що допомагає, коли саме OCR втрачає візуальний контекст, та уможливлює багатомодальний підхід RAG. Вони коштують дорожче, ніж класичні OCR-системи, працюють повільніше та генерують недетермінований результат, який потребує перевірки.

Чанкування

Чанкінг визначає, що стане одиницею, яку можна отримати. Поганий чанкінг розділяє важливу інформацію або об’єднує несуміжний матеріал.

• Рекурсивне розділення символів (RecursiveCharacterTextSplitter від LangChain) — це надійна базова методика, яка намагається дотримуватися меж абзаців та речень і легко налаштовується. Вона працює з синтаксисом, а не з значенням, і фіксований розмір не підходить для кожного документа.
• Розділення на токени визначає розмір чанків за модельними токенами, що допомагає дотримуватися обмежень вікна контексту. Кордони токенів не обов’язково збігаються з семантичними межами.
• Семантичний чанкінг шукає зміни теми за допомогою схожості, тому послідовні ідеї залишаються разом краще, ніж при використанні фіксованих розмірів. Він вимагає більше обчислень, потребує ембеддингів та залежить від порогового значення, яке потрібно вибрати.

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

Розділення з урахуванням структури враховує заголовки, розділи, таблиці та абзаци, що є корисним для технічних та корпоративних документів. Цей підхід залежить від надійного аналізу тексту, і різні типи документів вимагають різних правил.

Метадані

Типові поля включають ідентифікатор документа, назву файлу, номер сторінки, розділ, автора, час створення, тип документа, користувача або орендаря, права доступу, вихідну URL та версію. Хороші метадані дозволяють фільтрувати інформацію до або під час пошуку, підтримують цитування та контроль доступу, а також підвищують точність. З іншого боку, слабкі метадані безпосередньо погіршують якість пошуку, а схеми стає складніше підтримувати у поєднанні різних джерел.

Ембеддинги

Ембеддинги перетворюють текст на вектори, які передають його значення.

• Ембеддинги OpenAI є керованими, високоякісними та простими у використанні, з високою ефективністю для загального пошуку. Недоліки полягають у витратах на API, залежності від постачальника та тому, що передавання даних може бути неприйнятним у конфіденційних середовищах.

BGE — це потужна родина інструментів з відкритим кодом для пошуку, яку можна розмістити на власному сервері; існують її версії для інтенсивного пошуку та переранжування. Для самостійного розміщення потрібна інфраструктура, а вибір моделі та її розмірність впливають на обсяг зберігання та час відповіді.

E5 — це популярна родина інструментів з відкритим кодом, яка добре підходить для загального пошуку та має версії, засновані на інструкціях чи префіксах. Деякі версії вимагають ретельної форматування запитів та документів, а їх самостійна робота збільшує обсяг обробки.

Cohere Embed — це керований API з хорошими можливостями багатомовного та корпоративного пошуку залежно від версії моделі; його легко розгорнути. Однак він потребує оплати за API та зовнішньої залежності.

Jina embeddings — це моделі, орієнтовані на пошук; деякі з них підтримують довгий контекст та кілька мов. Функціонал змінюється залежно від версії, а для роботи з відкритими моделями потрібна інфраструктура.

Бази даних векторів

• pgvector додає функцію пошуку векторів до PostgreSQL, об’єднуючи реляційні дані, метадані та вектори в одному місці, що є чудовим рішенням, якщо додаток вже використовує Postgres. Дуже великі обсяги даних у векторному форматі можуть потребувати спеціалізованих систем, а масштабування у високих обсягах стає складнішим.
• Pinecone — це керована база даних векторів, яка масштабується без необхідності налаштування інфраструктури та пропонує фільтрацію, придатну для експлуатації в продакшені. Ви оплачуєте послугу, покладаєтесь на постачальника та відмовляєтесь від частини контролю.
• Qdrant доступний як у відкритому коді, так і в хмарній версії; добре фільтрує метадані, підтримує щільний та гібридний пошук та підходить для самостійної реалізації RAG. Самостійна експлуатація передбачає необхідність виконання операційного обслуговування, а дистрибутивні конфігурації вимагають ретельного планування пропускної здатності.

Weaviate пропонує розширені можливості пошуку, гібридний пошук та фільтрацію метаданих у хмарній чи самостійно розгорнутій формі. Більше функцій може призвести до підвищеної складності системи, а великі обсяги даних потребують налаштувань.

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

FAISS — дуже популярна бібліотека для швидкого пошуку схожостей та локальних експериментів без зовнішньої бази даних. Це бібліотека пошуку, а не розподілена база даних, тому для збереження даних, фільтрації, підтримки кількох користувачів та розподілу потрібні додаткові інженерні рішення.

Отримання даних

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

BM25 — це потужний лексичний метод, ідеальний для точних термінів, назв, ID та технічних ключових слів; він простий у використанні та зрозумілий. Він не враховує семантичну схожість, тому синоніми та парафрази можуть залишитися непоміченими.

Гібридний пошук зазвичай поєднує BM25 із щільним пошуком, поєднуючи лексичну точність із семантичним охопленням для отримання більш надійних результатів при різних типах запитів. Він вимагає об’єднання оцінок чи рангів, а також більше інфраструктури та налаштувань, ніж простий пошуковик.

Трансформація запиту

• Переписування запиту перетворює розмовний або нечіткий вхідний текст на формат, придатний для пошуку, що допомагає при постановці подальших запитань. Погане переписування може призвести до втрати ключової інформації, а також збільшити затримку та витрати ШІ.
• Багатозапитний пошук передбачає створення моделлю кількох альтернативних запитів та пошук інформації для кожного з них, що покращує точність результатів та дозволяє враховувати різні формулювання. Це означає більше запитів до системи, більшу затримку та витрати, а іноді — нерелевантні результати пошуку.
• HyDE (Hypothetical Document Embeddings) генерує вигадану відповідь та вбудовує її для подальшого пошуку, що може допомогти у складних запитах або у випадках, коли лексика запиту суттєво відрізняється від лексики документів. Для цього потрібен додатковий запит до ШІ, а погано створений гіпотетичний документ може спотворити результати.

Фузія

Фузія взаємних рангів об’єднує ранги з кількох пошукових систем. Вона проста, надійна та добре підходить для щільних сигналів та BM25; крім того, їй не потрібні оцінки з різних систем, щоб можна було їх порівнювати. Вона додає етап ранжування, проте все одно має параметри для налаштування.

Фузія з ваговими коефіцієнтами надає різний вагомість щільним, розрідженим чи іншим сигналам, що корисно, коли пошукові системи мають різні сильні сторони. Масштаби оцінок мають бути нормалізовані, а ваги залежать від обсягу роботи.

Поновне ранжування

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

Крос-енкодери для переранжування, такі як BGE Reranker, Cohere Rerank та Jina Reranker, оцінюють кожну пару запиту-документ спільно, зазвичай досягаючи кращих результатів, ніж проста схожість ембеддингів, і добре працюють після гібридного пошуку. Вони дорожчі за векторний пошук, тому їх слід використовувати лише з обмеженим списком кандидатів.

Переранжування за допомогою LLM полягає у тому, що модель оцінює релевантність та може враховувати складні критерії, але цей підхід повільний, вимагає багато ресурсів та менш детермінований, ніж спеціалізовані інструменти для переранжування.

Максимальна маржинальна релевантність (MMR) балансує релевантність та різноманітність, видаляючи дублікати, коли топ-k результатів є майже ідентичними. Вона включає параметр різноманітності, проте надмірна різноманітність може призвести до видалення релевантних даних, які випадково повторюються.

Компресія контексту

Екстрактивне стиснення зберігає лише релевантні речення чи фрагменти, що дозволяє заощадити токени та зберегти первісну формулювання, але воно може позбавити текст контексту, необхідного для розуміння його змісту. Стиснення на основі LLM підсумовує отриманий матеріал та може значно скоротити обсяг контексту у великих документах, проте це супроводжується додатковими витратами та затримками, і існує ризик, що сам процес стиснення призведе до втрати інформації чи галюцинацій.

Генерація

Поширеними варіантами для практичного використання є моделі OpenAI, Anthropic Claude, Google Gemini, Meta Llama та Qwen. Вони демонструють високу здатність до міркувань, а запити можна спрямовувати з урахуванням витрат, затримок та складності завдання. Моделі API пов’язані з витратами та залежністю від постачальника, відкриті моделі вимагають інфраструктури, а більші моделі підвищують затримки та витрати на обробку даних.

Фреймворки

LangChain має величезну екосистему завантажувачів, засобів пошуку інформації, інтеграцій із сховищами векторів та інтерфейсів моделей, що дозволяє швидко створювати потоки обробки даних. Абстракції можуть ускладнювати роботу, тому в продакшн-системах часто краще використовувати простіші, чіткі шляхи виконання запитів.

LlamaIndex зосереджується на отриманні даних, їх індексуванні та пошуку, пропонуючи корисні абстракції для роботи з документами у рамках підходу RAG. Він додає складності до фреймворку, тому деякі передові системи зрештою переходять на SDK нижчого рівня.

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

Продвинуті патерни

• Corrective RAG оцінює отриманий контекст та може ініціювати додаткове отримання інформації, виявляючи слабкі результати та дозволяючи використовувати альтернативний пошук, проте це супроводжується затримками та складністю.
• Self-RAG дозволяє моделі самостійно вирішувати, коли отримувати інформацію, та оцінювати отримані результати. Вона адаптується, щоб уникати зайвих запитів, але логіка керування є більш складною, і вимагає ретельної оцінки та підтримки з боку моделі.
• Agentic RAG використовує агента для планування пошуків, виклику інструментів, ітеративного отримання та перевірки інформації, що дозволяє розв’язувати складні багатоетапні завдання з кількох джерел. Очікуйте вищих затримок та витрат, більшої кількості проблем та складнішого виправлення помилок.

Graph RAG поєднує граф знань із механізмом пошуку, що допомагає розуміти взаємозв’язки між ентитетами та відповідати на запитання з кількома етапами обробки, які не можуть розпізнати звичайні вектори. Створення графа є дорогим процесом, екстракція ентитетів призводить до помилок, а також потрібна додаткова інфраструктура.

Multimodal RAG здійснює пошук та аналіз тексту, зображень, таблиць та діаграм, що підходить для звітів, сканів та діаграм; вимагає більших зусиль для обробки та індексування, а також має вищі витрати на роботу моделей обробки зображень.

Структуровані дані

Text-to-SQL дозволяє моделі перетворювати запитання натуральної мови на запити до структурованих баз даних, що ідеально підходить для аналізу свіжих даних. Отриманий SQL може бути неправильним або небезпечним, тому потрібні механізми отримання схеми, її верифікація та контроль доступу.

Гібридний текст та SQL RAG використовує векторне або ключове пошукове забезпечення для неструктурованих знань та SQL для структурованих даних, охоплюючи PDF-файли, документи, CSV-файли та бази даних у єдиній схемі. Це вимагає міжрежимного маршрутизування та ускладнює тестування та забезпечення безпеки.

Оцінка

У продакшн-системі необхідна оцінка як на рівні пошуку, так і на рівні генерації.

Показники пошуку (Recall@K, Precision@K, MRR, NDCG та коефіцієнт відповідностей) визначають, чи знайшов пошуковий механізм правильні докази. Показники генерації (вірність, релевантність відповіді, правильність відповіді, релевантність контексту, точність контексту та коефіцієнт відтворення контексту) визначають, чи правильно використав модель ці докази.

Ragas створений для оцінки RAG, охоплює обидва рівні та корисний для тестування на регресію. Багато його показників ґрунтуються на оцінках LLM чи моделей ембеддингів, тому бали не можуть повністю замінити людський огляд, а моделі-оцінювачі можуть мати упередження. Людська оцінка є найкращою для перевірки якості в конкретній галузі та дозволяє виявити те, що пропускають автоматизовані показники, але вона є дорогою, повільною та потребує послідовних правил.

Спостережуваність

LangSmith відстежує ланцюги операцій, запити на отримання даних, запити та результати виводу, а також допомагає у відлагодженні потоків обробки даних та порівнянні експериментів. Це керована платформа, яка враховує аспекти витрат та конфіденційності. Langfuse пропонує функції відстеження, керування запитами та метрики у вигляді програмного забезпечення з відкритим кодом для самостійного розміщення або в хмарі; проте самостійне розміщення є вашою відповідальністю та вимагає налаштування необхідних інструментів. OpenTelemetry — це відкритий стандарт для відстеження операцій, метрик та журналів подій, який дозволяє інтегрувати технологію RAG у існуючу інфраструктуру, але це вимагає більше технічних зусиль, ніж використання готової платформи.

Кешування та продуктивність

Семантичний кеш повторно використовує відповіді для схожих запитів, що зменшує кількість повторних викликів ШІ, затримки та витрати. Однак схожі запитання можуть потребувати різних відповідей після змін даних, а процес їх анулювання є складним. Кеш ембеддингів уникає повторного обчислення векторів для однакового тексту — це простий плюс, який необхідно анулювати щоразу, коли змінюється модель ембеддингів. Асинхронне та паралельне отримання даних дозволяє одночасно запускати незалежні механізми пошуку, що скорочує загальну затримку, хоча обробка помилок стає складнішою, а сервери мають витримувати одночасне навантаження.

Безпека

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

Обробка персональних даних. Персональні дані необхідно знаходити, маскувати або інакше керувати ними перед тим, як вони потраплять до індексу.

Ізоляція користувачів. При наявності кількох користувачів запити потребують фільтрів метаданих, які враховують особливості кожного користувача, а сама база даних має бути розділена.

Забруднення даних. Документи з ненадійних джерел можуть бути додані навмисно для введення в оману.

Жоден окремий захід не може гарантувати безпеку. Для цього потрібні контрольні заходи на кожному етапі — вхід даних, зберігання, пошук, авторизація, виконання інструментів та генерація результатів.

Розгортання

Типовими елементами складання є FastAPI для шару API, Docker для пакетування, Kubernetes для оркестрації у великих масштабах, Redis для кешування, PostgreSQL для реляційних метаданих, S3, GCS або Azure Blob для зберігання об’єктів, Prometheus для збору метрик, Grafana для панелей керування, OpenTelemetry для відстеження та MLflow для фіксації експериментів. Метою є створення системи RAG, яка є відтворюваною, спостережуваною, масштабованою та підтримуваною, а не такої, яка лише здається точною у ноутбуці.

Практичний набір інструментів

Міцний універсальний дизайн може залишатися досить простим. Документи проходять через Unstructured, PyMuPDF або PaddleOCR, потім — обробку з урахуванням структури чи рекурсивне поділення на частини, далі — використання ембеддингів від OpenAI, BGE, E5 чи Cohere, після цього — pgvector, Qdrant або Pinecone. Завдання пошуку виконується за допомогою BM25 та щільного пошуку, поєднаних із алгоритмом RRF; результати переупорядковуються за допомогою крос-енкодера, компресуються та передаються ШІ, разом із посиланнями для підтвердження достовірності. Якість оцінюється за допомогою Ragas та людського огляду, тоді як LangSmith, Langfuse чи OpenTelemetry відстежують час виконання.

Не кожній системі потрібні всі компоненти. Невелика внутрішня база знань може функціонувати за допомогою PostgreSQL, pgvector, ембеддингів та ШІ. Гібридний пошук, переупорядкування результатів, агентні цикли, пошук у графах та багатомодальна обробка слід додавати лише після того, як оцінка покаже, що простіший дизайн недостатній.

Вибір інструменту для завдання

• Простий текст у PDF: PyMuPDF. Змішані типи документів: неструктуровані. Сканування: PaddleOCR. Візуально складні сторінки: модель зору та мови.
• Базове розділення на частини: рекурсивний розщеплювач. Семантичні межі: семантичне розділення. Батьківський та дочірній контексти: пошук у батьківсько-дочірніх структурах.
• Керовані ембеддинги: OpenAI або Cohere. Відкриті ембеддинги: BGE або E5.
• Вже є у PostgreSQL: pgvector. Керований сховище векторів: Pinecone. Самостійно розгорнуте: Qdrant. Прототипи: Chroma або FAISS.
• Пошук на основі значення: щільні вектори. Точні ключові слова: BM25. Надійне покриття: гібридний підхід. Об’єднання рейтингів: RRF. Вища точність: крос-енкодер для перерейтингу. Кілька менше дублікатів: MMR.
• Складні багатокрокові запитання: агентний підхід RAG. Взаємозв’язки ентитетів: Graph RAG. Таблиці та бази даних: текст-у-SQL.

Оцінка: Раги. Відстеження: LangSmith або Langfuse. Стандартна телеметрія: OpenTelemetry. API високої масштабованості: FastAPI з Docker або Kubernetes.

Почніть з малого

Найбільшою архітектурною помилкою є розгляд LLM як цілісної системи. Якість формується від отримання даних до створення контексту, потім до генерації, а далі через оцінку та можливості моніторингу. Більша модель не може надійно компенсувати відсутність доказів.

Корисний цикл покращень виглядає так: встановлення базового рівня, оцінка, визначення проблемної стадії, зміна одного компонента, повторна оцінка, розгортання та моніторинг. Для більшості продакшн-систем почніть з надійного парсингу та структурно обумовленого розділення на частини, якісних ембеддингів, гібридного пошуку та ранжеру, а потім додайте генерацію з урахуванням контексту та оцінку. Впроваджуйте агентний пошук, Graph RAG, багатомодальні пайплайни, коригувальні цикли чи фінтунінг лише тоді, коли вимоги до продуктивності виправдовують їхню вартість та складність.

Хороша інженерія RAG — це не стільки збір усіх можливих технологій, скільки вибір найпростішої архітектури, яка відповідає вашим цілям щодо якості, затримки, витрат, безпеки та можливостей обслуговування.