единица 2 / 11

Вграждане и логика на векторна база данни

Печалби:

  • Разберете, че вграждането превръща текста във вектор в семантичното пространство и подобните значения са близки вектори
  • Обяснение как работи ANN търсенето с косинусови и точкови показатели за сходство
  • Избор на общи векторни бази данни въз основа на цена, мащаб и нужда от филтриране на метаданни

В основата на RAG е един единствен въпрос: "Коя част от текста е най-подобна на въпроса на потребителя?" Компютърът обработва текста с числа, а не буквално. Ето защо трябва първо да преобразуваме текста в числа, които носят неговия смисъл. Това е вграждането: процесът на преобразуване на текст в поредица от числа (вектор), който представя значението на този текст. Когато завършите този модул, ще знаете как работи вграждането, как се измерва приликата и как да изберете правилната векторна база данни.

Вграждане: Превеждане на значението в координати

Модел за вграждане (специално обучен изкуствен интелект) преобразува предоставения от вас текст във вектор от например 1024 числа. Мислете за този вектор като за координата в многомерно пространство. Магията е следната: близки по смисъл текстове попадат в близки координати в това пространство.

Прост пример: „годишен отпуск“, „право на отпуск“ и „годишен платен отпуск“ използват различни думи, но означават едно и също нещо — техните вектори са близки един до друг. „Сметка за заплати“ е друг въпрос - векторът му е далечен. Така че потребителят пита "колко дни ваканция имам?" Когато питате, дори можем да намерим документ, в който няма думата „отпуска“, а пише „годишният отпуск е 14 дни“. Това е, което класическото търсене по ключови думи (търсене, което съвпада точно с думата) не може да направи.

Съвет: Мислете за вграждането като за „пръстов отпечатък на смисъла“. Отпечатъците на две изречения с едно и също значение изглеждат подобни; Дори думите да са различни.

Важно правило: моделът, който използвате при вграждане на въпроса, трябва да бъде същият модел, който използвате при вграждане на документи. Различните модели създават различни пространства; координатите стават несравними.

Как да измерим сходството?

Има няколко метода за измерване колко сходни са два вектора. Най-често срещаното е косинусното подобие: то измерва ъгъла между два вектора. Ако ъгълът е малък (вектори сочат в една и съща посока), сходството е голямо. Стойността е между −1 и 1; Близо до 1 = много подобно.

критерий

Какво измерва?

Кога е за предпочитане?

Косинус

Ъгъл (посока) между векторите

Най-често срещаните; семантично сходство по подразбиране в текста

Точков продукт

Посока + големина заедно

Ако векторите са нормализирани, това дава същия резултат като косинус; е бърз

Евклидово (евклидово разстояние)

Право разстояние между координатите

В някои сценарии за групиране; по-малко използвани в текста

На практика повечето модели за вграждане произвеждат нормализирани вектори (размер, зададен на 1); В този случай косинусът и скалярният продукт дават същия ред. Не се парализирайте при вземането на решения: започнете с косинус.

Сред милиони вектори, сравняването им един по един е бавно. Ето защо векторните бази данни използват ANN (Approximate Nearest Neighbor) алгоритми. ANN намира "почти точно най-близкото", а не "точно най-близкото" много бързо. Например методът, наречен HNSW, може да върне резултати за няколко милисекунди дори за 10 милиона вектора. Печелите голяма скорост срещу малка жертва на точност.

Какво прави векторната база данни?

Векторната база данни прави три неща едновременно: (1) съхранява вектори, (2) бързо намира вектори, които са най-подобни на вектор на заявка, (3) филтрира по метаданни до всеки вектор. Метаданните са етикетите, които прикрепяте към тази част: изходен файл, дата, отдел, ниво на поверителност и т.н. Филтрирането на метаданни е критично в корпоративната RAG; защото трябва да можете да зададете ограничения като „търсене само в документите 2025 на финансовия отдел“.

# Регистрирайте се във векторната база данни (концептуална)vektor_db.add( id="izin-politikasi-parca-3", vektor=embed("Годишният платен отпуск е 14 дни..."), text="Годишният платен отпуск е 14 дни...", metadata={"source": "ik_el_kitabi.pdf", "department": "IK", "date": "2025-06", "поверителност": "ic"})

# Филтрирано търсене с метаданни (концептуален) резултат = vektor_db.search( vektor=embed("колко дни отпуск имам?"), top_k=4, filter={"department": "HR", "privacy": ["internal", "on"]})

Избор на правилната база данни

превозно средство

Представен аспект

Подходяща ситуация

Вграден/базиран на файл (вградена библиотека)

Без инсталация, една машина

Прототип, малък комплект (< няколкостотин хиляди части)

Управлявана облачна услуга

Мащабирането и поддръжката не са ваша отговорност

Продукция, бързо развиващи се данни, малък екип

Отворен код на вашия собствен сървър

Пълен контрол, вашите данни остават ваши

Задължение за поверителност, съществуваща инфраструктура

Допълнение към съществуваща база данни

Вие не управлявате отделни системи

Добавяне на векторна поддръжка към базата данни, която вече използвате

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

Слаб подход / силен подход

Слабо (съхранява обикновено вграждане, без метаданни):

Просто запазете текста и вектора. Търсене: връща 4-те най-сходни вектора.# Проблем: не може да се филтрира като "само текущи HR документи";# стари/неоторизирани части също могат да бъдат включени в отговора.

Мощен (богати метаданни + филтрирано търсене):

Добавете източник, дата, отдел и етикет за поверителност към всяко парче. Филтрирайте според авторитета и актуалността на потребителя по време на търсенето: filter = {"privacy": user_authority, "date_date": "2024-01"}# Така резултатът е едновременно безопасен и актуален.

Три мини калъфа

Случай 1 — Грешен микс от модели. Екип вгради документи с модел A и въпроси с модел B. Търсенията върнаха безсмислени резултати и процентът на верните отговори остана 31%. Когато преминах към един модел (и двата един и същ модел за вграждане), процентът скочи до 88%. Урок: въпросът и документът трябва да са на едно място.

Случай 2 — Риск за поверителността без метаданни. В здравна компания всички документи на отдела бяха хвърлени в един пул без метаданни. Когато сътрудник по продажбите зададе въпрос, системата контекстуализира част от данните на пациента. Когато бяха добавени метаданни + филтър (според нивото на оторизация), този риск беше елиминиран; При извличане 12 неразрешени бройки изобщо не са донесени.

Случай 3 — Тесни места в мащаба. Компания за електронна търговия претърси 8 милиона описания на продукти с прост метод "сканиране на всички"; Всяка заявка отне 6 секунди. Когато преминахме към базирана на HNSW ANN, времето намаля до 45 милисекунди, със само 1% загуба на точност. Урок: ANN е задължителен в големия комплект.

Често срещани грешки

  • Вграждане на въпроса и документа с различни модели: Резултатите са безсмислени; винаги един модел.
  • Пропускане на метаданни: Не можете да филтрирате; Губите контрол върху поверителността и актуалността.
  • Грешка за вграждане с криптиране: Вграждането носи обратима информация; Погрешно е да се приеме, че чувствителните данни са „скрити“.
  • Изграждане на ненужно голяма инфраструктура върху малък комплект: Гигантски клъстер, управляван от 5000 части, е ненужна сложност.
  • Не се притеснявайте много за критерия за сходство: Започнете с косинус в текста; Фината настройка идва по-късно.
Внимание: Вграждането вгражда значението на текста в числа, но не „унищожава“ съдържанието. Ако изтече векторна база данни, оригиналните съхранени текстове (в повечето инсталации текстът също се съхранява) също са компрометирани. Пазете векторното хранилище толкова поверително, колкото и документите в него.

В обобщение

  • Вграждането превръща текста във вектор от числа, който носи неговото значение; Подобни значения са близки вектори.
  • Сходството често се измерва чрез косинус; За нормализирани вектори точковият продукт дава същия резултат.
  • В големите данни ANN (напр. HNSW) замества точното търсене: голяма скорост с малка жертва на точност.
  • Векторната база данни изпълнява векторно съхранение + търсене по сходство + филтриране на метаданни; метаданните са от съществено значение за корпоративната RAG.
  • Въпросът и документът трябва да бъдат преведени с един и същ модел за вграждане; в противен случай координатите не могат да бъдат сравнени.

Задача за приложение

Извлечете 10 кратки пасажа (3-6 изречения всеки) от документа, който сте избрали в предишния раздел. (1) Проектирайте поне три маркера с метаданни за всяка част (източник, дата и трети, подходящ за вашия бизнес контекст: отдел, продукт, поверителност и т.н.). (2) Напишете кой филтър за метаданни трябва да се приложи за 3 различни потребителски въпроса. (3) Намерете 3 двойки въпроси, които изразяват едно и също значение в различни думи (напр. „право на отпуск“ ↔ „годишен отпуск“) и обяснете в едно изречение защо те няма да съответстват на търсенето по ключова дума, но ще съответстват на вграждането.

контролен списък

  • [ ] Мога да кажа, че вграждането превръща текста във вектор в семантичното пространство и подобни значения са близки.
  • Знам, че [ ] косинусното сходство измерва ъгъл и е предпочитанието по подразбиране в текста.
  • [ ] Мога да обясня защо ANN е необходим при големи данни.
  • [ ] Знам защо метаданните са критични за поверителността и контрола на актуалността.
  • [ ] Спазвам правилото за превод на въпроса и документа с един и същ модел на вграждане.