LlamaIndex: чому пошук по базі знань видає сміття
База знань наповнена: регламенти, інструкції, договори, історія звернень. Асистент відповідає впевнено — і повз: замість порядку повернення цитує розділ про приймання, замість внутрішнього регламенту переказує загальну статтю. Причина не в моделі, а в шарі пошуку, який до неї не добудований.
Без індексації документи залишаються набором файлів: пошук іде за збігом слів, а не за змістом, і запит «як оформити повернення» не знаходить розділ «порядок розірвання».
Розбиття на фрагменти теж не налаштовано — шматки або по десять сторінок, і в контекст приїжджає шум, або по рядку, і умова відривається від визначення. Робочий варіант — фрагменти в 300–500 слів з перекриттям, щоб пов'язані частини не роз'їжджалися.
Друга половина проблеми — джерело відповіді. Без метаданих (документ, редакція, дата, розділ) і порогу релевантності в контекст потрапляють дублі та застарілі версії; модель сумлінно переказує те, що отримала, і на одне питання видає дві суперечливі відповіді. Перевірити нічого — посилання на фрагмент немає.
LlamaIndex закриває саме цей шар: індексація документів, розбиття на фрагменти, ранжування та повернення джерела разом з відповіддю. Далі розбираємо, як це налаштовується і де найчастіше ламається.
Що дає керована індексація даних на практиці
Єдиний індекс змінює сам спосіб роботи з базою знань: замість пошуку за назвами файлів і папками відділів система відповідає на питання фрагментом документа.
Розбиття тексту на фрагменти з перекриттям і прив'язка кожного фрагмента до джерела дають те, чого не дає пошук за іменами файлів — влучання в зміст, а не в збіг слова.
На практиці основну частину часу у фахівця з'їдав ручний пошук по десятках редакцій; після складання індексу цей етап скорочується до одного запиту з перевіркою посилання.
Швидкість пошуку та частка релевантних влучань — те, що ми вимірюємо до введення в роботу.
Беремо контрольний набір реальних питань співробітників, проганяємо і рахуємо, у якому відсотку випадків потрібний документ опинився у верхніх результатах, а відповідь зібрана з його фрагментів.
Це дає числову базу для донавчання пошуку: де бракує синонімів, де заважає застаріла редакція, де документ розбитий надто крупно і зміст розмивається.
Контроль версій документів вбудований у саму збірку: індекс перезбирається за подією зміни джерела, старі фрагменти витісняються, і у відповідь не може потрапити скасована редакція.
Це знімає клас помилок, через які співробітники перестають довіряти внутрішньому пошуку — коли система впевнено цитує документ, який уже не діє.
Окремо закриваємо клас «відповідь не з джерела»: кожне твердження у відповіді підкріплене посиланням на фрагмент із зазначенням документа і місця, а за відсутності опори система повідомляє про це замість здогаду.
Керована індексація на LlamaIndex тут цінна не сама по собі, а тим, що правила розбиття, оновлення та видачі описані явно і відтворюються на нових масивах.
Перед запуском проходить перевірка: єдиний індекс покриває всі узгоджені джерела, оновлення йде за подією, застарілі редакції виключені, частка влучань і швидкість пошуку виміряні на контрольному наборі, зниження ручного пошуку підтверджено заміром часу на типових задачах. Якщо хоча б один пункт не виконується — рішення не готове до використання.
Режими роботи LlamaIndex: порівняння підходів
Індекс у LlamaIndex — це не лише вектори, а зв'язка з вузлів з метаданими, самого індексу і сховища, куди він пише. Локальний варіант тримає все у файлах поряд із застосунком, зовнішній виносить вузли та векторні представлення в окрему базу, яку читають кілька сервісів.
Від цієї розвилки залежить, хто може писати в індекс, як швидко в ньому з'являються нові документи і що відбувається під час відкату невдалого прогону.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Локальний індекс | Один сервіс, корпус до кількох тисяч документів, перезбирання за хвилини | Живе до перезапуску без постійного диска; два процеси одночасно не пишуть |
| Зовнішнє сховище | Індекс читають кілька сервісів, потрібні резервні копії та відкат до попередньої версії | Потребує міграцій схеми та розмежування доступу; додається мережевий обмін із базою |
| Пакетна індексація | Корпус змінюється рідко, оновлення за розкладом | Свіжі документи не видні до прогону; повний перерахунок дорожчий за ресурсами |
| Потокова індексація | Документи надходять постійно, важлива свіжість відповіді | Складніше видалення та пошук дублів; потрібна ідемпотентна обробка повторів |
| Гібридний пошук | Запити з точними термінами, артикулами, абревіатурами | Потрібне налаштування ваг і перевпорядкування видачі, інакше якість падає |
На практиці вибір зводиться до двох питань: як часто змінюється корпус і скільки сервісів читає індекс.
Режими сумісні між собою — локальний індекс переноситься у зовнішнє сховище без перезбирання, а пакетний прогін доповнюється потоковим підкачуванням лише для змінених документів.
Етапи впровадження: від аудиту даних до передачі
Маршрут фіксуємо до старту, інакше індекс збирають раніше, ніж домовилися про якість відповіді. Кожен етап спирається на артефакти попереднього, а перевірка йде на реальних робочих питаннях, а не на показових прикладах.
- Аудит джерел даних. Збираємо, що є: регламенти, база знань, таблиці, скани листування. Фіксуємо формати, власників, частоту змін і права доступу — від цього залежить, що можна індексувати, а що зобов'язане залишитися закритим.
- Схема індексу. На LlamaIndex описуємо, на які фрагменти б'ється документ і які метадані до них приклеюємо: розділ, дата, роль користувача. Крупний фрагмент розмиває відповідь, дрібний втрачає контекст — розмір підбираємо замірами, а не на око.
- Налаштування пошуку. Збираємо гібридну видачу: пошук за змістом плюс пошук за точними формулюваннями та артикулами, з переранжуванням. Підбираємо кількість фрагментів, що йдуть у модель: більше — повніша відповідь, але вища затримка.
- Перевірка на еталонних питаннях. Беремо 50–100 реальних питань співробітників із відомими відповідями і заміряємо, чи потрапляє потрібне джерело в топ видачі. Розходження розбираємо: зазвичай це помилки розбиття або невраховані синоніми.
- Відмова та доступи. Перевіряємо, що система відповідає «в джерелах немає даних», а не додумує, і що співробітник бачить лише дозволені йому документи. Ці сценарії ламають довіру найшвидше.
- Передача рішення. Віддаємо конфігурації, схему індексу, регламент переіндексації та інструкцію для власника бази знань, показуємо, як самим заміряти якість після правок.
Артефакти інтеграції LlamaIndex: що залишається вам
Інтеграція вважається завершеною не в момент, коли пошук за документами відповідає на демонстраційних прикладах, а коли у вашої команди залишається комплект, відтворюваний без нас.
Нижче — що саме передаємо на руки: кожен пункт можна відкрити, прочитати й змінити своїми силами, не відновлюючи логіку з листування.
- Конфігурація індексу — параметри розбиття тексту на фрагменти, вибрана модель векторних представлень, метрика близькості та ваги джерел. Все в одному файлі: зміна моделі або розміру фрагмента не потребує правок у коді застосунку.
- Схема обробки документів — звідки забираються файли, як розбираються різні формати, які поля йдуть у метадані. За цією схемою видно, чому конкретний документ потрапив або не потрапив у видачу.
- Правила доступу — розмежування за ролями на рівні метаданих: співробітник бачить лише ті фрагменти, на які в нього є права у вихідній системі. Правила лежать окремо від логіки пошуку і перевіряються автоматичними тестами.
- Скрипти переіндексації та контролю якості — обробка нових і змінених документів, набір перевірних питань з еталонними відповідями, метрики влучання в потрібний фрагмент. Прогін займає хвилини і показує деградацію до того, як її помітять користувачі.
- Документація рішення — карта компонентів, зовнішні залежності, точки відмови та порядок відкату на попередню версію індексу. Інженер, який не брав участі в проєкті, розгортає копію середовища за цією інструкцією.
- Регламент оновлення — періодичність переіндексації, відповідальний за джерела, дії при зміні формату документів і при зростанні обсягу даних. Задає, що відбувається без нашої участі, а що потребує доопрацювання.
Кожен артефакт передаємо у вашому репозиторії та на вашій інфраструктурі — разом з розбором, як його змінювати. Опишіть задачу: повернемося з оцінкою та планом, у якому вигляді комплект ляже у ваші процеси.
Кейс: скоротили частку нерелевантних відповідей утричі
Клієнт — служба підтримки з розподіленою базою знань: регламенти, статті, листування за закритими зверненнями.
Пошук по ній відповідав впевнено, але в 38% випадків спирався не на той розділ, а оператори перевіряли кожне посилання вручну — на підготовку відповіді йшло до шести хвилин.
Що змінили в індексації
Зібрали єдиний індекс на LlamaIndex замість кількох розрізнених сховищ і переписали підготовку даних: документи розбили за смисловими блоками з перекриттям, щоб відповідь не обривалася на межі фрагмента, а до кожного блоку прив'язали метадані — підрозділ, тип звернення, дату актуальності.
Далі включили гібридний пошук: векторний відбір доповнюється лексичним за точними формулюваннями тарифів і назвами послуг, а знайдені фрагменти проходять переранжування перед подачею в модель. Відповідь будується лише на відібраних блоках і завжди з посиланням на джерело.
Як вимірювали результат
До правок зібрали еталонний набір із двохсот питань операторів із заздалегідь відомими правильними джерелами — він став лінійкою, за якою порівнювали версії індексу. Метрики знімали на кожній зміні, а не один раз наприкінці.
Частка відповідей із нерелевантним джерелом упала з 38% до 12%, влучання в топ-3 видачі зросло з 54% до 89%, а частка звернень, закритих без ескалації на другу лінію, — з 61% до 84%. Підготовка відповіді скоротилася з шести хвилин до двох.
Чим гібридний пошук відрізняється від векторного?
Векторний пошук порівнює зміст: запит і фрагмент бази знань переводяться у векторні представлення, близькість рахується за відстанню між ними. Тому «як повернути товар» знаходить статтю «умови повернення», навіть якщо жодне слово не збіглося.
Слабке місце — точні токени: артикули, коди помилок і абревіатури у векторному просторі майже нерозрізненні між собою.
Пошук за ключовими словами влаштований дзеркально: лексичний індекс з лематизацією та частотною моделлю точно ловить рідкісний термін, але пропускає перефраз і синоніми. У LlamaIndex обидва режими збираються як окремі пошукові гілки, а гібридний пошук об'єднує їхні видачі.
Гібридний режим проганяє один запит через обидві гілки і зводить результати: оцінки нормалізуються і складаються з вагами або об'єднуються взаємним ранжуванням, після чого верхні кандидати йдуть на переранжування. Запит з артикулом витягує лексична гілка, смислове питання — векторна.
| Критерій | Векторний пошук | Гібридний пошук |
|---|---|---|
| Що знаходить | смислові збіги, перефраз | зміст і точні токени |
| Сильна сторона | питання «своїми словами» | артикули, коди, рідкісні терміни |
| Обмеження | плутає близькі ідентифікатори | дорожчий за обчисленнями, потрібен підбір ваги |
| Коли вибирати | однорідні тексти, часті питання | каталоги, техдокументація, звернення в підтримку |
За точністю влучань вибір залежить від трафіку: на однорідних запитах без ідентифікаторів вистачає векторної гілки, а на змішаних гібрид піднімає в топ-3 те, що чистий смисловий пошук втрачав.
Технічні сумніви перед інтеграцією LlamaIndex
Перед інтеграцією LlamaIndex інженерні команди задають ті самі питання: де буде жити індекс, що станеться зі сховищем при зростанні бази, як оновлювати документи і хто отримає доступ до даних. Нижче — відповіді по суті, без загальних слів.
Чи можна розгорнути все у своєму контурі?
Так. Застосунок, векторне сховище та моделі піднімаються всередині вашої інфраструктури, назовні не йде жоден фрагмент документа. Зовнішні сервіси підключаються лише там, де ви це дозволите явно.
Яким буде навантаження на сховище?
Індекс займає помітно більше місця, ніж вихідні тексти: зберігаються вектори та метадані фрагментів. Обсяг рахуємо заздалегідь і розділяємо гарячий індекс та архів — зростання бази не перетворюється на некеровану лавину.
Як оновлюється індекс?
Переіндексація йде за розкладом або за подією зміни документа, перераховуються лише зачеплені фрагменти. Повне перезбирання залишається страховкою і виконується в окремому контурі, не блокуючи видачу відповідей.
Як забезпечується приватність даних?
Права доступу успадковуються з джерела: співробітник бачить у відповіді лише ті фрагменти, до яких у нього є доступ. Запити та відповіді логуються, історія залишається у вас.
Скільки зусиль потребує супровід?
Основне — якість даних і контроль дрейфу: метрики влучання у відповідь, моніторинг порожніх видач, регламент оновлення. Налаштовані оповіщення знімають більшу частину ручної роботи.
Розкажіть про задачу — повернемося з оцінкою та планом
Щоб повернутися з оцінкою робіт і планом впровадження, потрібен мінімум ввідних — зазвичай вони збираються за один прохід і відразу знімають половину уточнювальних дзвінків.
Нижче список того, що прискорює старт проєкту: чим конкретніші ввідні, тим точніше ми називаємо етапи, трудовитрати та ризики.
- Склад даних. Які джерела індексуємо (файлові сховища, база знань, внутрішні портали, таблиці), у яких форматах, який сумарний обсяг і як часто контент змінюється. Окремо — хто власник кожного джерела і через кого оформлюються доступи.
- Сценарії запитів. 15-30 реальних формулювань від ваших співробітників, включно з тими, де пошук зараз дає неправильний результат. На них ми налаштовуємо розбиття документів на фрагменти і підбираємо ваги пошуку.
- Вимоги до відповіді. Чи потрібне посилання на першоджерело, допустима затримка відповіді, мова видачі та що вважається помилкою: пропуск факту чи впевнена неправильна відповідь.
- Контур розміщення. Хмара чи закрита інфраструктура, вимоги служби безпеки, розмежування прав за ролями — від цього залежить схема зберігання індексу та режим доступу до моделі.
- Поточні напрацювання. Чим уже користуєтеся для пошуку та зберігання векторів, чи є прототипи на LlamaIndex — працююче не переписуємо, вбудовуємо в нову схему.
- Критерії приймання. Частка коректних відповідей на тестовому наборі питань, час відгуку, набір питань-провокацій, на яких перевіряємо стійкість.
- Люди та строки. Хто приймає рішення з боку замовника, хто тестує і до якої дати потрібен робочий контур.
Опишіть задачу у вільній формі — можна без таблиць і точних цифр на першому кроці. Повернемося з оцінкою, планом впровадження за етапами та списком ввідних, яких не вистачило для розрахунку.
