Настройка PostgreSQL для LLM

Итак, в этой статье я расскажу, как эффективно настроить PostgreSQL, чтобы вам было проще работать с большими языковыми моделями.

Пока звучит странно, не правда ли? Что я имею в виду? Я имею в виду повышение эффективности создания любых SQL-запросов в базу данных с использованием LLM (ChatGPT, DeepSeek, Llama и других).

Метод, о котором пойдет речь, до безобразия прост и от этого гениален. После прочтения этой статьи вы сможете самостоятельно или в рамках вашей компании увеличить скорость формирования SQL-запросов в 50 раз!

Готовим БД

Очень важно подготовить PostgreSQL для работы с LLM.

Основные аспекты подготовки:

• Descriptive variables (Описательные переменные) – самодокументируемые, понятные переменные, названия которых позволяют понять их назначение без углубления в код.

• Constraints (Ограничения) – должны быть заданы на уровне базы данных. Даже если они прописаны в коде приложения, их необходимо задокументировать и реализовать в БД.

• Foreign Keys (Внешние ключи) – таблицы должны быть связаны друг с другом с помощью внешних ключей. Это поможет LLM правильно интерпретировать связи между данными и понимать структуру базы.

• Documentation (Документация) – критически важный пункт. Мы рассмотрим его подробнее, но сразу отмечу: без задокументированной базы данных эффективность работы с LLM значительно снижается.

Если все эти пункты соблюдены – отлично! Но, скорее всего, документации у вас нет. Сейчас я расскажу, почему её наличие принципиально важно.

Пишем документацию

Представим, что у вас уже развернута база данных, и она успешно работает. В ней есть несколько таблиц, например, Users или Roles, с различными полями: email, phone_number и так далее. Количество полей может быть любым – 10, 20, 30, это не столь важно. Главное, чтобы первые три пункта, о которых мы говорили ранее, были реализованы.

Теперь разберем четвертый пункт – документацию базы данных.

Что такое документация PostgreSQL?

Документация в PostgreSQL – это всего две простые команды:

COMMENT ON TABLE table_name IS 'Описание таблицы';
COMMENT ON COLUMN table_name.column_name IS 'Описание колонки';

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

create table public.users
(
    id            bigserial primary key,
    first_name    varchar(255),
    last_name     varchar(255),
    email         varchar(255) not null unique,
    password      varchar(255),
    type          varchar(50),
    is_active     boolean,
    registered_at timestamp    not null,
    jpeg_photo    bytea
);

-- Документация таблиц 
comment on table public.users is 'Таблица пользователей';

-- Документация колонок 
comment on column public.users.id is 'Идентификатор';
comment on column public.users.first_name is 'Имя пользователя';
comment on column public.users.last_name is 'Фамилия';
comment on column public.users.email is 'Электронный адрес';
comment on column public.users.password is 'Пароль';
comment on column public.users.type is 'Тип пользователя (CORE - из базы Метрик, LDAP - из базы LDAP или AD)';
comment on column public.users.is_active is 'Активен ли пользователь';
comment on column public.users.registered_at is 'Дата регистрации пользователя';
comment on column public.users.jpeg_photo is 'User photo in JPEG format';

В команде стоит взять за привычку документировать каждое поле, даже если его назначение кажется очевидным. Например, id – все и так понимают, что это идентификатор, верно? 🙂 Однако лучше все же прописать документацию везде. Это не только снижает вероятность “галлюцинаций” LLM, но и делает базу данных понятнее для всех, кто с ней работает.

Кстати, в примере я использовал комментарии на русском языке, но если в вашей компании принято использовать английский – это тоже отличный вариант.

Почему это важно?

Позже эта документация пригодится не только при работе с LLM, но и:

• Аналитикам – для быстрого понимания структуры данных,

• BI-специалистам – при построении отчетов,

• Другим разработчикам – чтобы быстрее разобраться в базе,

• Администраторам БД – для удобного сопровождения системы.

Как это выглядит?

В среде разработки JetBrains (например, DataGrip) такие комментарии отображаются прямо в интерфейсе. Аналогичная поддержка есть и в других инструментах работы с БД. Это делает работу с таблицами намного удобнее.

Но что действительно важно – это влияние документации на работу LLM.

По нашим замерам, LLM-модель работает в 4 раза лучше на задокументированной базе данных. Почему так происходит?

Контекст играет ключевую роль в понимании для нейросетей. Чем больше информации о структуре данных у модели, тем точнее и качественнее она формирует SQL-запросы.

В результате:

• Запросы становятся более корректными,

• Меньше ошибок и некорректных предположений,

• Генерация SQL-кода происходит быстрее,

• Улучшается интерпретация взаимосвязей между таблицами.

Таким образом, качественная документация не только упрощает жизнь разработчикам и аналитикам, но и значительно повышает точность работы LLM при генерации SQL-запросов.

При выгрузке DDL, документация выгружаются вместе с DDL, так как документация является частью схемы БД.

Зачем документация?

Кажды раз пред тем как делать SQL запрос с помощью LLM, стоит в 2 клика выгрузить DDL всей схемы БД, с документацией. Отправить в LLM со словами что бы она запомнила структуру.

И можно абсолютно простым чвеловеческим языком писать в LLM запрсоы достать ту или иную инфомрацию. Даже можно просто сообщения менеджера что-то достать перекидывать в LLM, потом сразу в SQL и доставать нужные данные. Что упростит работу с БД на 90%, и увиличит сокрость создания любых вопросов с данными с LLM на БД на 80%.

Что дальше?

Очевидное развитие этой технологии, что бы все это обновлялось автоматически при накате миграций, и учитывалось в Ci/CD и других процессах. В конечном итоге будет создан такой продукт. Где будет очень простой Web Ui, где челвоек просто задает ему вопросы, на обычном языке и получает грамотные ответы из БД срзу в Web Ui свой. И любой менеджер в компании сможет этим опльзоваться.

Если хотите разработать совместно со мной такой продукт на добровольных началах пишите мне личку или в телеграм если модератор позволит приложить сюда мой телеграм https://t.me/apan98