RAG, retrieval-augmented generation, чудово виглядає в демо. У production такі системи ламаються передбачувано: слабкий retrieval, вигадані цитати та нестабільні відповіді. Нижче чеклист, за яким ми перевіряємо систему перед запуском.
1. Якість retrieval
Стратегія chunking, вибір embedding-моделі та reranking зазвичай впливають сильніше, ніж сам LLM. Перевіряйте retrieval окремо, перш ніж додавати generation.
2. Цитування та grounding
Кожне важливе твердження має спиратися на джерело. Потрібні жорсткі правила цитування та fallback-поведінка на випадок низької впевненості.
3. Пайплайн оцінки якості
Зберіть датасет із реальних запитів та очікуваної поведінки. Відстежуйте hallucination rate, recall retrieval і стабільність відповідей у часі.
4. Спостережуваність
Логуйте входи й виходи retrieval, витрати токенів, затримки та користувацький feedback. Покращувати production-систему без спостережуваності неможливо.
5. Guardrails
Потрібні валідація входу, фільтрація виходу та контроль прав доступу. Production RAG будується на межах, а не лише на хорошому prompt engineering.
Ми запускали RAG-системи для support copilot, внутрішнього пошуку та процесів із важкими документами. Різниця між демо й production проходить саме по цьому чеклисту.