RAG с нуля

Зачем нужен RAG

Модель не знает ваших внутренних документов и выдумывает детали. RAG подкладывает в запрос куски из вашей базы, и модель отвечает по фактам, а не по памяти. Так строят чат-боты по документации, поддержку и поиск по архиву.

Как это работает в 4 шага

1. Режете документы на куски.
2. Превращаете куски в векторы через модель эмбеддингов.
3. На вопрос пользователя находите ближайшие куски по смыслу.
4. Кладёте найденное в промпт и просите модель ответить только по этому тексту.

Нарежьте документы с умом

Куски по 300-500 токенов с перекрытием в 50 токенов работают лучше всего. Слишком крупные размывают смысл, слишком мелкие теряют контекст. Режьте по абзацам и заголовкам, а не по символам вслепую.

Выберите векторную базу

Для старта хватит Chroma или FAISS, они поднимаются в пару строк кода. Когда данных станут миллионы, переходите на Qdrant или pgvector поверх привычного Postgres.

Соберите пайплайн

Возьмите модель эмбеддингов, прогоните через неё все куски один раз и сохраните векторы. На каждый вопрос считаете вектор запроса, достаёте топ-5 похожих кусков и склеиваете их с инструкцией «отвечай только по контексту ниже, если ответа нет, так и скажи».

Проверьте качество поиска

Слабое звено обычно не модель, а retrieval. Соберите 20 вопросов с известными ответами и проверьте, попадают ли нужные куски в топ-5. Если нет, чините нарезку и эмбеддинги, а не промпт.

Уберите галлюцинации

Попросите модель ссылаться на источник каждого утверждения и возвращать «не знаю», когда контекст пуст. Показывайте пользователю, из какого документа взят ответ. Это поднимает доверие и упрощает отладку.

Замерьте скорость и цену

RAG добавляет шаг поиска перед каждым ответом, и это время и деньги. Держите индекс горячей базы в памяти, считайте вектор вопроса быстро. Эмбеддинги обычно дешёвые, а раздутый контекст из десятка кусков бьёт по счёту за генерацию. Кладите в промпт топ-3-5 кусков, а не всё подряд.