Від документа до корисного фрагмента: retrieval pipeline

Релевантним фрагментам потрібен їхній контекст. Ілюстрацію створено за допомогою AI.

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

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

Розгляньмо вигаданий посібник із позичання обладнання. У розділі «Позичання обладнання» написано: «Продовження потребує погодження координатора до завершення поточного строку. Строк користування обладнанням, зарезервованим для іншого бронювання, продовжити не можна». Читач запитує: «Чи можу я залишити позичений проєктор довше?». Посібник, питання та всі наведені нижче фрагменти-кандидати вигадані; для цього прикладу жодну систему пошуку не запускали.

Корисна відповідь має врахувати і погодження, і виняток щодо бронювання. Фрагмент про продовження бронювання кімнати може бути схожим на запит, але стосуватися іншого об’єкта. Отже, ще до вибору методу пошуку маємо конкретну перевірку релевантності: чи відповідає вибране джерело на питання про позичене обладнання, не втрачаючи обмеження?

Обирайте межі, які зберігають потрібний контекст разом

Chunking розділяє матеріал на менші одиниці для опрацювання та пошуку. У рекомендаціях Microsoft щодо chunking розглянуто підходи з фіксованим розміром і з урахуванням структури, зокрема меж речень або заголовків. Також пояснено, що перекриття може зберігати зв’язність, водночас дублюючи частину вмісту. Доцільний вибір залежить від документів і питань; універсального розміру чи перекриття немає.

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

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

Представте питання та знайдіть кандидатів

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

Vector search порівнює представлення, щоб знаходити схожі елементи. В огляді Google BigQuery описано пошук семантично пов’язаних елементів за відстанями у просторі embeddings. Для питання до документів це допомагає відібрати фрагменти-кандидати, але не доводить, що кожен із них містить відповідь або що потрібне джерело взагалі знайдено.

Semantic search описує мету — зіставляти значення чи поняття, а не лише буквальні формулювання. Огляд vector search від Microsoft ілюструє цю відмінність та описує гібридне поєднання в Azure векторного пошуку й пошуку за ключовими словами. Ці ідеї пов’язані: пошук за змістом є метою, а порівняння векторів — одним із підходів, що може їй сприяти.

Читач каже «залишити довше», а уявний посібник — «продовження». Зіставлення за змістом могло б допомогти подолати різницю формулювань. Але воно також могло б повернути фрагмент про бронювання кімнат. Ми не обчислювали embeddings, оцінок чи порога, тому це можливості для перевірки, а не твердження про порядок результатів реальної системи.

Повторно ранжуйте лише ті фрагменти, що потрапили до набору кандидатів

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

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

Оцінюйте пошук і відповідь як окремі етапи

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

Наприклад, речення «Так, погодження координатора достатньо» відкидає виняток щодо бронювання. Це написаний автором контрприклад, а не згенерований результат. Обґрунтоване пояснення зберігало б умови, а не обіцяло продовження. Якщо наявні дані неповні, перевірка має зафіксувати прогалину, а не вигадати відсутнє правило.

Якщо ширше питання полягає в тому, чи потребує збій кращого промпту, пошуку або адаптації моделі, матеріал Prompting vs RAG vs Fine-Tuning пропонує рамку такого рішення. Тут завдання вужче: перевірити, як документ стає придатним доказом. Зберігайте контекст джерела, відрізняйте релевантність кандидата від фактичного підтвердження та оцінюйте відповідь за тим, що справді сказано у фрагментах.