Все сейчас строят RAG. Берут векторную базу, закидывают туда эмбеддинги, подключают LLM и говорят "у нас AI-поиск по документам". Красивая демка за 30 минут. А потом начинается прод и всё ломается.

Недавно на Towards Data Science вышла статья от инженера, который внедрял RAG нескольким корпоративным клиентам. Вот несколько уроков, каждый из которых стоил ему нервов и денег заказчика и что оказалось реально важно:

1. Люди не прощают уверенного вранья. Пользователь стерпит медленный интерфейс. Пользователь стерпит неудобный UX. Но если система с уверенным видом выдает неправильный ответ, доверие убито навсегда. Достаточно пары таких случаев, и народ уходит обратно в ручной поиск. Даже если потом систему починить, репутацию уже не вернуть.

2. Качество данных важнее выбора модели. Классика: Garbage In, Garbage Out. Многие команды тратят недели на сравнение GPT-4 и Claude, а потом выясняется, что пользователи злятся не из-за качества генерации, а потому что система ищет не в тех документах. 60% времени проекта надо закладывать на чистку и подготовку данных. Это не модная работа, но именно на ней проект живет или умирает.

3. Наивный чанкинг это преступление. Резать документы по 500 символов с перекрытием в 50 и надеяться на лучшее - это то, чему учат в туториалах. В реальности таблица с процедурой эскалации инцидентов не должна разрезаться пополам потому что превысила лимит символов. Структура документа - это семантическая информация. Её надо сохранять.

4. Чистый семантический поиск не работает. Когда человек ищет "ISO 27001", ему нужны документы с упоминанием ISO 27001. Ему не нужны "семантически похожие" результаты про "фреймворки информационной безопасности". Гибридный поиск (семантика + BM25) дает результат на порядок лучше.

RAG - это не MVP за выходные. Это серьезный инфраструктурный проект. Как только вы начинаете гонять через систему реальные данные в проде, все слабые места пайплайна вылезают наружу. Не гонитесь за трендом. Внедряйте ценность. #RAG #LLM #AI #ProductManagement #MLOps