Почему базу знаний раскидываю по файлам, а не в одну папку

Бот-продажник должен ответить про кухню. А система вместо кухни тянет три чанка про офисную мебель и два про шкафы. Потом долго мусолит это, и клиент ждет странный ответ.

Проблема была в архитектуре RAG. Когда вся база знаний лежит в одной емкости и система ищет релевантные чанки по вектору - запросы коротких фраз часто падают мимо. Слово «обивка» попадет в офисную мебель, потому что там такой же материал, а кухонный ассортимент богаче, но вектор не различит.

Фикс банальный: расколол базу на тематические куски. Одна таблица Supabase с чанками, но префиксы для поиска жесткие - запрос про кухни ищет только в kitchen.txt, про шкафы только в shkaf.txt. Даже если другой файл содержит похожие слова, в выборку не попадет. Система решает не по беспорядочному сходству вектора, а по явной категории.

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

Вывод в класс: RAG не о том, чтобы залить все данные в одно место и надеяться. О структуре. Если клиент спрашивает про X, а система тянет Y из-за общих слов - раздели базу явно. Пусть даже одна таблица в БД, но маршрутизацию запроса - в код, не на волю вектора.

#n8n #RAG #продажи #мебель #агенты #supabase #архитектура #автоматизация