Цей матеріал згенеровано за допомогою штучного інтелекту та опубліковано без попередньої перевірки людиною. Він може містити помилки і не є професійною консультацією. Повідомити про проблему: info@delionsoft.com.
MariaDB вже деякий час підтримує векторний пошук, але люди, які вирішують, яку базу даних використовувати в новому проєкті штучного інтелекту, часто навіть не чули про це. В інтерв’ю на Percona Live, про яке повідомило видання The Register, виконавчий голова MariaDB Foundation Кай Арно (Kaj Arnö) зазначив, що проблема полягає не в наборі функцій, а в видимості всередині асистентів кодування для штучного інтелекту, які за замовчуванням, як правило, рекомендують інші бази даних. Це невелика історія з важливим висновком: рекомендації за замовчуванням стають каналом розповсюдження.
Що сталося
MariaDB, яка відокремилася від MySQL у 2009 році, тепер підтримує векторний пошук — пошук записів за схожістю, а не за точним збігом, що є типовою вимогою для функцій пошуку та рекомендацій. Згідно з оригінальним повідомленням, Арно засмучений тим, що ця можливість не є широко відомою, і він частково пов’язує це з матеріалами, на основі яких навчалися інструменти штучного інтелекту: навчальними даними, які, можливо, були зібрані до появи цієї функції, а також документацією та прикладами в інших джерелах, які досі вказують на усталені альтернативи.
Репортер провів неформальну перевірку: на запитання, яку базу даних використовувати для векторного пошуку, Claude першою назвала PostgreSQL і не згадала MariaDB. На пряме прохання порівняти ці дві бази даних для виконання одного й того самого завдання вона надала детальну відповідь. Знання були наявні; просто їх не пропонували.
Арно порівнює цю ситуацію з ранніми часами ранжування пошукових систем, коли правила були непрозорими, і каже, що чесний шлях — це випустити цю функцію, задокументувати її та дозволити, щоб її використання генерувало матеріал. Це створює замкнуте коло: менше користувачів означає менше публічних прикладів, а це, у свою чергу, означає менше матеріалу, з якого можуть черпати інструменти. Він також прокоментував Galera — технологію кластеризації, майбутнє якої як відкритого програмного забезпечення є предметом дискусій, провівши межу між комерційними продуктами MariaDB plc та сервером, який захищає фундація.
Чому це важливо
Для невеликих команд практична проблема полягає не в маркетингових труднощах MariaDB, а у ваших власних архітектурних рішеннях. Якщо розробник будує проєкт, приймаючи все, що пропонує помічник, стек обирається за замовчуванням, яке відображає популярність у навчальних даних, а не вашу операційну реальність. Це може означати впровадження другого сховища даних поряд із базою даних, яку ви вже використовуєте, резервуєте, моніторите та знаєте, як відновити, лише тому, що інструмент це запропонував.
Є також аспект управління. Коли одні й ті самі значення за замовчуванням повторюються у тисячах проєктів, ринок непомітно звужується. Команди, які вже використовують MySQL, MariaDB або PostgreSQL, можуть виявити, що додавання векторних стовпців до існуючого екземпляра є дешевшим, ніж запуск спеціалізованого векторного сервісу, принаймні з тими обсягами даних, які насправді мають більшість малих та середніх підприємств.
Що робити
- Ставтеся до пропозицій асистентів як до першого варіанту. Коли у згенерованому коді з’являється нове сховище даних, чітко запитуйте, чи може ваша поточна база даних впоратися з цим завданням.
- Запишіть свій стандартний стек — базу даних, чергу, кеш — і додайте його до інструкцій репозиторію, які читають асистенти, щоб пропозиції виходили саме з ваших обмежень.
- Перш ніж впроваджувати окреме векторне сховище, оцініть обсяг даних, затримку запитів та визначте, хто буде ним керувати. Багато робочих навантажень цілком зручно розміщуються в існуючому реляційному двигуні.
- Якщо ви публікуєте документацію чи приклади, підтримуйте сторінки з описом можливостей актуальними та конкретними. Саме цей матеріал зрештою повторюють інструменти нижчого рівня.