Мой RAG-агент с множеством баз и своим подходом к чанкингу основан, по сути, на бесплатных решениях. Но ключевая идея — в создании отказоустойчивой схемы, которая должна пытаться получить лучший возможный ответ в текущий момент.
Иерархия запросов: от лучших моделей к локальным
Процесс получения ответа должен быть многоуровневым. По сути, есть одна задача — «спросить у ЛЛМ», но внутри неё должна быть разветвлённая схема.
Вот как я это вижу:
- Попытка №1: API крупных моделей. Сначала система дёргает крутые модели типа GPT или Gemini по API.
- Попытка №2: Веб-интерфейс крупных моделей. Если что-то пошло не так (API недоступен, ошибка), она должна идти в них через веб-интерфейс. С API пока вопрос, но его можно будет заменить модулем с Playwright.
- Попытка №3: Модели попроще. Если и это не сработало, пробуем API систем послабже.
- Попытка №4: Веб-интерфейс моделей попроще. Аналогично, используем веб-версию как запасной вариант.
- Последний рубеж: Локальная модель. Если вообще беда, идём к локальной модели.
Логирование качества и будущие улучшения
Важно не просто получить ответ, а понимать его происхождение. В ответе нужно уточнять, что он получен, например, от локальной модели, и хранить это в базе данных.
Нужно продумать структуру, где я смогу логировать уровень качества ответа. Это позволит в будущем, при появлении доступа к более крутым моделям, повышать качество уже сгенерированных ответов.
А в будущем появятся ещё более крутые, специализированные модели. Например, модель-монстр, заточенная специально под психологию. Тогда ничто не помешает мне психологический чанк отправлять именно к ней. Эта гибкость и есть цель текущей архитектуры.
Добавить комментарий