RAG — retrieval-augmented generation — это схема, в которой языковая модель отвечает не «из головы», а по найденным фрагментам ваших документов. Сначала система ищет подходящие куски текста, затем модель формулирует ответ и ссылается на источник.
Звучит просто, и прототип действительно собирается за пару недель. Сложности начинаются, когда им пользуются сотни людей с разными правами доступа и документами, которые меняются каждый день.
Где это работает
Лучшие результаты — там, где знания уже записаны, но их трудно найти:
- регламенты и внутренние инструкции;
- техническая документация и паспорта оборудования;
- база ответов службы поддержки;
- договоры и типовые условия — для поиска, но не для юридических выводов.
Если ответ есть в документах, но сотрудник тратит на поиск больше пяти минут, RAG окупится.
Где не работает
Модель не исправит противоречивую документацию. Если в двух регламентах написано разное, система честно найдёт оба фрагмента, и ответ будет таким же противоречивым.
Второе ограничение — расчёты и аналитика. RAG хорошо отвечает на вопрос «как оформить возврат», но плохо — на «сколько возвратов было в марте». Для таких вопросов нужен доступ к данным, а не к текстам.
Как устроен поиск
Документы делятся на фрагменты, для каждого считается вектор — числовое представление смысла. Мы храним векторы прямо в PostgreSQL с расширением pgvector: одной базой меньше, а права доступа проверяются тем же запросом.
SELECT id, title, chunk
FROM doc_chunks
WHERE allowed_roles && $1
ORDER BY embedding <=> $2
LIMIT 8;
Фильтр по ролям стоит в том же запросе, что и поиск по сходству. Так модель физически не получит фрагмент, который сотруднику видеть нельзя.
С чего начать
- Выберите один процесс и одну группу пользователей.
- Соберите 30–50 реальных вопросов и правильные ответы на них.
- Проверьте, что ответы на эти вопросы действительно есть в документах.
- Запустите пилот на 2–4 недели и измеряйте долю верных ответов.
Если хотите обсудить пилот в вашей компании, напишите нам : разберём задачу и оценим сроки.