Появление генеративных моделей, а что еще более важно, появление их в широком доступе, разом изменило привычный "ландшафт" информационных технологий. Базы данных не остались в стороне. Как оказалось, с языком SQL большие языковые модели дружат чуть ли не лучше, чем со всеми остальными языками программирования. И это определенно дает новый импульс реляционным базам данных. Но только ли реляционным?

Проблема

Новые возможности приходят вместе с новыми трудностями. Технология GPT здесь не исключение. Первые попытки перейти от "баловства" к делу обозначили одну техническую проблему. Не то, чтобы она была и есть какая-то особо изощренная, но как-то ее надо решать.

Речь идет о размере того, что вы подаете на вход нейросети в процессе эксплуатации. Пока мы развлекались, задавая нейросети вопросы типа: что тяжелее, килограмм пуха или килограмм гвоздей, лимит в четыре тысячи токенов даже для русского языка (напомню, что в русском языке токены расходуются в несколько раз быстрее, чем в английском) казался вполне приемлемым. Четыре тысячи букв это относительно много. Вы только читать это будете примерно 4 минуты. Для "ха-ха-ха" за глаза хватит.

Лимит начинает "поджимать", когда мы пытаемся приспособить языковую модель к какому-нибудь реальному делу. В целом ряде случаев это означает, что мы неявно для пользователя прицепляем к его вопросу что-то еще. Например, я использую языковую модель для организации взаимодействия неквалифицированного пользователя с базой данных. Пользователь задает вопрос на человеческом языке. Я добавляю к его вопросу описание структуры базы данных и прошу нейросеть построить SQL запрос.

Есть и еще один способ рационального использования нейросети. Идея, что называется, лежит на поверхности. Мы организуем службу поддержки некоего продукта. Получаем вопрос пользователя. Если в этот момент мы заставим нейросеть (а куда она денется!) RTFM, то она ответит на вопрос пользователя в среднем лучше, чем человек. Потому что он, конечно, тоже когда-то RTFM, но это было давно и что-то он уже забыл. Идея вполне рабочая, но тут дело в том, что эти самые FM могут быть весьма объемными. Ни четыре, ни восемь, ни даже 32 тысячи токенов, которые нам обещают в GPT-4 может и не хватить.

Не стоит забывать, что эта проблема измеряется не только в токенах (или, если хотите, в байтах), но и в денежных единицах. Пока мы развлекаемся, а будущие возможные вендоры наперебой демонстрируют нам "аттракционы неслыханной щедрости" это не так заметно. Но, как говорят китайцы, "огонь в бумагу не завернешь". Каждое обращение к большой языковой модели это работа суперкомпьютера, а она стоит денег. Даже при весьма щадящих тарифах, которые сейчас предлагает OpenAI, наш гипотетический искусственный работник службы поддержки может оказаться "золотым".

И, наконец, есть еще один момент. Даже если прогресс приведет нас к тому, что мы не будем особо сильно ограничены ни токенами, ни деньгами, все равно останется вопрос качества. Дело в том, что с увеличением размера промта качество результата может внезапно упасть. Вот вам конкретный пример. Как я уже говорил, я организую взаимодействие пользователя с базой данных. У меня есть описание структуры базы данных. В этом описании есть таблица продаж. В таблице продаж поля прибыль и рентабельность. Тестирую на вопросах типа: 5 самых рентабельных товаров, прибыль за прошлый месяц и т.п. На выходе получаю нормальные SQL запросы. Все хорошо. В какой-то момент я решаю добавить в описание базы данных таблицу цен товаров. Типа: цена розничная такая-то, оптовая такая-то и т.д. Получаю неожиданный эффект. Теперь получив вопрос, касающийся прибыли, языковая модель начинает прыгать на одной ножке, размахивать руками и кричать: я знаю, знаю, знаю как считать прибыль! И начинает считать через цену товара. При том, что в схеме явно указано наличие готового расчета. Но языковой модели очень нужно продемонстрировать свою "умность".

Решение

Мы рассмотрели два случая. Хоть и по разным причинам, но и там, и там нам требуется каким-то образом разделить промт на части. Далее, в зависимости от того, какой вопрос мы получаем от пользователя, мы добавляем ту или иную часть.

Для решения этой задачи лучше всего подходят векторные базы данных. Векторные базы данных появились сравнительно недавно. Это не реляционные базы. И семейству NoSQL они тоже не принадлежат. Можно сказать, что они стоят особняком. Векторные базы данных предназначены для хранения и получения одного конкретного типа данных: векторных представлений (vector embeddings). Все что они умеют делать, и делают хорошо, это давать ответ на вопрос: к чему больше всего подходит вот этот текст. Собственно это нам и нужно. Будь то мануал или описание структуры базы данных, мы делим наш исходный большой промт на части. Получив на входе вопрос пользователя, определяем к какой части этот вопрос относится и используем эту часть в запросе.

Заключение

Векторные базы родились в мире искусственного интеллекта и машинного обучения. С появлением больших языковых моделей, векторные базы становятся полезными не только относительно узкому кругу тех, кто занят непосредственно обучением моделей, но и тем, кто пожинает плоды их труда, занимается эксплуатацией больших языковых моделей. К векторным базам данных следует присмотреться тем, кто позиционирует себя, как специалиста по базам данных.

Также хочу порекомендовать вам бесплатный вебинар, в рамках которого Вы узнаете:

• Какие вопросы нужно задать себе перед началом проектирования хранилищ данных в вопросе выбора архитектуры.

• Какие основные различия существуют между OLAP и OLTP.

• Какие ключевые особенности присущи различным архитектурам и как правильно скомбинировать оба решения.

• А также на практике построите архитектуру тестового хранилища прямо на занятии!

• Зарегистрироваться на бесплатный вебинар