Нехай точні терміни та значення працюватимуть разом у пошуку
Об’єднайте лексичні та семантичні списки кандидатів, не розглядаючи некомпатibilні оцінки пошуку як взаємозамінні.
Розробник, який шукає ERR_CACHE_STALE, очікує саме цей код помилки. Інший розробник може описати ту саму проблему як «додаток постійно відображає дані вчорашнього дня». Корисний пошук знань має вміти обробляти обидва типи запитів.
Лексичний пошук є корисним, коли саме написання слів несе інформацію. Семантичний пошук може пов’язувати різні описи однієї ідеї. Поєднання цих двох методів дає кожному з них можливість знайти докази, які пропускає інший.
Рішення щодо дизайну визначає, де саме відбувається це поєднання.
Надати кожному засобу пошуку доступ до корпусу
Припустимо, семантичний пошук знаходить двадцять кандидатів, а потім лексичний оцінювач сортує їх. Це може покращити їхній порядок, але точний збіг поза першими двадцятьма залишиться непоміченим.
Щоб охопити більше кандидатів, застосуйте обидва методи пошуку до відповідного корпусу та об’єднайте їхні результати. У обох варіантах використовуйте однакові правила та фільтри відбору джерел. Документ, виключений через невизначеність його ідентичності, не повинен потрапити назад за допомогою другого пошуковика.
Це безпосередньо ґрунтується на інвентаризації джерел: пошук має базуватися на доказах, які ви готові використати.
Об’єднайте ранги перед тим, як створювати арифметику оцінок
Оцінка BM25 та оцінка косинусової схожості відображають різні обчислення. Їх пряме додавання дає число, але це число не має автоматичного значення як комбінована релевантність.
Метод взаємного об’єднання рангів пропонує просту основу. Кожен список з рангами вносить значення, залежне від позиції кандидата:
fused_score(document) = sum(1 / (c + rank_in_list))
Ранги починаються з одиниці. Список не вносить жодного внеску до документа, який він не отримав. Додатня константа c контролює наскільки різко змінюється внесок між позиціями.
Перевагою є простота роботи: для об’єднання не потрібно, щоб масштаби оцінок збігалися. Недоліком є те, що це призводить до втрати інформації про амплітуду оцінок. Два сусідні результати отримують схожий внесок, навіть якщо один з пошукових механізмів вважав їх дуже різними.
Зберігайте константи та кількість кандидатів у налаштуваннях, а потім оцінюйте їх. Це вибір проектувальника, а не гарантія релевантності.
Усувати дублікати за ідентифікатором, а не за назвою
Два пошукові механізми можуть повернути один і той самий фрагмент. Об’єднайте цей фрагмент за його стабільним ідентифікатором, щоб обидва ранги вносили внесок у одного кандидата. Не вважайте його двома окремими доказами.
Назви є слабкими ідентифікаторами. Різні статті можуть мати спільну назву, а назва однієї статті може змінитися. Корисний ключ фрагмента включає ідентифікатор джерела, версію контенту та місцезнаходження фрагмента.
Також необхідно розрізняти точні дублікати та сусідні фрагменти в одному розділі. Останні можуть знадобитися для об’єднання пізніше, як описано в методі об’єднання фрагментів для збереження доказів.
Перевіряйте типи запитів окремо
Використовуйте принаймні три групи запитів: точні ідентифікатори, концептуальні описи та їхні поєднання. Порівнюйте лише лексичний пошук, лише семантичний пошук та результат об’єднання.
Перевірте, чи потрапляють відповідні докази до списку кандидатів, перш ніж оцінювати якість відповідей. Якщо об’єднання допомагає при концептуальних запитах, але шкодить запитам з точними кодами помилок, загальний середній показник може приховати важливе погіршення.
Невелика технічна бібліотека може вже добре функціонувати з використанням лексичного пошуку. Додайте семантичне пошукове забезпечення, якщо кількість невдалих пошуків дозволяє це зробити. Зберігання лексичного базового рівня також дозволяє побачити користь від додаткових механізмів.
Передайте корисний список далі
Процес фузії створює список, а не фактичний висновок. Документ із високим рейтингом все одно може бути застарілим, неповним або неактуальним щодо важливих критеріїв у запитанні.
Наступний етап може переоцінити кандидатів, використовуючи більш сильний сигнал релевантності. Але жоден наступний етап ранжування не зможе врятувати докази, які ніколи не потрапили до списку. Спочатку виміряйте охоплення кандидатами; інакше ви можете оптимізувати порядок неправильних матеріалів.