Когда нужен RAG
Когда у компании есть существенный объём документов (договоры, регламенты, инструкции, переписка), и сотрудники тратят часы на поиск нужной информации. RAG — это не «загрузил всё в ChatGPT», это пайплайн: извлечение → чанкинг → embeddings → vector store → retrieval → reranking → generation.
Какие технологии использую
Vector DB: pgvector (PostgreSQL extension) для маленьких проектов до 100k чанков, Qdrant для среднего масштаба, Pinecone — только если у клиента уже есть. Embeddings — OpenAI text-embedding-3 или Cohere в зависимости от языка. Reranking — Cohere rerank или cross-encoder локально.
Подводные камни
RAG плохо работает на табличных и числовых данных — здесь нужна гибридная схема с SQL-агентом. Длинные документы требуют умного чанкинга по семантическим границам, а не просто разбивки по 500 токенов. Каждое внедрение начинаю с замера baseline на ручной выборке.
Что я делаю
Прохожу полный цикл: дискавери данных → пилот на 10–20 типовых запросах → запуск с метриками. Окупаемость считаю в сэкономленных часах на поиск умножить на количество сотрудников и стоимость их часа.