Correct the mistakes in the work of the AI agent with the vector database.

Regarding different metadata. this is not an error, but an architectural decision. One table stores two fundamentally different types of documents:

Legislation (Sejm) - has the structure "Article/Paragraph".

Court decisions (SAOS) - have the structure "Case Number/Court". The fact that some rows have certain fields while others are NULL is normal practice for mixed databases. This allows the Agent to understand whether it is citing a law or a court ruling. They cannot be unified because they are different entities.

Regarding "we record some vectors, we search for others".

Both for writing to the database (parsing) and for searching (agent), the same model is used — Google Gemini Embeddings.

The vector dimension is fixed — 768.

If the sizes were different, the database would have thrown a transaction error at the stage of writing or searching, and the system would not work at all.

Regarding "multi-stage search" - here I probably agree, because I found no other options, it probably needs to implement hybrid search

Vectors are formed by the Google Gemini Embeddings model via API.

Technically, this is implemented through the Google Gemini Embeddings node in n8n, which sends text to Google servers, receives a vector array embedding in response, and passes it for writing to the database.

The incoming request is transformed into a vector using the Google Gemini model.

A function is called in Supabase that compares the query vector with the document vectors in the database.

Results are sorted by similarity coefficient (from highest to lowest).

The database returns a set number of Top-K most relevant text fragments, regardless of whether it is Sejm law or SAOS court decision, which are then passed into the AI context.

Physically, the data is in the database. I checked this through direct queries to the database — records of SAOS court decisions are loaded correctly.

The agent does not see these decisions at the moment of forming the response. The AI agent cannot correctly match a human question with the legal texts of court decisions during the search. It sees Sejm laws but "skips" SAOS rulings, and this is the main problem.

All logic and structure of the project are implemented standardly within your Supabase account (PostgreSQL). There is nothing external or hidden there.

The search functions are standard SQL functions, they are located directly in the database schema.

The vector size is clearly defined in the data types of the columns in the document table.

Any developer with access to the database can obtain this information in a minute by simply reviewing the Schema structure and the list of functions through an SQL query or the Supabase interface.

Rows where sejm_id exists and saos_id is NULL are legislative acts. They come from the Polish Sejm database. Since this is a law, it has a number in the Sejm register, but it is not a court decision, so it cannot have saos_id.

Rows where saos_id exists and sejm_id is NULL are court decisions from the SAOS database. Each ruling has its unique number in the court system. But a ruling is not a law, the Sejm did not adopt it, so it does not have and cannot have 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.