Научете за Okapi BM25, алгоритъм за извличане, базиран на „торба с думи“.

Дигитализацията е съсредоточена около принципа „клиентът на първо място“ и оттогава е инструмент за обогатяване на потребителското изживяване. Тази статия ще обясни как алгоритъмът Okapi BM25 се използва за подобряване на уместността на търсенето и потребителското изживяване в дигиталния свят.

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

Така че най-добрият подход е да отидете при собственика на книжарницата, който ви задава някои въпроси:

  • Кой жанр бихте искали - технически, научна фантастика, комедия, романтика, трилър, фантастика?
  • Кой език предпочитате - английски, френски?
  • Трябва ли да е подходящ за начинаещи, средно напреднал или експерт?
  • Някакви предпочитания към автора?

Въз основа на вашите отговори собственикът на книгата филтрира набора от книги, които най-добре отговарят на вашите нужди, и споделя примерен комплект с вас. Сега задачата ви е сведена до намирането на този, който ви харесва най-много от тези, които ви се сервират въз основа на вашето обяснение/взаимодействие със собственика на книгата.

Сега разширете тази аналогия към дигиталното изживяване и вижте как събираме изискването и какви са общите терминологии, за да зададем контекста за останалата част от нашата дискусия:

  • Намерете документа или елемента, който представлява интерес за потребителя: Сега нямаме лукса на собственика на книгата, който може да разбере намерението ни, като ни задава допълнителни въпроси. Трябва да обясним интереса си, като използваме достатъчно низ за търсене, за да покажем исканите ресурси.
  • Интересът се улавя в заявката за търсене: това е, на което потребителят очаква компютърът да намери съвпадение. Трябва да взаимодействате с компютър/цифрова система, която има алгоритъм, за да съпостави вашата заявка за търсене с най-близките артикули в техния магазин.
  • Най-подходящите резултати трябва да се показват в горната част: Имайте предвид, че заявката за търсене не сочи към един документ. Извлечените документи трябва да бъдат подредени в низходящ ред според това колко подходящи са за потребителя. В аналогията с книжарницата ви беше представен набор от проби, за да изберете най-доброто, което ви интересува. Тук се нуждаете от система, която може да сортира резултатите вместо вас.

Основната тема е да се гарантира, че потребителите могат ефективно да взаимодействат със системата и имат достъп до ресурсите, които търсят.

Ако все още не разбирате какво е заявка за търсене, как изглеждат резултатите и се интересувате да знаете как подреденият по ранг набор от показани елементи се променя с промяна в заявката ви, не се притеснявайте. Ще обясня с примерите по-долу:

Ако търсите „синя рокля за момиченце“, отидете на най-известния пример за система за извличане на информация, т.е. търсачката на Google.

Обърнете внимание, че ако промените заявката на „синьо горнище за момиченце“, резултатите се променят, както следва:

Продължавайте да отбелязвате как изричното споделяне на спецификациите на вашия продукт променя дисплея. Сега, ако искате да посочите изискването за „цял ръкав“

Досега трябва да сте запознати с това какво е запитване и как то може да бъде основният двигател за получаване на продукта, който ви интересува. Този процес се нарича извличане на информация.

„Извличане на информация“ е процес на получаване на ресурси на информационната система, които са подходящи за информационна нужда от колекция от тези ресурси.

Търсенето може да бъде пълнотекстово или контекстно.

Търсенето в пълен текст работи, като изследва всички думи във всички съхранени документи, за да съответства на намерението на потребителя, посочено в заявката за търсене.

Работи сравнително добре върху малък набор от документи, мислете за него като по-скоро като grep. Но в момента, в който говорите за мащаб, т.е. голям набор от документи или увеличени заявки за търсене, това не работи. Това е мястото, където индексирането и търсенето са полезни.

Сигурно си мислите колко трудно е за един компютър да ми даде това, което искам, ако собственик на книжарница може да го направи. Е, позволете ми да изброя възможните проблеми:

  • Съдържанието в интернет не е ограничено само до книжарница, която е хоствала хомогенен набор от артикули, т.е. само книги. Собственик на книжарница, който е експерт в работата си, може бързо да ви достави книгата, но може да се провали, ако го помолите да ви достави правилните дрехи. И така, много интернет потребители имат широк спектър от изисквания към разнородни набори от продукти, вариращи от джаджи, храна, облекло, обувки и т.н.
  • Заявките, идващи от потребители с различен опит, Това, което се случва в крайна сметка е, че заявките са конструирани по различен начин от различните потребители и се очаква машината да разбере всичко и да бъде уместна
  • Освен това потребителите обикновено не използват повече от 3-4 думи, за да уловят интересите си.
  • Предполага се, че отговорът е бърз — бихте ли изчакали, след като въведете заявка за търсене в Google, толкова, колкото бихте чакали собственикът на магазина да се върне. Няма право.
  • Дори и с индексиране не можете да индексирате всички документи, не всички документи са еднакви, някои са по-информативни от други.

Най-важното нещо, което трябва да имате предвид, когато изграждате и внедрявате своя модел? Разбиране на вашата крайна цел. „Прочетете нашето интервю“ с експерти по машинно обучение от Станфорд, Google и HuggingFace, за да научите повече.

Така че това не е лесна задача и изисква усъвършенствани алгоритми, един от които е BM25.

Нека научим няколко концепции, преди да навлезем дълбоко в BM25.

  • Честота на термина: Честота на срещане на ключова дума за заявка в документа
  • Обратна честота на термина: важността на ключовата дума в броя на документите
  • Уместност: въпрос за милиони долари, нали? Типичният алгоритъм за машинно обучение няма да може да се наслаждава на производствения път, освен ако не бъде оценен като добър. По същия начин уместността за потребителите трябва да бъде измерена и оценена с помощта на определени показатели като прецизност и запомняне.
  • Точност — От всички върнати резултати, колко са уместни (от 4 върнати резултата, 1 зелен и 3 червени, само 1 резултат е уместен, т.е. 1/4). Предполага се, че други извлечени резултати са уместни, т.е. 3 червени точки в синята област, но не са. Следователно, маркирани като фалшиви положителни резултати, където положителното е „уместно“.
  • Припомняне — От всички уместни резултати, колко извлечени резултати са уместни (един зелен върнат от 3 уместни зелени резултата, т.е. 1/3)

  • Имайте предвид, че ако трябва да подобрите запомнянето, в крайна сметка ще направите компромис с Precision, тъй като сега извличате много документи, които ще доведат със себе си и неподходящи документи. Това добавя повече фалшиви положителни резултати, като по този начин намалява прецизността.

Okapi BM25:

BM25 означава „Най-добро съвпадение 25“ и се основава на добре познатия TF-IDF (метод за оценяване на термини) и оценява документи, свързани със заявка. BM25 постига резултати над TF-IDF чрез отчитане на дължината на документа и честотното насищане на термина.

Функцията BM25 изглежда така:

където q: термин на заявката и „i“ представлява i-тия термин на заявката

например: „Здравей, аз съм Видхи“ има q0 = Здравей, q1 = Аз, q2 = съм, q3 = Видхи

Индивидуалните резултати се изчисляват за всеки термин на заявка и след това се сумират, за да се стигне до крайния резултат за релевантност на заявката за търсене.

Обратна честота на документа:

Означава колко често се среща даден термин във всички документи, налагайки наказание на общи думи. Например „аз“ се среща по-често от „съм“ и „видхи“.

Следователно по-редкият термин получава по-висок множител, така че неговият принос към крайния резултат е по-голям.

Дължина на документа:

fieldLen/avgFieldLen е съотношението на дължината на документа спрямо средната дължина на документа. Той казва, че ако документът е по-дълъг от средната дължина на документите в корпуса, тогава неговият документ има повече термини и трябва да получи по-малка оценка.

Можете да проверите с формулата по-долу, тъй като съотношението е в знаменателя, то е обратно пропорционално на оценката за релевантност.

Помислете за термин на заявка, който се появява в документ от 100 думи срещу документ от 1000 думи, кой трябва да бъде претеглен повече?

Параметри: b и k

b е множителят на съотношението на дължината на полето. По-висока стойност на b предполага повишен ефект на съотношението на дължината на документа в сравнение със средната дължина. По същия начин, b= 0 → няма ефект от дължината на документа върху резултата, остава само k.

k означава насищане на честотата на термина, т.е. трябва ли термините, появяващи се повече пъти в документ, да продължат да добавят към повишен резултат или има фактор на насищане, който контролира честотния компонент.

Например TF/IDF води до по-голям резултат за термин, който се появява повече пъти в документ, докато BM25 претегля това въздействие до конкретен праг и изглажда ефекта му известно време по-късно (примерна честота от 10 тук)

За да обобщим, способността на BM25 да изчислява резултата за уместност въз основа на средната дължина на документа, увеличената честота на термините, влиянието на дължината на документа го прави по-стабилен по отношение на подхода TF/IDF.

Ако искате да научите повече за Okapi BM25, какви са другите функции за класиране, подробности за обърнатия индекс и как изчисленията на релевантността се различават въз основа на променящите се параметри, уведомете ме в коментарите и аз ще ги напиша в следващия си блог.

Дотогава, приятно учене.

Бележка на редактора: Heartbeat е онлайн публикация и общност, ръководена от сътрудници, посветена на предоставянето на първокласни образователни ресурси за наука за данни, машинно обучение и практици в дълбокото обучение. Поели сме ангажимент да подкрепяме и вдъхновяваме разработчици и инженери от всички сфери на живота.

Редакционно независим, Heartbeat е спонсориран и публикуван от Comet, MLOps платформа, която позволява на учените по данни и екипите на ML да проследяват, сравняват, обясняват и оптимизират своите експерименти. Ние плащаме на нашите сътрудници и не продаваме реклами.

Ако искате да допринесете, преминете към нашата покана за сътрудници. Можете също така да се регистрирате, за да получавате нашите седмични бюлетини (Deep Learning Weekly и Бюлетин на Comet), да се присъедините към нас в Slack и да следвате Comet в Twitter и LinkedIn за ресурси, събития и много повече, което ще ви помогне да изградите по-добри ML модели, по-бързо.