Data: как дать модели память

Модель может быть очень умной и при этом ничего не знать о вашей компании. Она знает общие закономерности из данных обучения, но не знает, какой тариф действует сегодня или что написано в договоре конкретного клиента.

Есть два способа решить эту проблему: изменить саму модель или дать ей доступ к нужной информации во время запроса. Для второго подхода используется RAG — Retrieval-Augmented Generation.

Разберём путь от текста до ответа: Embeddings → Vector DB → Retrieval → Reranking → RAG.

Embeddings: как превратить смысл в числа

📌 Что это: числовое представление текста, позволяющее сравнивать фрагменты по смысловой близости.

✅ Зачем: чтобы поиск находил не только одинаковые слова. Запрос «Как вернуть товар?» найдёт документ «Порядок оформления возврата».

⚠️ Ограничение: семантическая близость не всегда означает релевантность. Артикулы, номера договоров и коды часто требуют keyword или hybrid search.

Vector DB: где хранить embeddings

📌 Что это: система хранения и поиска векторов вместе с метаданными (документ, источник, дата, права доступа).

⚠️ С чем путают: с обычной базой данных. Vector DB не заменяет PostgreSQL или MongoDB. Они решают разные задачи и в реальной системе работают вместе.

✅ Популярные решения: Pinecone (облачный, простой старт), Weaviate (open-source, гибкий), Qdrant (быстрый), pgvector (расширение для PostgreSQL).

RAG: как дать модели знания без переобучения

💻 Схема: Запрос → поиск → релевантные фрагменты → контекст → модель → ответ.

✅ Главное преимущество: знания можно обновлять без изменения весов модели. Добавили новый документ в базу — после индексации система сразу может использовать его в ответах.

⚠️ Когда RAG недостаточен: он хорошо решает проблему доступа к информации, но не гарантирует, что модель научится стабильно следовать специфическому поведению или формату. Для этого нужна адаптация.

Chunking: как разбивать документы

Модель не может эффективно работать с бесконечным документом. Тексты разбивают на chunks (фрагменты) для индексации.

📌 Fixed-size: деление на фрагменты одинакового размера. Просто, но граница может пройти посреди важной мысли.

📌 Structure-aware: система учитывает заголовки, разделы и абзацы, сохраняя смысловые связи.

⚠️ Главная проблема: слишком маленький chunk теряет контекст, слишком большой добавляет шум и увеличивает стоимость обработки. Размер подбирается под конкретную задачу.

Retrieval + Reranking: как найти действительно нужное

Первый поиск может вернуть много похожих, но не самых полезных документов. Поэтому используют двухэтапную архитектуру:

1️⃣ Retrieval: система быстро находит набор кандидатов (например, 100 фрагментов из базы знаний).

2️⃣ Reranking: более точная, но медленная модель переоценивает эти 100 фрагментов и выбирает топ-10 самых релевантных для передачи в LLM.

Это идеальный баланс между скоростью (быстрый первичный поиск) и точностью (качественный reranking).

---

Источники:

• [Hugging Face Blog](https://huggingface.co/blog)

• [The Batch — Andrew Ng](https://www.deeplearning.ai/the-batch/)

• [Artificial Analysis](https://artificialanalysis.ai/)

• [REAL DIGITAL](https://t.me/digitalreal)