Исправить ошибки в работе ИИ агента с векторной базой

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

Законодательство (Sejm) - имеет структуру "Статья/Параграф".

Судебные решения (SAOS) - имеют структуру "Номер дела/Суд". То, что в одних строках есть одни поля, а в других они NULL — это нормальная практика для смешанных баз данных. Это позволяет Агенту понимать, цитирует ли он закон или судебный приговор. Унифицировать их невозможно, так как это разные сущности.

Что касается «записываем одни векторы, ищем другие».

И для записи в базу (парсинг), и для поиска (агент) используется одна и та же модель — Google Gemini Embeddings.

Размерность вектора фиксирована — 768.

Если бы размеры отличались, база данных выдала бы ошибку транзакции еще на этапе записи или поиска, и система не работала бы вообще.

Что касается "поиска в несколько этапов" - а вот тут, наверное, согласен, так как других вариантов я не нашел, вероятно, нужно реализовать гибридный поиск

Векторы формирует модель Google Gemini Embeddings через API.

Технически это реализовано через ноду Google Gemini Embeddings в n8n, она отправляет текст на серверы Google, получает в ответ векторный массив embedding и передает его для записи в базу данных.

Входной запрос преобразуется в вектор с помощью модели Google Gemini.

В Supabase вызывается функция, которая сравнивает вектор запроса с векторами документов в базе.

Результаты сортируются по коэффициенту схожести (от наибольшего к наименьшему).

База возвращает установленное количество Top-K наиболее релевантных фрагментов текста, независимо от того, является ли это законом Sejm или судебным решением SAOS, которые затем передаются в контекст ИИ.

Физически в базе данные есть. Я проверил это через прямые запросы к базе данных — записи судебных решений SAOS загружены корректно.

Агент не видит этих решений в момент формирования ответа. ИИ-агент при поиске не может правильно сопоставить человеческий вопрос с юридическими текстами судебных решений. Он видит законы Sejm, но «пропускает» приговоры SAOS, и именно это главная проблема.

Вся логика и структура проекта реализованы стандартно в рамках вашего аккаунта Supabase (PostgreSQL). Ничего внешнего или скрытого там нет.

Функции поиска — это стандартные SQL-функции, они находятся непосредственно в схеме базы данных.

Размер вектора — этот параметр четко определен в типах данных колонок таблицы с документами.

Любой разработчик, имея доступ к базе, может получить эту информацию за минуту, просто просмотрев структуру Schema и список функций через SQL-запрос или интерфейс Supabase.

Строки, где sejm_id есть, а saos_id — NULL, это законодательные акты. Они приходят из базы польского Сейма. Поскольку это закон, у него есть номер в реестре Сейма, но он не является судебным решением, поэтому он не может иметь saos_id.

Строки, где saos_id есть, а sejm_id — NULL, это судебные решения из базы SAOS. У каждого приговора есть свой уникальный номер в системе судов. Но приговор — это не закон, Сейм его не принимал, поэтому он не имеет и не может иметь sejm_id.

Щодо різної метадати. це не помилка, а архітектурне рішення. В одній таблиці зберігаються два принципово різні типи документів:

Законодавство (Sejm) - має структуру "Артикул/Параграф".

Судові рішення (SAOS) - мають структуру "Номер справи/Суд". Те, що в одних рядках є одні поля, а в інших вони NULL — це нормальна практика для змішаних баз даних. Це дозволяє Агенту розуміти, чи цитує він закон, чи вирок суду. Уніфікувати їх неможливо, бо це різні сутності.

Щодо «записуємо одні вектори, шукаємо інші». 

І для запису в базу (парсинг), і для пошуку (агент) використовується одна й та сама модель — Google Gemini Embeddings.

Розмірність вектора фіксована — 768.

Якби розміри відрізнялися, база даних видала б помилку транзакції ще на етапі запису або пошуку, і система не працювала б взагалі.

Щодо "пошуку в декілька етапів"  - а ось тут мабуть погоджуюсь, бо інших варіантів я не знайшов, напевно треба реалізовувати гібрідний пошук

Вектори формує модель Google Gemini Embeddings через API.

Технічно це реалізовано через ноду Google Gemini Embeddings у n8n вона відправляє текст на сервери Google, отримує у відповідь векторний масив embedding і передає його для запису в базу даних.

Вхідний запит перетворюється на вектор за допомогою моделі Google Gemini.

У Supabase викликається функція, яка порівнює вектор запиту з векторами документів у базі.

Результати сортуються за коефіцієнтом схожості (від найбільшого до найменшого).

База повертає встановлену кількість Top-K найбільш релевантних фрагментів тексту, незалежно від того, чи це закон Sejm, чи судове рішення SAOS, які далі передаються в контекст ШІ.

Фізично в базі дані є. Я перевірив це через прямі запити до бази даних — записи судових рішень SAOS завантажені коректно.

Агент не бачить цих рішень у момент формування відповіді. ШІ-агент при пошуку не може правильно зіставити людське питання із юридичними текстами судових рішень. Він бачить закони Sejm, але «пропускає» вироки SAOS і саме це головна проблема.

Вся логіка та структура проекту реалізована стандартно в межах вашого акаунта Supabase (PostgreSQL). Нічого зовнішнього чи прихованого там немає.

Функції пошуку це стандартні SQL-функції, вони знаходяться безпосередньо в схемі бази даних.

Розмір вектора цей параметр чітко визначений у типах даних колонок таблиці з документами.

Будь-який розробник, маючи доступ до бази, може отримати цю інформацію за хвилину, просто переглянувши структуру Schema та список функцій через SQL-запит або інтерфейс Supabase. 

Рядки, де sejm_id є, а saos_id — NULL це законодавчі акти. Вони приходять з бази польського Сейму. Оскільки це закон, у нього є номер у реєстрі Сейму, але він не є судовим рішенням, тому він не може мати saos_id.

Рядки, де saos_id є, а sejm_id — NULL це судові рішення  з бази SAOS. У кожного вироку є свій унікальний номер у системі судів. Але вирок — це не закон, Сейм його не ухвалював, тому він не має і не може мати sejm_id.