Розв'язання проблеми мільярда векторів в Azure AI Search
By Mirko Peters ·
Дізнайтеся про унікальні технічні виклики пошуку у величезних наборах даних у масштабі. Цей допис розбирає, як висока розмірність і обмеження пам'яті впливають на робочі навантаження корпоративного ШІ.
Automatically translated with AI from the original post. Read the English original
Дізнайтеся про унікальні технічні виклики пошуку у величезних наборах даних у масштабі. Цей допис розбирає, як висока розмірність і обмеження пам'яті впливають на робочі навантаження корпоративного ШІ.
Проблема мільярда векторів в Azure AI Search
Виклики пошуку векторів у масштабі мільярдів
Проблема мільярда векторів виникає, коли вам потрібно індексувати та шукати у величезних наборах даних для корпоративного ШІ. Робота з мільярдами векторів створює унікальні технічні виклики. Вам потрібно побудувати ефективні системи індексування, які обробляють великі обсяги даних без втрати швидкості. Оновлення в реальному часі важливі, адже ви хочете, щоб результати пошуку залишалися актуальними та релевантними. Керування високорозмірними embedding-ами також критично для точності результатів пошуку.
Коли ви працюєте з наборами даних масштабу мільярдів, стикаєтеся з низкою обмежень:
- Висока розмірність збільшує обчислювальні витрати та може уповільнювати пошук.
- Семантичний розрив між векторними представленнями та реальним змістом може призводити до неточностей.
- Збирання сміття стає складним, через що важко видаляти застарілу інформацію з індексів.
- Якість векторів залежить від обраної моделі embedding-ів, а це впливає на точність пошуку.
- Масштабування збільшує вимоги до пам'яті та може подовжувати час пошуку.
- Проблема холодного старту ускладнює пошук нових елементів без хороших векторних представлень.
- Інтерпретованість низька, тому зрозуміти, чому з'явився той чи інший результат пошуку, може бути непросто.
Ці виклики роблять проблему мільярда векторів однією з найскладніших у сучасному ШІ.
Чому вибір алгоритму важливий
Ваш вибір алгоритму безпосередньо впливає на те, як ви розв'язуєте проблему мільярда векторів. Якщо обрати алгоритм на кшталт HNSW, ви отримаєте швидкий доступ і ефективний пошук у великих наборах даних. Однак він потребує багато оперативної пам'яті, а це може підвищити витрати. Інші алгоритми, наприклад вичерпний KNN, забезпечують високу точність, але потребують значно більше обчислень, тому краще підходять для менших наборів даних. Правильний алгоритм допомагає збалансувати швидкість, точність і використання ресурсів. Ви можете оптимізувати продуктивність для свого конкретного застосунку, підібравши алгоритм під свої потреби. Це рішення визначає, наскільки добре ви впораєтеся з величезними наборами даних і скільки витратите на обладнання.
Огляд Azure AI Search
Azure AI Search дає вам потужну платформу для розв'язання проблеми мільярда векторів. Ви можете попередньо обробити дані за допомогою просунутих інструментів очищення та збагачення, що покращує якість векторів before індексуванням. Платформа організовує вашу інформацію у векторну базу даних, призначену для завдань пошуку та сучасних потреб пошуку. Ви отримуєте надійні функції пошуку та отримання, зокрема обробку природної мови для семантичного розуміння. Безпека забезпечена на високому рівні: шифрування та контроль доступу захищають ваші дані.
Azure AI Search бездоганно інтегрується з іншими службами Microsoft Azure та сторонніми платформами. Ви можете використовувати гібридний пошук, який поєднує пошук за ключовими словами та векторний пошук для найкращих результатів. Ранжування та налаштування релевантності дають змогу коригувати відображення результатів пошуку, роблячи їх корисними для користувачів. Платформа також пропонує розумні функції пошуку, як-от автодоповнення та пропоновані результати. Побудований на глобальній інфраструктурі Azure, Azure AI Search забезпечує масштаб і надійність, потрібні для величезних наборів даних і масштабних проєктів з даними.
Графовий індекс: HNSW і DiskANN

Що таке HNSW
Можливо, ви вже чули про hnsw, що розшифровується як hierarchical navigable small world. Цей алгоритм індексування на основі графа допомагає швидко знаходити схожі вектори у великих наборах даних. Hnsw будує багатошарову структуру графа, яка з'єднує точки даних так, що пошук виходить швидким і точним. Кожен шар графа має різну щільність: у верхніх шарах вузлів менше, а в нижніх – більше. Така конструкція дозволяє почати пошук зверху і рухатися вниз, поступово звужуючи результати. Hnsw оптимізовано для пошуку векторів у пам'яті, тому він зберігає весь граф в ОЗП. Такий підхід забезпечує результати з низькою затримкою, але водночас означає, що для зростаючого набору даних вам потрібно багато пам'яті.
Що таке DiskANN
Diskann – це відповідь Microsoft на виклики пошуку векторів у масштабі мільярдів. Цей індекс на основі графа використовує гібридний підхід, що поєднує пам'ять і сховище на SSD. Diskann дозволяє зберігати більшу частину індексу на SSD, які значно дешевші за ОЗП. У пам'яті ви тримаєте лише найважливіші дані для навігації. Така конструкція допомагає керувати величезними наборами даних без високих витрат на обладнання. Diskann використовує алгоритм графа Vamana, щоб спрямовувати пошук по даних. Також він застосовує спеціальний метод обрізання, який підтримує граф різноманітним і ефективним. Microsoft diskann лежить в основі Azure AI Search та інших сервісів, що робить його ключовою інновацією для корпоративного ШІ.
| Інновації | Опис |
|---|---|
| Швидкий пошук ANN | Архітектура Diskann дозволяє ефективно виконувати пошук ANN на SSD, що допомагає знизити витрати на обладнання. |
| Гібридна система пам'яті | Diskann поєднує DRAM і SSD, щоб керувати мільярдами точок на одній машині. |
| Економне зберігання | Diskann зберігає індекс ANN на диску, пропонуючи економне рішення для обробки багатовимірних даних. |
Як працює HNSW
Побудова графа
Hnsw будує свій індекс на основі графа, створюючи ієрархію графів пошуку. Ви починаєте з порожньої структури. Перший доданий вектор стає єдиним вузлом верхнього шару. Для кожного нового вектора hnsw випадковим чином визначає, у скількох шарах він має бути присутнім. Новий вектор з'єднується зі своїми найближчими сусідами в кожному шарі до досягнення призначеного максимуму. Верхній шар має найменше вузлів, тому він є зручною відправною точкою для пошуку. Нижні шари містять більше вузлів, що дозволяє виконувати детальний пошук. Hnsw може оновлювати граф без повного перебудування, тож ви можете додавати нові дані, коли потреби зростають.
Процес пошуку
Коли ви шукаєте з hnsw, ви починаєте з верхнього шару графа. Далекі зв'язки дозволяють швидко наблизитися до області, де може перебувати ваш цільовий вектор. Під час переходу вниз по шарах зв'язки стають щільнішими. Це допомагає уточнити пошук і наблизитися до найкращого збігу. На найнижчому шарі hnsw використовує променевий пошук, щоб знайти найближчих сусідів. Такий процес забезпечує швидкі й точні результати, особливо коли весь граф поміщається в пам'яті.
- Принципи конструкції Hnsw:
- Оптимізовано для операцій у пам'яті, що забезпечує низьку затримку і високу повноту пошуку.
- Використовує багатошарову структуру графа на основі мереж малого світу.
- Застосовує стратегію обрізання для видалення зайвих ребер і підтримки різноманітності.
- Пошук передбачає спуск по шарах: від розріджених далеких зв'язків до променевого пошуку на базовому шарі.
Як видно, і hnsw, і diskann використовують індекс на основі графа, але їхня конструкція відповідає різним потребам. Hnsw найкраще працює, коли все можна тримати в пам'яті. Diskann дозволяє масштабуватися до мільярдів векторів завдяки SSD, що робить його ідеальним для корпоративних навантажень в Azure AI Search.
Як працює DiskANN
Гібридна архітектура пам'яті та SSD
Для пошуку серед мільярдів векторів DiskANN пропонує унікальний підхід. DiskANN поєднує пам'ять і сховище SSD в гібридну архітектуру. Така конструкція дозволяє зберігати більшу частину векторного індексу на SSD, які коштують дешевше за ОЗП. У пам'яті ви тримаєте лише необхідні дані для навігації. Цей метод дозволяє масштабувати пошук до мільярдів векторів без дорогого обладнання.
DiskANN використовує два основні прийоми для оптимізації зберігання та швидкості:
- Граф Vamana: Ця структура забезпечує ефективну навігацію індексом.
- Квантування добутку (PQ): Ви стискаєте вектори в пам’яті, що зменшує використання оперативної пам’яті.
Ви отримуєте перевагу від дворівневого процесу виконання запиту. На першому етапі DiskANN використовує стиснуті за допомогою PQ вектори в оперативній пам’яті, щоб швидко визначити набір кандидатів. На цьому кроці читання з диска не потрібне. На другому етапі DiskANN отримує вектори повної точності з SSD для набору кандидатів. Далі ви обчислюєте точні відстані, щоб знайти найкращі збіги. Такий процес забезпечує високу повноту результатів і малу затримку, зберігаючи при цьому низькі вимоги до пам’яті.
Порада: Гібридна архітектура DiskANN з пам’яттю та SSD дозволяє виконувати пошук у масштабах вебу на звичайному обладнанні. Ви можете зберігати векторні індекси на SSD замість оперативної пам’яті, що робить великомасштабні застосунки доступнішими.
Процес пошуку
Пошук у DiskANN починається з навігації графом Vamana з використанням стиснутих векторів у пам’яті. Цей крок допомагає швидко знайти перспективних кандидатів. На цьому етапі ви уникаєте читання з диска, що прискорює процес. Щойно у вас є набір кандидатів, DiskANN переходить до наступного етапу.
Для кожного кандидата ви отримуєте з SSD вектори повної точності. Далі обчислюєте точні відстані між вашим запитом і цими кандидатами. Такий дворівневий процес гарантує точні результати без уповільнення пошуку. Висока повнота досягається тому, що DiskANN детально перевіряє найкращих кандидатів. Низьку затримку ви також зберігаєте, оскільки більшість роботи виконується в пам’яті.
Процес пошуку в DiskANN добре працює з масивними наборами даних. Ви можете обробляти мільярди векторів без потреби у великому обсязі оперативної пам’яті. Ви отримуєте швидкі й надійні результати навіть тоді, коли дані зростають. Це робить DiskANN сильним вибором для корпоративних навантажень ШІ в Azure AI Search.
| Крок | Що ви робите | Перевага |
|---|---|---|
| Фаза 1: навігація | Використовуйте стиснуті за допомогою PQ вектори в оперативній пам’яті, щоб знайти кандидатів | Швидкий пошук, без читання з диска |
| Фаза 2: уточнення | Отримайте вектори повної точності з SSD і обчисліть відстані | Висока повнота, мала затримка |
Ви бачите, що гібридна архітектура та процес пошуку в DiskANN допомагають ефективно розв’язувати проблему мільярда векторів. Ви можете масштабувати пошук, знижувати витрати та підтримувати продуктивність у міру зростання даних.
Переваги та недоліки
Плюси та мінуси HNSW
Ви часто обираєте hnsw для пошуку векторів, оскільки він забезпечує найвищу швидкість пошуку серед сучасних алгоритмів і високу повноту результатів. Коли ви правильно налаштовуєте hnsw, ви отримуєте швидкі результати та точні збіги. Він добре працює з високовимірними векторними даними, що важливо для сучасних навантажень ШІ. Також ви отримуєте перевагу від інкрементального додавання, тож можна оновлювати індекс без повного перебудовування.
| Переваги | Недоліки |
|---|---|
| Швидкість пошуку та висока повнота результатів на рівні сучасних алгоритмів за умови належного налаштування. | Висока витрата пам’яті через зберігання зв’язків графа для кожного вектора. |
| Добре працює з високовимірними даними. | Тривалий час побудови індексу з високоякісними параметрами побудови. |
| Ефективно підтримує інкрементальне додавання. | Складне видалення елементів може з часом погіршувати продуктивність. |
Масштабування hnsw ефективне, оскільки побудова індексу має складність O(N log N). Паралельна побудова дозволяє використовувати багатоядерні процесори, що прискорює процес. Використання пам’яті зростає лінійно з розміром набору даних, тож потреби в сховищі можна прогнозувати. Водночас весь граф必须 зберігатися в оперативній пам’яті, що обмежує масштабованість для наборів із мільярдами векторів.
Плюси та мінуси DiskANN
Ви звертаєтеся до diskann, коли потрібно масштабувати пошук векторів понад те, що може витримати оперативна пам’ять. Diskann оптимізований для використання SSD, що знижує витрати на обладнання та дозволяє керувати масивними наборами даних. Ви отримуєте високу точність і малу затримку, поєднуючи пошук в пам’яті з пакетним читанням із SSD. Diskann підтримує оновлення в режимі реального часу та гібридний пошук, тож ви можете ефективно фільтрувати й отримувати вектори.
Зверніть увагу на такі моменти щодо diskann:
- Економічно ефективне масштабування за рахунок використання SSD замість оперативної пам’яті.
- Висока точність і мала затримка у великих масштабах завдяки пошуку в пам’яті та читанню з SSD.
- Оновлення в реальному часі та гібридне поєднання векторного пошуку з фільтрованим отриманням.
- Побудова індексу відбувається повільно, оскільки конструювання графа Vamana є обчислювально витратним.
- Продуктивність залежить від пропускної здатності та затримки SSD.
- Оновлення обходяться дорожче, ніж у структурах, що зберігаються в пам'яті, як-от hnsw.
- Впровадження та налаштування потребують ретельної оптимізації.
Ви отримуєте перевагу від здатності diskann обробляти квантовані вектори: він стискає дані та покращує пошук з ефективним використанням пам'яті. Ви можете використовувати diskann для робочих навантажень із мільярдами векторів, не турбуючись про обмеження оперативної пам'яті.
Ефективність пам'яті та сховища
Вибираючи між hnsw і diskann для векторного пошуку, обов'язково враховуйте ефективність використання пам'яті та сховища. Hnsw добре працює з наборами даних, які вміщуються в оперативну пам'ять сервера. Ви отримуєте швидкий доступ і високу продуктивність, але не можете масштабуватися понад межі пам'яті. Diskann дозволяє збільшувати розмір набору даних до ємності диска, жертвуючи частиною швидкості заради місця для зберігання. Більшість індексу ви зберігаєте на SSD, тому diskann ідеально підходить для масивних наборів векторних даних.
| Характеристика | HNSW | DiskANN |
|---|---|---|
| Ефективність пам'яті | Дуже ефективний для наборів даних, що вміщуються в кеш сервера (оперативну пам'ять). | Призначений для наборів даних, які завеликі для оперативної пам'яті. |
| Ефективність сховища | Обмежений обсягом доступної оперативної пам'яті. | Розширює розмір набору даних до ємності диска, жертвуючи частиною швидкості заради місця для зберігання. |
| Оптимізація продуктивності | Використовує швидкий доступ до пам'яті для досягнення високої швидкості. | Мінімізує втрати продуктивності, пов'язані з повільнішим дисковим сховищем. |
| Придатність набору даних | Підходить для наборів даних, що вміщуються в оперативну пам'ять. | Підходить для масивних наборів даних, що перевищують обсяг оперативної пам'яті. |
І hnsw, і diskann використовують квантовані вектори, щоб зменшити потребу в сховищі та прискорити пошук. Гібридна архітектура diskann дозволяє масштабувати векторний пошук і водночас тримати витрати на низькому рівні. Ви досягаєте ефективного використання пам'яті для великомасштабних завдань пошуку, особливо коли працюєте з квантованими векторами та сховищем на SSD.
Порівняння алгоритмів векторного пошуку

Продуктивність у масштабі
Потрібно вимірювати, як алгоритм векторного пошуку працює зі зростанням набору даних. HNSW і DiskANN обидва прагнуть забезпечити високу повноту результатів і швидкість, але їхні стратегії відрізняються. HNSW спирається на графи в пам'яті, тож ви отримуєте швидкий пошук найближчих сусідів, коли вектори вміщуються в оперативну пам'ять. DiskANN використовує гібридний підхід із пам'яттю та SSD, тому ви можете масштабувати продуктивність пошуку, не турбуючись про обмеження пам'яті.
Коли ви виконуєте пошук найближчих сусідів серед мільйонів векторів, HNSW забезпечує високошвидкісне отримання результатів і низьку затримку. Ви можете налаштовувати параметри на повноту результатів або швидкість. DiskANN зберігає високу повноту та швидкість навіть тоді, коли набір даних зростає. Більшість індексу ви зберігаєте на SSD, що дозволяє обробляти мільярди векторів. Двоетапний пошук допомагає збалансувати швидкість і точність: перший етап знаходить кандидатів у пам'яті, а другий уточнює результати з використанням SSD.
Обидва алгоритми забезпечують високу повноту та швидкість, але DiskANN дозволяє масштабувати продуктивність пошуку за межі оперативної пам'яті.
Масштабованість для мільярдів векторів
Ви стикаєтеся з новими викликами, коли набір даних зростає від мільйонів до мільярдів векторів. HNSW добре працює з наборами до 50 мільйонів векторів. Ви використовуєте HNSW як алгоритм векторного пошуку за замовчуванням і налаштовуєте параметри на повноту результатів. Коли кількість векторів сягає від 50 до 500 мільйонів, ви впроваджуєте шардинг і скалярне квантування. Для підвищення ефективності можна використати двофазне отримання результатів. Для наборів понад 500 мільйонів векторів потрібне ієрархічне отримання результатів і багаторівневі архітектури. Для холодних даних використовуйте агресивне квантування.
| Діапазон кількості векторів | Стратегія HNSW |
|---|---|
| 1–50 млн | Використовуйте HNSW як алгоритм за замовчуванням, переконайтеся, що вектори вміщуються в оперативну пам'ять, і налаштовуйте параметри на повноту результатів. |
| 50–500 млн | Впровадьте шардинг, увімкніть скалярне квантування та розгляньте двофазне отримання результатів для підвищення ефективності. |
| понад 500 млн | Використовуйте ієрархічне отримання результатів, багаторівневі архітектури та агресивне квантування для холодних даних. |
DiskANN змінює правила гри для векторного пошуку у масштабі мільярдів. Більшість індексу ви зберігаєте на SSD, тож не маєте турбуватися про обмеження оперативної пам'яті. Для стиснення векторів використовуєте квантування добутку, а дані навігації тримаєте в пам'яті. Ви масштабуєте пошук найближчих сусідів до мільярдів векторів без втрати продуктивності пошуку. DiskANN підтримує наближений пошук на основі кластеризації та гібридне отримання результатів, що допомагає керувати масивними наборами даних.
DiskANN дозволяє масштабувати ваш алгоритм векторного пошуку на мільярди векторів, тож він ідеально підходить для корпоративних робочих навантажень.
Затримка запитів і пропускна здатність
Затримка запитів і пропускна здатність мають значення, коли ви виконуєте векторний пошук у масштабі. HNSW забезпечує низьку затримку для пошуку найближчих сусідів, оскільки тримає весь граф у пам'яті. Ви отримуєте швидкі відповіді на запити та високу пропускну здатність для наборів даних, які вміщуються в RAM. Коли набір даних зростає, затримка збільшується, оскільки доводиться шардувати дані або використовувати багаторівневі архітектури.
DiskANN використовує двоетапний процес пошуку. Спочатку ви шукаєте стиснуті вектори в пам'яті, що дає швидкий відбір кандидатів. Далі уточнюєте запит, отримуючи повноточні вектори з SSD. Такий підхід утримує затримку на низькому рівні та забезпечує високу пропускну здатність навіть для наборів даних на рівні мільярдів. Оптимізувати пошук можна, групуючи читання з SSD у пакети та використовуючи ефективні структури навігації.
DiskANN забезпечує високу повноту та швидкодію навіть тоді, коли кількість запитів зростає. Про обмеження пам'яті можна не турбуватися, тож ви можете масштабувати продуктивність пошуку для корпоративних застосунків.
DiskANN забезпечує стабільну затримку запитів і пропускну здатність, тому це надійний вибір для пошуку найближчих сусідів у великому масштабі.
Вплив на вартість і ресурси
Вартість і вплив на ресурси слід враховувати, коли ви обираєте алгоритм векторного пошуку для Azure AI Search. Те, як кожен алгоритм використовує пам'ять і сховище, впливає на ваш бюджет і на здатність масштабуватися.
DiskANN є найкращим вибором для робочих навантажень на мільярди векторів. Більшість індексу можна зберігати на SSD, які коштують дешевше за RAM. Така конструкція дозволяє масштабуватися від тисяч до мільярдів векторів без різкого зростання витрат на пам'ять. DiskANN добре підходить для продуктивних робочих навантажень ШІ, бо ефективно використовує SSD і тримає в пам'яті лише найважливіші дані.
HNSW найкраще працює з наборами даних середнього розміру. Весь індекс потрібно тримати в RAM, і ця вимога обмежує масштабування. Якщо набір даних стає надто великим, можуть зрости експлуатаційні витрати. HNSW також обмежений 2 000 вимірами, що може звузити сценарії використання.
| Тип індексу | Придатність для робочих навантажень на мільярди векторів | Вимоги до пам'яті | Експлуатаційні витрати |
|---|---|---|---|
| DiskANN | Так, розроблено для продуктивності SSD | Масштабується від тисяч до мільярдів векторів | Рекомендовано для продуктивних робочих навантажень ШІ |
| HNSW | Ні, підходить для наборів даних середнього розміру | Потребує, щоб індекс вміщувався в RAM | Обмежено 2 000 вимірами |
Порада: якщо ви хочете керувати витратами та масштабувати пошук до мільярдів векторів, DiskANN дає вам явну перевагу. Можна використовувати доступні SSD і тримати потреби в пам'яті на низькому рівні.
Практичні сценарії використання
Цінність цих алгоритмів добре видно в реальних застосунках. Багато організацій використовують DiskANN і HNSW для різних завдань векторного пошуку.
- Для наближеного пошуку найближчих сусідів можна використати економічний гібридний метод. Цей підхід поєднує зберігання на SSD зі структурами графа в пам'яті.
- DiskANN можна розгорнути для статичних наборів даних, наприклад корпусів досліджень, де дані змінюються нечасто.
- Ви можете обрати DiskANN для розгортань, чутливих до витрат. Він добре працює для застосунків на рівні мільярдів, де потрібно контролювати витрати.
- DiskANN можна використовувати для запитів, які витримують затримку менше 10 мілісекунд. Такої швидкості достатньо для багатьох корпоративних завдань пошуку.
- HNSW можна поєднати з дисковими інвертованими файлами (HNSW-IF) для гібридного пошуку. Цей метод забезпечує високу повноту та низьку затримку.
| Сценарій використання | Опис |
|---|---|
| Статичні набори даних | Ідеально для корпусів досліджень, де дані змінюються рідко. |
| Розгортання, чутливі до витрат | Підходить для застосунків на рівні мільярдів, де важлива вартість. |
| Запити, толерантні до затримки | Добре працює для запитів, які витримують затримку менше 10 мс. |
Примітка: багато організацій досягають повноти 90% при затримці 10 мс, використовуючи гібридні методи. Такої продуктивності достатньо для більшості корпоративних застосунків пошуку на основі ШІ.
Алгоритм слід підбирати відповідно до робочого навантаження. Якщо вам потрібно масштабувати систему, контролювати витрати й тримати затримку низькою, DiskANN дає гнучкість і ефективність, яких ви потребуєте.
Коли використовувати HNSW або DiskANN
Вибір правильного алгоритму для вашого навантаження в Azure AI Search може суттєво вплинути на швидкість, вартість і точність. Потрібно враховувати ваші дані, апаратне забезпечення та те, як часто дані змінюються. Розберімо основні критерії вибору, щоб ви могли обрати найкращий інструмент для векторного пошуку.
Критерії вибору
Розмір набору даних
Почніть із розміру вашого набору даних. Якщо ви працюєте з мільйонами векторів, hnsw забезпечує швидкий і точний пошук. Він найкраще працює, коли дані вміщуються в пам’ять. Коли набір даних зростає до мільярдів векторів, кращим вибором стає diskann. Він зберігає більшу частину індексу на SSD, тож вам не треба турбуватися про нестачу RAM.
| Критерій | HNSW | DiskANN |
|---|---|---|
| Розмір набору даних | Підходить для мільйонів векторів | Найкраще підходить для мільярдів векторів |
Як бачите, hnsw підходить для менших навантажень, тоді як diskann обробляє величезні набори даних без втрати швидкодії.
Апаратне забезпечення та вартість
Апаратне забезпечення і бюджет також відіграють велику роль. Hnsw потребує багато RAM, адже тримає весь граф у пам’яті. Зі зростанням векторної бази це може стати дорогим. Diskann допомагає заощадити, зберігаючи більшу частину індексу на SSD, які коштують дешевше за RAM. Вам потрібно лише достатньо пам’яті для навігаційної частини індексу.
| Критерій | HNSW | DiskANN |
|---|---|---|
| Інфраструктура | Вимоги до RAM | Зменшує витрати на пам’ять |
Якщо ви хочете утримувати витрати на низькому рівні й водночас шукати серед мільярдів векторів, diskann дає чітку перевагу.
Вимоги до затримки
Варто подумати, наскільки швидко вам потрібні результати пошуку. Hnsw забезпечує дуже низьку затримку, бо шукає в пам’яті. Результати можна отримати лише за кілька мілісекунд, якщо дані вміщуються в RAM. Diskann поєднує швидкість і масштаб. Він використовує двоетапний процес пошуку, тож результати залишаються швидкими навіть для величезних наборів даних. Для більшості корпоративних застосунків diskann утримує час запитів до 10 мілісекунд.
- Hnsw найкраще підходить для навантажень, де кожна мілісекунда має значення.
- Diskann добре працює, коли потрібно швидко шукати у великих наборах даних і можна прийняти невелике збільшення затримки.
Шаблони оновлення
На вибір впливає і те, як часто змінюються дані. Hnsw добре працює зі статичними або повільно змінюваними даними. Якщо ви часто оновлюєте вектори, може знадобитися перебудова індексу, а це займає час. Diskann краще адаптується до частих оновлень. Він зберігає точність і повноту результатів навіть тоді, коли ви часто додаєте або змінюєте вектори.
| Характеристика | HNSW | DiskANN |
|---|---|---|
| Затримка оновлення | Потребує повної перебудови індексу | Ефективно адаптується до змін |
| Повнота (recall) | Висока, але залежить від змін | Стабільна точність за частих змін |
Якщо ваш застосунок має обробляти багато оновлень, diskann дає більше гнучкості.
Типові сценарії
Реальні сценарії допоможуть визначити, який алгоритм вам потрібен.
| Метрика | HNSW | DiskANN |
|---|---|---|
| Середня повнота (recall) | 0.6 | 0.7 |
| Наскрізна точність | 0.972 | 0.933 |
| Robustness-0.2@10 | 0.998 | 0.984 |
| Robustness-0.9 | 0.84 | 0.81 |
- Hnsw забезпечує високу повноту і швидку пропускну здатність запитів. На наборах даних на кшталт SIFT1M можна досягти приблизно 95% recall@10 лише за 1–2 мілісекунди на запит на CPU.
- Diskann показує вищу середню повноту, тобто знаходить більше справжніх збігів у великих наборах даних. Він утримує високу точність навіть тоді, коли дані зростають.
- Hnsw найкраще працює для систем рекомендацій або пошукових систем, де потрібні найвища точність і швидкість.
- Diskann підходить для масштабного пошуку, наприклад серед мільярдів зображень товарів або документів, де потрібно збалансувати швидкість, вартість і масштаб.
Hnsw виділяється для навантажень, яким потрібен максимально швидкий пошук на менших наборах даних. Diskann найкращий, коли треба шукати в величезних масивах даних, не вийшовши за бюджет.
Міграція та гібридні підходи
Не обов’язково обирати один алгоритм для всіх ситуацій. Багато організацій починають із hnsw для менших наборів даних. Коли їхня векторна база зростає, вони переходять на diskann, щоб обробляти більше даних і стримувати витрати. Можна також використовувати гібридний підхід. Наприклад, найпопулярніші або нещодавні вектори можна зберігати в пам’яті з hnsw, а старіші чи рідко використовувані — на SSD з diskann.
- Починайте з hnsw для швидкого прототипування та невеликих навантажень.
- Переходьте на diskann, коли набір даних перевищує межі пам’яті.
- Поєднуйте обидва методи для найкращого балансу швидкості та масштабу.
Порада: регулярно переглядайте свої робочі навантаження. Оскільки дані та потреби змінюються, ви можете коригувати підхід, щоб отримувати найкращу продуктивність і цінність.
Розуміючи розмір набору даних, апаратне забезпечення, вимоги до затримки та характер оновлень, ви можете зробити обґрунтований вибір між hnsw і diskann. Це допомагає побудувати систему векторного пошуку, яка відповідає вашим цілям і зростає разом із бізнесом.
Найкращі практики векторного пошуку в Azure
Поради щодо конфігурації індексу
Високої продуктивності в Azure AI Search можна досягти, дотримуючись кількох важливих порад щодо конфігурації. Насамперед переконайтеся, що розмір індексу вміщується в одну одиницю векторного пошуку. Це допомагає зберегти швидкість і надійність пошуку. Намагайтеся мінімізувати розмір ваших вбудовувань (embeddings). Менші вбудовування прискорюють виконання запитів і збільшують кількість запитів за секунду. Використовуйте запити Approximate Nearest Neighbor для ефективності: вони прискорюють пошук без суттєвої втрати точності.
Тримайте кількість результатів на запит у діапазоні від 10 до 100. Такий діапазон зменшує затримку та забезпечує чутливість пошуку. Уникайте кінцевих точок моделей, які масштабуються до нуля, у продуктивному середовищі. Холодний старт може сповільнити пошук і дратувати користувачів. Плануйте пікові навантаження, щоб ваша система могла витримати раптове зростання трафіку пошуку. Використовуйте служебні принципали з токенами OAuth для безпечної та ефективної автентифікації. Завжди використовуйте останню версію Python SDK, щоб скористатися покращеннями продуктивності. Якщо вам потрібна вища пропускна здатність, масштабуйте кінцеву точку або розподіліть навантаження між кількома кінцевими точками.
Порада: добре налаштований індекс є основою оптимізованого векторного пошуку в Azure.
Моніторинг і оптимізація
Ви маєте постійно моніторити та оптимізувати систему пошуку, щоб підтримувати високу продуктивність, особливо для робочих навантажень із мільярдами векторів. У таблиці нижче наведено кілька ефективних методів:
| Метод | Опис |
|---|---|
| Багаторівневі індекси | Використовуйте швидкі індекси для гарячих даних і стискайте холодні дані, щоб заощадити місце. |
| Контроль fan-out | Керуйте взаємодією шардів і кластерів, щоб зменшити кількість мережевих переходів. |
| Квантування | Зменшуйте розмір векторів за допомогою методів на кшталт IVF-PQ, щоб вони вміщувалися в обмеження пам'яті. |
| Налаштування центроїдів | Змінюйте кількість центроїдів, щоб збалансувати повноту результатів і накладні витрати. |
| Асиметричне обчислення відстаней | Прискорюйте пошук, порівнюючи запити повної точності зі стиснутими векторами. |
| Цілеспрямована маршрутизація запитів | Використовуйте метадані та кластеризацію, щоб уникнути непотрібних широкомовних розсилок під час пошуку. |
| Мінімізація мережевих навантажень | Між вузлами передавайте лише ідентифікатори та оцінки, а не повні вектори. |
| Ієрархічна агрегація | Агрегуйте результати локально, щоб зменшити координацію та стабілізувати затримку. |
| Домінування пам'яті | Стежте, щоб вектори вміщувалися в пам'ять, для найкращої продуктивності пошуку. |
| Ситуативне використання GPU | Використовуйте GPU для індексації за потреби, але перевірте, чи вони справді підвищують пропускну здатність пошуку. |
| Якість мережі | Моніторте мережеві умови, адже вони впливають на затримку пошуку. |
Примітка: регулярний моніторинг допомагає вчасно помічати проблеми та підтримувати стабільну роботу пошуку.
Типові помилки
Під час налаштування чи масштабування системи пошуку в Azure можна зіткнутися з типовими помилками. Одна з них: дозволити індексу зрости занадто великим для однієї одиниці пошуку. Це може сповільнити запити та знизити надійність пошуку. Використання великих вбудовувань також може погіршити продуктивність. Завжди тримайте вбудовування якомога меншими для свого сценарію.
Ще одна помилка: ігнорувати пікові навантаження. Якщо ви не плануєте раптове зростання трафіку пошуку, система може не витримати тиску. Залежність від кінцевих точок, які масштабуються до нуля, може спричинити затримки холодного старту, що уповільнюють пошук. Незнайомство з оновленням SDK або відмова від токенів OAuth можуть призвести до ризиків безпеки та втрати можливих покращень продуктивності.
Пам'ятайте: уникайте цих помилок, щоб пошук залишався швидким, безпечним і надійним.
Дотримуючись цих найкращих практик, ви зможете побудувати надійний і ефективний пошуковий сервіс в Azure. Ви легко працюватимете з великими наборами даних і надаватимете користувачам швидкі й точні результати.
Проблему мільярда векторів в Azure AI Search вирішують, обираючи алгоритм, який відповідає вашим потребам. DiskANN забезпечує економічно вигідне масштабування для величезних наборів даних, а HNSW дає швидкі результати для менших навантажень. Ви підбираєте алгоритм під своє навантаження, масштаб і бюджет. Таблиця нижче допоможе вам вибрати найкращу кінцеву точку:
| Тип SKU | Сценарій використання |
|---|---|
| Стандартні кінцеві точки | Найкраще підходить для критичних вимог до затримки з індексами до 320 млн векторів. |
| Кінцеві точки, оптимізовані для зберігання | Ідеально для 10 млн+ векторів, коли допустима певна затримка і важлива економічна ефективність. |
- Оцініть потребу в сховищі, протестувавши на кількох документах.
- Закладіть у планування оновлення та загальний обсяг контенту.
Azure AI Search дає вам гнучкість і підтримує інновації Microsoft для корпоративного ШІ.
Поширені запитання
Яка основна відмінність між HNSW і DiskANN?
HNSW використовують для векторного пошуку в оперативній пам'яті. DiskANN дозволяє зберігати більшу частину індексу на SSD. Тому DiskANN краще підходить для роботи з мільярдами векторів без високих витрат на пам'ять.
Чи можна використовувати DiskANN для застосунків реального часу?
Так. DiskANN забезпечує пошук з низькою затримкою, зазвичай менше 10 мілісекунд. Його можна використовувати для завдань ШІ-пошуку в реальному часі, навіть з дуже великими наборами даних.
Як вирішити, який алгоритм використовувати в Azure AI Search?
Обирайте HNSW для менших наборів даних, які вміщуються в оперативну пам'ять. Обирайте DiskANN для величезних наборів даних, яким потрібне економічно вигідне масштабування. Враховуйте розмір даних, апаратне забезпечення та вимоги до затримки.
Чи потребує DiskANN спеціального апаратного забезпечення?
Ні. DiskANN можна запускати на звичайних серверах із SSD. Вам не потрібні дорогі машини з великим обсягом пам'яті. Так масштабувати систему простіше й дешевше.
Як Azure AI Search захищає ваші дані?
Azure AI Search використовує шифрування та контроль доступу. Ви контролюєте, хто має доступ до ваших даних. Засоби безпеки Microsoft допомагають захистити конфіденційну інформацію.
Чи можна оновлювати векторний індекс без простою?
Ви можете оновлювати індекси HNSW і DiskANN. DiskANN ефективно підтримує оновлення для великих наборів даних. Результати пошуку залишаються актуальними, а система не потребує відключення.
Які найкращі практики оптимізації продуктивності векторного пошуку?
Використовуйте менші embeddings, тримайте індекс в межах однієї search unit і відстежуйте затримку запитів. Завжди оновлюйте SDK і плануйте піки навантаження, щоб зберігати високу продуктивність.
🎧 Слухайте цей епізод
Хочете практичне пояснення теми HNSW проти DiskANN для векторного пошуку в Azure AI Search? У цьому епізоді тему розібрано простою мовою та пояснено, чому вона важлива для Microsoft 365, Azure, Power Platform, безпеки, ШІ та сучасної роботи.
Послухайте цей епізод, якщо хочете:
- Зрозуміти ключові концепції HNSW проти DiskANN для векторного пошуку в Azure AI Search
- Побачити, як це вписується в ширшу екосистему технологій Microsoft
- Дізнатися, де це може принести практичну користь вашій організації
Вам також можуть сподобатися пов'язані епізоди M365 FM:
- Як підвищити точність Microsoft Copilot понад векторний пошук
- Azure AI Search – просто пояснено
- Векторні бази даних – просто пояснено
- Microsoft Graph API Discovery для семантичного пошуку в організації
- Як налаштувати пошук SharePoint, щоб спочатку показувати потрібні файли
Відкривайте більше практичних розмов про Microsoft на M365 FM.
Останнє перевірення: липень 2026.
Кому варто послухати
Цей епізод призначено для адміністраторів Microsoft, архітекторів, розробників, фахівців з безпеки та бізнес-лідерів, яким потрібна практична основа перед ухваленням рішень щодо впровадження, експлуатації чи управління.
🎧 Вам також варто послухати
- Azure Resource Manager — наступний логічний крок для поглиблення цієї теми.
- Infrastructure as Code — наступний логічний крок для поглиблення цієї теми.
- Azure Policy — наступний логічний крок для поглиблення цієї теми.