Я создал RAG-приложение, а затем спросил его, какая машина мне нравится. Оно не знало ответа.

Я создал RAG-приложение, а затем спросил его, какая машина мне нравится. Оно не знало ответа.

Я разрабатываю инструмент для чата с документами под названием Kenning. Он использует RAG (Retrieval-Augmented Generation), чтобы пользователи могли задавать вопросы по загруженным файлам.

Я построил весь конвейер с нуля, используя:

• Java 21 и Spring Boot
• Spring AI
• PostgreSQL с pgvector
• Ollama (запускающая llama3.2:3b и nomic-embed-text)
• Docker Compose

Конвейер работает следующим образом: Загрузка файла → Извлечение текста → Разбиение на чанки → Преобразование чанков в векторы → Сохранение в pgvector → Поиск похожих чанков → Отправка чанков + вопроса модели → Получение ответа с источниками.

Система работала, но я столкнулся с двумя разными сбоями. Они выглядели одинаково, но причины были разными.

Сбой 1: Модель запуталась. Я спросил: «Какую модель эмбеддингов использует этот проект?» В документе был четко указан ответ. Модель извлекла правильный текст. Однако она ответила, что не знает, даже повторив правильное название модели в следующем предложении.

Моя теория: модель на 3B параметров слишком мала. Она извлекла верные данные, но не смогла дать уверенный ответ. Использование более крупной модели, скорее всего, решит эту проблему.

Сбой 2: Модель ничего не нашла. Я спросил: «Какая марка машины мне нравится?» В документе упоминалось, что мне нравится BMW. Но система вернула нулевой результат. Показатель сходства (similarity score) был слишком низким, чтобы преодолеть мой порог.

Моя теория: размытие чанка (chunk dilution). Мой тестовый документ был коротким. В одном чанке смешалось множество тем, таких как Spring AI, OAuth2 и мои предпочтения в автомобилях. Вектор этого чанка стал слишком «размытым» из-за всех этих тем. Специфический вопрос об автомобилях потерял свою силу на фоне слишком широкого чанка. Это можно исправить улучшением стратегии разбиения на чанки.

Извлеченные уроки:

• У маленьких моделей есть ограничения в рассуждениях.
• Наивное разбиение на чанки влияет на точность поиска.
• Поиск причины («почему») важнее, чем просто исправление ошибки.

Архитектура жизнеспособна. Она работает медленно и иногда ошибается, но цикл завершен.

Источник: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

Опциональное обучающее сообщество: https://t.me/GyaanSetuAi