Розробка RAG з Pinecone: пайплайни, гібридний пошук, кейси

Чому RAG з Pinecone ламається на реальних даних

На демо-даних пошук по базі знань виглядає робочим: десяток документів, акуратні запитання — відповіді збігаються з очікуванням.

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

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

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

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

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

Що дає керований пошуковий контур знань

Керований пошуковий контур відрізняється від «просто підключеної векторної бази» передбачуваністю за трьома метриками: точність попадання в потрібний фрагмент, час оновлення індексу та частка відмов.

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

Фільтри за метаданими (документ, версія, права доступу) застосовуються до ранжування: система фізично не може послатися на фрагмент, який користувачеві не дозволений.

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

Окремо рахуємо частку відповідей, де посилання веде на правильний фрагмент, на наборі еталонних запитань — це вимірювана величина, а не суб'єктивне «стало краще відповідати».

Завдяки порогу релевантності зникає клас відмов «впевнена відповідь не за джерелом»: якщо відповідних фрагментів немає, система повідомляє про відсутність даних замість правдоподібної вигадки, а кожна відповідь супроводжується посиланням на першоджерело.

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

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

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

Режими пошуку в RAG з Pinecone: порівняння підходів

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

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

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

Етапи робіт: від аудиту даних до передачі контуру

Насамперед фіксуємо, що саме має потрапити в індекс і за якими правилами тим самим документом можна користуватися.

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

1. Аудит корпусу документів. Розбираємо джерела: формати, дублікати, застарілі редакції, документи з обмеженим доступом. Окремо відзначаємо, де текст витягується чисто, а де потрібна попередня обробка таблиць і сканів.
2. Схема контуру. Визначаємо, де живе індекс, як документи потрапляють до нього під час оновлення і що відбувається при видаленні або зміні редакції. Схему погоджуємо до написання коду — правки на цьому кроці коштують години, після запуску — тижні.
3. Налаштування індексу. Підбираємо розмір фрагмента й перекриття так, щоб відповідь не розривалася на півслові, розмічаємо метадані для фільтрів. Тут же вмикаємо гібридний пошук: векторний за сенсом плюс лексичний за точними формулюваннями, номерами й абревіатурами.
4. Фільтри та права доступу. Перевіряємо, що співробітник бачить лише дозволені йому розділи, а фільтр застосовується до ранжування, а не після. Це знімає клас витоків, які неможливо зловити на демонстрації.
5. Контрольні запити. Збираємо набір еталонних запитань із заздалегідь відомими джерелами й дивимося, як часто система попадає в потрібний документ. Ті самі запити залишаються регресійним тестом: після будь-якої правки індексу видно, що стало краще, а що зламалося.
6. Передача рішення. Віддаємо документацію щодо контуру, регламент оновлення корпусу, спосіб відкату на попередню конфігурацію індексу й навчання вашої команди. Pinecone або інший векторний шар тут — деталь реалізації; важливіше, що контур супроводжується вашими силами.

Комплект постачання: конфігурації, схеми та регламенти

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

Усе передаємо у ваш репозиторій і базу знань, кожен файл розбираємо на дзвінку та перевіряємо на вашому стенді: приймання йде за списком, а не за відчуттям «ніби відповідає».

• Конфігурації контуру. Декларації індексів і просторів імен, параметри нарізки документів на фрагменти, налаштування моделі векторизації та пороги відсікання за релевантністю — у версійному контролі, а не в листуванні інженера.
• Схема потоків даних. Шлях документа від завантаження до відповіді з посиланнями на джерела: де очищення, де нарізка, де запис в індекс, де виклик моделі. Діаграма й текстовий опис поруч.
• Правила фільтрації та доступу. Які метадані навішуються на вектори, як простори імен розділяють клієнтів і підрозділи, хто які документи бачить. Кожне правило закрито тестом на витік між контурами.
• Регламент оновлення. Тригери й розклад переіндексації, порядок повного перезбирання при зміні моделі векторизації, процедура відкату на попередній індекс.
• Документація. Карта сервісів, інструкція з локального запуску, опис метрик і порогів спрацювання, розбір типових відмов із готовими діями.
• Еталонний набір запитань. Запити з очікуваними джерелами та скрипт прогону: після правок видно, що якість не просіла.

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

Кейс: як скоротили частку нерелевантних відповідей

Замовник — сервісна компанія з внутрішньою базою знань: кілька тисяч регламентів, договорів і проєктного листування. Асистент відповідав швидко, але кожну п'яту відповідь не можна було підтвердити жодним фрагментом вихідного документа. На довгих договорах пошук піднімав вступну частину замість потрібного пункту на сороковій сторінці.

Що було до змін

Частка відповідей без посилання на джерело трималася на 21%. До потрібного фрагмента фахівець добирався за шість-вісім секунд, половину з них займав ручний перегляд видачі.

Базу правили раз на одну-дві тижні: шматки були нарізані за фіксованою довжиною й розривали таблиці, нумерацію та вкладені пункти.

Що змінили

Розбиття перевели на смислові блоки зі збереженням заголовків і структури пунктів, у метадані додали тип документа, підрозділ і дату редакції.

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

Поріг впевненості виставили явно: якщо найкращі фрагменти не набирають вагу, асистент відповідає «у базі немає відповіді» й називає власника документа замість правдоподібного припущення.

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

Чим гібридний пошук відрізняється від векторного

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

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

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

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

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

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

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

Правимо не за відчуттями: беремо набір запитів із заздалегідь розміченими правильними фрагментами й дивимося, як змінюється частка випадків, коли правильна відповідь потрапила в першу п'ятірку.

Обмеження та підводні камені: що врахувати заздалегідь

Більшість збоїв RAG-контуру проявляється не на демонстрації, а в експлуатації: корпус зростає, документи редагуються, у співробітників різні права. Ці вузькі місця дешевше закласти на старті, ніж розбирати інциденти після запуску.

Нижче — технічні сумніви, які найчастіше спливають перед виведенням системи в продакшн.

Як у відповіді враховуються права доступу до документів?

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

Користувач отримує відповідь лише за доступними йому розділами — інакше система збере відповідь із документа, який співробітнику не дозволений, і це вже інцидент витоку.

Що робити з різнорідними форматами?

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

Чи є межа за обсягом корпусу?

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

Що відбувається при зміні моделі?

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

Обговоримо задачу: що потрібно для старту

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

• Перелік джерел знань: бази, файлові сховища, внутрішні системи й документи — з форматами та орієнтовними обсягами.
• 10–20 реальних запитань користувачів і еталонні відповіді до них — на них налаштовується пошук і перевіряється якість видачі.
• Схема доступу: хто й звідки звертається до системи, які ролі та обмеження діють щодо документів.
• Вимоги до розгортання: ваш контур чи зовнішній, хто видає доступи до векторного сховища й моделей.
• Обмеження за часом відповіді та кількістю одночасних запитів, якщо вони вже сформульовані.
• Наявні напрацювання: прототипи, розмітка, скрипти, минулі оцінки — те, що не потрібно робити заново.

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

Опишіть задачу у двох-трьох абзацах або надішліть те, що вже зібрано, — і ми повернемося з планом і строками етапів.