У цій статті
Головна думка
Якщо потрібний уривок не потрапляє в модель, зміна промпта рідко допомагає. Оцінюйте пошук окремо: точні терміни, семантичні збіги, структура документів і ранжування виправляють різні причини помилок.
Розділяйте зовні схожі питання
«Як скинути цей пристрій?» і «Що означає помилка AX-204?» схожі на питання підтримки. Першому корисний семантичний пошук, якщо посібник використовує інші слова. Другому потрібен точний ідентифікатор. Зберіть невеликий набір обох типів, додавши абревіатури, різні мови та питання за кількома документами.
Попросіть експерта вказати потрібні уривки для кожного питання. Перевіряйте результати пошуку до генерації відповіді: плавний текст може приховати вибір посібника іншого продукту. Збережіть простий лексичний варіант як основу; складність виправдана, лише коли усуває конкретну помилку.
Поєднуйте точність термінів і смислове охоплення
Гібридний пошук поєднує повнотекстовий і векторний. Azure AI Search описує злиття паралельних списків через reciprocal rank fusion. Інженерна ідея — зберегти точні збіги й знаходити інакше сформульовані уривки. Підхід потрібно оцінювати: це не доказ переваги будь-якого гібридного налаштування над будь-яким векторним пошуком.
У нашому прикладі фільтри продукту й доступу мають збігатися в обох шляхах пошуку. Вивчіть внесок кожного шляху та чи не витісняють копії одного документа інші докази. Порівнюйте з базою на однакових питаннях і версіях джерел. Поліпшення середнього бала може приховувати погіршення для точних кодів помилок, найважливіших підтримці.
Два способи знайти ті самі докази
Приклади запитань підтримки. Порівняйте обидва шляхи на своїх документах.
Точні слова
«AX-204» → зберегти код помилки, назву продукту й ідентифікатори.
Сенс
«Пристрій не перезапускається» → знайти інструкцію з іншим формулюванням.
Об’єднані відомості
Об’єднайте кандидатів, видаліть дублікати й оцініть підсумкове ранжування.
Кожен фрагмент має бути зрозумілий окремо
Фрагмент — одиниця тексту для пошуку. Почніть зі структури документа: розділ із заголовком, повна процедура або таблиця з назвами стовпців. Поділ за однаковою кількістю символів може відірвати виняток від правила. Завелике перекриття створює дублікати й витрачає контекст.
Універсального розміру фрагмента без вивчення матеріалу немає. Перевірте кілька підходів на типових документах, зокрема сканах PDF і довгих таблицях. Зберігайте посилання на вихідне місце та сусідній контекст для виразів на кшталт «наступні умови». Якщо витягання втратило заголовок таблиці, дорога модель не відновить його надійно.
Додавайте переранжування за вимірюваної користі
Переранжування — повторне впорядкування знайдених кандидатів перед складанням контексту. Зберігши пошуковий механізм, порівняйте відібрані докази з цим етапом і без нього. Вимірюйте релевантні уривки нагорі списку, пропуски, затримку й вартість. Переранжувальник не врятує джерело, виключене хибним фільтром.
Зберігайте модульність для окремої перевірки підготовки запиту, пошуку й складання контексту. Документація RAG у Spring AI показує такий підхід через advisor API. До розширення запишіть виявлений дефект і очікуване поліпшення. Випускайте просту конфігурацію, якщо додатковий етап не поліпшує важливих питань.
Перевірте точне посилання й питання звичайною мовою
Візьміть два запити: «Помилка E-417 на контролері X2» і «контролер зупиняється, коли в приміщенні спекотно». Перший залежить від точного ідентифікатора; другому може знадобитися смисловий пошук, оскільки посібник називає проблему «тепловим вимкненням». Перевірочний набір має містити обидва типи, а не лише гладкі природні питання.
Вивчіть кандидатів до фінальної відповіді. Якщо потрібний посібник не потрапив до набору, переранжування не поверне його. Спочатку перевірте токенізацію ID, фільтри, мову й наявність документа. Якщо потрібний уривок є, але схований серед менш корисних, дослідіть ранжування. Так ви не змінюєте відразу три етапи й зберігаєте пояснення поліпшень.
Використовуйте матрицю помилок замість одного загального бала
Групуйте питання за помилками: точний код, перефразування, відсутнє джерело, неоднозначний продукт і суперечливі редакції. Порівнюйте конфігурації на однакових групах, зберігаючи знайдені уривки. Одне середнє приховує погіршення для кодів, якими підтримка користується найчастіше.
Вимірюйте час разом із релевантністю та обсягом контексту генерації. Більше уривків може означати вищу вартість і більше суперечностей без поліпшення відповіді. Виберіть ліміт кандидатів і стратегію переранжування за спостережуваними випадками, потім повторюйте перевірки після змін документів чи ембедингів. Результат — обґрунтоване рішення про якість пошуку, а не заява про універсальну перевагу гібридного підходу.
Знайдіть етап, що втратив доказ
Приклади діагностики; результати бенчмарків не маються на увазі.
Прокрутіть по горизонталі, щоб прочитати таблицю →
| Симптом | Що перевірити | Наступний експеримент |
|---|---|---|
| Точний код не знайдено | Індексацію, токенізацію, фільтри | Запит точного ідентифікатора |
| Перефразування не знаходить посібник | Семантичних кандидатів і охоплення | Порівняти лексичні й семантичні результати |
| Релевантний уривок занизько | Порядок кандидатів і дублікати | Оцінити переранжування на тих самих випадках |
| Хороший уривок, хибна відповідь | Генерацію та суперечливий контекст | Звірити твердження з вибраними доказами |
Джерела й додаткові матеріали
Документацію перевірено .
ЗАПИТАННЯ / РІШЕННЯ
Поширені запитання
Чи досить векторної БД для RAG?+
Вона підходить для першого пошукового конвеєра, але витягання документів, права, ранжування й оцінювання відповідей однаково потрібно проєктувати. Перевіряйте точні ідентифікатори нарівні з питаннями звичайною мовою.
Кожній RAG-системі потрібен переранжувальник?+
Ні. Додавайте його, коли порівняння на ваших питаннях показує, що поліпшення контексту виправдовує додаткову затримку й вартість.