Виправити помилки в роботі АІ агента з векторною базою
5920 UAHПривіт.
Роблю застосунок. Система збудована таким чином: Користувач дає запит в чаті застосунку - Агент АІ шукає інформацію в БД і дає відповідь. Якщо запит користувача виходить за рамки БД, тоді агент звертається до Gemini.
БД - Supabase. Туди залиті дані з двох державних сайтів по API.
В бекенді збудований флоу в n8n (той самий агент). Він бігає по базі і дає відповіді та коментарі.
В Supabase стаорені таблиці з даними з 2 сайтів. Вони об єднані в 1 таблицю document_chunks
Проблема - Агент АІ знаходить інформацію тільки 1 таблиці а даних другої якби не бачить. Навіть якщо дати запит і скопіювати дані які треба знайти (ми знаємо що ці дані там є), то агент не знаходить.
Також необхідно збудувати алгоритм для пошуку для агента. База інформації величезна і я так розімую агент не знає що є релевантиним а що ні. Бракує системи "кластерів" пошуку.
Щодо різної метадати. це не помилка, а архітектурне рішення. В одній таблиці зберігаються два принципово різні типи документів:
Законодавство (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.
Додатки 1
-
2 дні11 961 UAH
272 1 2 дні11 961 UAHДоброго дня,
Я проаналізував проблему з вашим агентом ШІ і визначив основну причину — векторна конкуренція між двома різними типами документів в одній площині. Документи Верховної Ради (структуровані статті) завжди виграють у рішеннях SAOS (неструктурований юридичний текст) при стандартному векторному пошуку.
Рішення
Архітектура з двома незалежними потоками пошуку:
Класифікатор запиту — визначає тип пошуку (закон/прецедент/обидва)
Паралельний пошук — окремі запити з оптимальною конфігурацією
Інтелектуальне з'єднання — об'єднання з крос-посиланням (рішення → закони)
… Оптимізація витрат API
Поточна система: ~$0.20-$0.25/запит
Нова система: ~$0.03-$0.04/запит
Зменшення: 85% (при 1000 запитів/місяць = економія ~800 PLN/місяць)
Обсяг робіт
Виконаю віддалено (9-10 годин):
Аналіз і технічний план (2-3 години)
Функції SQL + конфігурація (2-2.5 години)
Класифікатор запитів (2 години)
Основний n8n workflow (3-3.5 години)
Виконаєте самостійно (економія ~4-5 годин):
Міграція даних (готовий SQL скрипт з інструкцією)
Імпорт workflow + конфігурація облікових даних
Тестування за чек-листом
Тонка настройка параметрів
Отримаєте: SQL скрипти, n8n workflow JSON, інструкції покроково, чек-лист, підтримка Telegram
Оцінка
Стандартний розрахунок: 1000-1350 PLN (9-10 годин × 25-30 EUR)
Пропозиція: 990 PLN
Знижка ~30% від стандартної ставки
Опціонально: повне впровадження "під ключ" +200 PLN (дебагінг TeamViewer, розширене тестування)
Якщо пропозиція влаштовує, можемо почати з аналізу (2-3 години) — отримаєте конкретний план і підтвердження здійсненності.
З повагою,
Євгеній
-
1 день6041 UAH
1562 7 0 1 день6041 UAHя входжу до топ-5 розробників у категорії «Штучний інтелект і машинне навчання» серед ~2100 фахівців на платформі.
Гарантую:
- Швидке та якісне виконання завдання
- Чітке дотримання дедлайнів
- Регулярний зв'язок протягом усього процесу
Буду радий обговорити деталі вашого проекту у приватних повідомленнях.
ціна умовна
-
3 дні6041 UAH
1539 4 0 1 3 дні6041 UAHДоброго дня. Подивився опис проблеми типовий кейс
Схоже, що частина даних або не проіндексована через embeddings, або просто не потрапляє в пошук. Плюс зараз у агента немає нормальної логіки відбору, тому він губиться у великій базі і не розуміє, де що шукати.
Я працював із Supabase, vector search і RAG-системами. Можу Знайти, чому друга частина даних не знаходиться Перебудувати логіку пошуку Зробити так, щоб Gemini підключався тільки коли в БД реально немає відповіді
У результаті агент почне стабільно знаходити дані і відповідати адекватно.
Готовий подивитись на вашу поточну реалізацію і запропонувати рішення.
-
15 днів60 409 UAH
12784 4 2 15 днів60 409 UAHПривіт,
Я дуже зацікавлений у покращенні можливостей пошуку вашого AI Агенту та забезпеченні надійного отримання як законодавства Сейму, так і рішень суду SAOS. У мене є великий досвід у створенні та оптимізації бекенд-систем з великими, багатосутнісними базами даних, включаючи Supabase/PostgreSQL, а також у інтеграції робочих процесів пошуку на основі векторів.
Я можу реалізувати надійний, гібридний алгоритм пошуку, який враховує кілька типів документів, покращує рейтинг релевантності в великих наборах даних і впроваджує кластеризацію або обізнане про сутності отримання, щоб забезпечити, що AI Агент не пропускає жодне джерело. Мені комфортно працювати з робочими процесами n8n, вбудовувати моделі, такі як Google Gemini, і розробляти масштабовані рішення для обробки великих обсягів структурованих даних.
Я впевнений, що можу покращити логіку пошуку, підвищити точність результатів і забезпечити, щоб AI Агент повністю використовував ваш об'єднаний набір даних.
З найкращими побажаннями,
… Джо Вінсент Карретас
-
5 днів12 082 UAH
3160 23 1 3 5 днів12 082 UAHВітаю, Максиміліан! З розумінням на вашу ситуацію, пропоную інтегративний підхід для вирішення проблеми з АІ агентом. Спочатку займаюся детальним аудитом існуючого флоу в n8n та структури вашої бази Supabase. Опираючись на мій досвід в проектуванні архітектур систем, швидко виявляю та вирішую проблему з пошуком серед "document_chunks". Крім того, розроблю оптимальний алгоритм кластеризації, що підвищить точність і релевантність результатів агента. Налаштую систему для безперебійної та масштабованої роботи. Обговоримо проєкт далі?
-
1 день6041 UAH
2226 46 0 1 день6041 UAHДоброго дня. Без реального розуміння того, що у вас там зроблено, важко сказати реальні терміни та вартість. Пишіть в ЛС, обговоримо детальніше. Поки що лише попередні питання.
Ви впевнені, що у вас дві таблиці? Чи, можливо, у вас дві БД? За зображенням нічого не зрозуміло, крім того, що є одна таблиця. Що в цій таблиці означає стовпець chunk_index?
Якої розмірності ембедінги? Які розміри чанків? Чому сапбейс, а не спеціалізовані рішення?