Poprawić błędy w pracy agenta AI z bazą wektorową

W kwestii różnej metadanych. to nie jest błąd, a rozwiązanie architektoniczne. W jednej tabeli przechowywane są dwa zasadniczo różne typy dokumentów:

Ustawodawstwo (Sejm) - ma strukturę "Artykuł/Paragraf".

Orzeczenia sądowe (SAOS) - mają strukturę "Numer sprawy/Sąd". To, że w niektórych wierszach są jedne pola, a w innych są NULL — to normalna praktyka dla mieszanych baz danych. To pozwala Agentowi zrozumieć, czy cytuje on ustawę, czy wyrok sądu. Ujednolicenie ich jest niemożliwe, ponieważ są to różne byty.

W kwestii „zapisujemy jedne wektory, szukamy inne”.

I do zapisu w bazie (parsowanie), i do wyszukiwania (agent) używana jest ta sama model — Google Gemini Embeddings.

Wymiar wektora jest stały — 768.

Gdyby rozmiary się różniły, baza danych zgłosiłaby błąd transakcji już na etapie zapisu lub wyszukiwania, a system w ogóle by nie działał.

W kwestii "wyszukiwania w kilku etapach" - a tutaj chyba się zgadzam, bo innych opcji nie znalazłem, prawdopodobnie trzeba wdrożyć hybrydowe wyszukiwanie

Wektory formuje model Google Gemini Embeddings przez API.

Technicznie jest to zrealizowane przez węzeł Google Gemini Embeddings w n8n, który wysyła tekst na serwery Google, otrzymuje w odpowiedzi wektorową tablicę embedding i przekazuje ją do zapisu w bazie danych.

Wejściowe zapytanie jest przekształcane na wektor za pomocą modelu Google Gemini.

W Supabase wywoływana jest funkcja, która porównuje wektor zapytania z wektorami dokumentów w bazie.

Wyniki są sortowane według współczynnika podobieństwa (od największego do najmniejszego).

Baza zwraca ustaloną liczbę Top-K najbardziej relewantnych fragmentów tekstu, niezależnie od tego, czy to ustawa Sejm, czy orzeczenie sądowe SAOS, które następnie są przekazywane do kontekstu SI.

Fizycznie w bazie dane są. Sprawdziłem to przez bezpośrednie zapytania do bazy danych — zapisy orzeczeń sądowych SAOS zostały załadowane poprawnie.

Agent nie widzi tych orzeczeń w momencie formowania odpowiedzi. Agent SI podczas wyszukiwania nie może poprawnie dopasować ludzkiego pytania do tekstów prawnych orzeczeń sądowych. Widzi ustawy Sejm, ale „pomija” wyroki SAOS i to jest główny problem.

Cała logika i struktura projektu są zrealizowane standardowo w ramach twojego konta Supabase (PostgreSQL). Nic zewnętrznego ani ukrytego tam nie ma.

Funkcje wyszukiwania to standardowe funkcje SQL, znajdują się bezpośrednio w schemacie bazy danych.

Rozmiar wektora, ten parametr jest wyraźnie określony w typach danych kolumn tabeli z dokumentami.

Każdy programista, mając dostęp do bazy, może uzyskać te informacje w minutę, po prostu przeglądając strukturę Schema i listę funkcji przez zapytanie SQL lub interfejs Supabase.

Wiersze, w których sejm_id jest, a saos_id — NULL to akty prawne. Pochodzą z bazy polskiego Sejmu. Ponieważ to ustawa, ma numer w rejestrze Sejmu, ale nie jest orzeczeniem sądowym, więc nie może mieć saos_id.

Wiersze, w których saos_id jest, a sejm_id — NULL to orzeczenia sądowe z bazy SAOS. Każdy wyrok ma swój unikalny numer w systemie sądów. Ale wyrok — to nie ustawa, Sejm go nie uchwalił, więc nie ma i nie może mieć 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.