Информационный поиск

Semantic Search

2020 год. Google впервые за 20 лет меняет базовый алгоритм поиска. До BERT: PageRank + TF-IDF + 200 сигналов. После: трансформер понимает смысл запроса. Запрос "can you get medicine for someone pharmacy" - до BERT страницы про pharmacy medication. После - конкретный ответ про pickup rules. Не потому что добавили данные. Потому что изменили модель поиска: от совпадения слов к сходству смыслов. Dense retrieval, hybrid search, RAG - это весь стек этого сдвига.

  • **Google Search BERT (2020)**: 10% запросов обрабатываются через dense retrieval - это 3.5 миллиарда запросов в день через нейронное понимание
  • **Perplexity.ai**: hybrid search (BM25 + BGE embeddings) + cross-encoder rerank + GPT-4 synthesis - полный RAG pipeline в production, 100 млн запросов в месяц
  • **GitHub Copilot**: bi-encoder для code retrieval из репозитория + cross-encoder context selection - dense retrieval в IDE на 1.5 млн разработчиков
  • **Notion AI**: hybrid search по личным заметкам + LLM synthesis - retrieval recall критичен для персонального контекста
  • **Elasticsearch 8.x**: native hybrid search (BM25 + kNN) и RRF fusion из коробки - production standard для enterprise search

Dense retrieval: DPR и bi-encoder

2020 год. Google переключил поиск на BERT - впервые за 20 лет алгоритм понимал смысл запроса, а не только ключевые слова. Запрос "can you get medicine for someone pharmacy" наконец вернул правильный ответ вместо страниц про pharmacy medication. Инструмент - dense retrieval. Не инвертированный индекс с частотами, а вектор смысла в пространстве 768 измерений.

Dense Passage Retrieval (DPR) - Facebook AI Research, 2020. Два BERT-энкодера: один для запросов, другой для документов. Оба обучаются contrastive loss: релевантная пара должна быть ближе, чем нерелевантная. Обученные энкодеры проецируют тексты в одно векторное пространство. Сходство - dot product или cosine. Документы кодируются заранее и индексируются в FAISS. Запрос кодируется на лету за 10 мс. ANN поиск в FAISS - ещё 5 мс. Итого: 15 мс против 1 мс у BM25, но совсем другие запросы обрабатываются корректно.

Contrastive loss для DPR: берётся батч из B пар (запрос, релевантный документ). Все B документов в батче становятся in-batch negatives для каждого запроса. Loss = -log(softmax(dot(q, d+) / [dot(q, d+) + sum(dot(q, d-))])). Hard negatives - документы с высоким BM25 score но нулевой релевантностью - добавляются отдельно и резко улучшают качество. Разница: без hard negatives MRR@20 = 0.31, с hard negatives = 0.42.

Современные bi-encoder модели значительно превзошли оригинальный DPR: BGE-M3 (BAAI, 2024) поддерживает multi-lingual, multi-granularity retrieval и показывает NDCG@10 = 0.585 на BEIR - на 30% выше оригинального DPR. E5-large от Microsoft и GTE-large от Alibaba - сильные альтернативы с открытыми весами.

DPR обрабатывает запрос "can you get medicine for someone pharmacy" лучше BM25. Почему?

Hybrid search: BM25 + dense, reciprocal rank fusion

Конкуренция BM25 против dense retrieval - ложная дихотомия. BM25 непобедим на exact match: имена людей, названия продуктов, коды ошибок, ISBN. Dense retrieval непобедим на семантику: перефразированные запросы, синонимы, многоязычные запросы. Hybrid search берёт оба сигнала и объединяет их. Это не эксперимент - так работает production поиск в Elasticsearch 8.x, Qdrant, Weaviate.

Reciprocal Rank Fusion (RRF) - самый простой и надёжный способ объединить два списка рангов. Для каждого документа d: RRF_score(d) = sum(1 / (k + rank_in_list_i)), где k = 60 (эмпирически). Документ в топ-1 BM25 получает 1/61, документ в топ-100 - 1/160. Если документ попал в оба списка - его RRF суммируется. Красота RRF: никакой нормализации, никакого тюнинга весов. Отлично обобщается на новые домены.

Alpha-weighting как альтернатива RRF: final_score = alpha * dense_score + (1 - alpha) * bm25_score. Требует нормализации обоих score в [0, 1] (min-max или softmax). Alpha = 0.5 - разумная точка старта, оптимум обычно 0.3-0.7 в зависимости от домена. Elasticsearch named_query + knn поддерживает оба подхода нативно с 8.0.

Типичная ошибка hybrid search: объединять BM25 и dense scores напрямую (без RRF или нормализации). BM25 score может быть 7.3, cosine similarity 0.82 - они измеряют разные вещи в разных диапазонах. RRF работает с рангами, а не с абсолютными значениями, и поэтому не требует нормализации.

Запрос: "TypeError: cannot read properties of undefined". Какой метод поиска даст лучший результат в базе документации?

RAG pipeline: от запроса до ответа

Lewis et al., 2020 (Facebook AI): "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks". Идея: не храни все знания в весах языковой модели - храни в индексе, доставай по запросу. Это обнулило необходимость дорогого fine-tuning на каждое обновление данных. Сегодня RAG - архитектурная основа Perplexity, Bing AI, Notion AI, большинства enterprise AI ассистентов.

Production RAG pipeline - это не "embedding + GPT". Это восемь последовательных решений: chunking strategy, embedding model, vector store, retrieval method (dense/hybrid), top-k, reranker, prompt assembly, LLM. Каждое решение влияет на финальное качество. Типичный стек 2025 года: chunking 512 токенов с 64 overlap, BGE-M3 embeddings (1024-dim), Qdrant с HNSW, hybrid search (BM25 + dense, RRF), cross-encoder reranker top-5, GPT-4o для synthesis. End-to-end latency - 400-800 мс.

Chunking - недооценённая часть RAG. Слишком маленькие чанки (< 128 токенов): теряется контекст, ответ фрагментирован. Слишком большие (> 1024 токенов): embedding усредняет слишком много смыслов, precision падает. Оптимум зависит от домена: для FAQ - 256 токенов, для технической документации - 512, для юридических текстов - 1024. Sentence-aware chunking (разрезать по предложениям, не по символам) всегда лучше naive chunking.

Два главных failure mode RAG: 1) Reranker выбрал правильные документы, но LLM галлюцинирует поверх контекста - лечится строгим system prompt и temperature=0. 2) Правильный документ есть в корпусе, но не попал в top-20 retrieval - лечится улучшением recall первой стадии (hybrid search, query expansion). Измерять: retrieval recall@k отдельно от end-to-end answer quality.

RAG = embeddings + LLM; просто берёшь документы, делаешь векторный поиск, отдаёшь в GPT

Production RAG - pipeline из восьми компонентов, каждый влияет на качество. Retrieval recall@k - жёсткий потолок. Chunking, hybrid search, reranking - не опции, а необходимость в реальных задачах.

Naive RAG (embedding + cosine + GPT) работает на демо-данных. На реальных корпусах провал по двум причинам: dense retrieval пропускает exact-match запросы (нужен BM25), embedding усредняет смысл длинных документов (нужны правильные чанки + reranker).

RAG система отвечает неточно. Evaluation показывает: retrieval recall@5 = 0.45, но когда правильный документ есть в контексте - LLM отвечает верно в 95% случаев. Что исправлять в первую очередь?

Ключевые идеи

  • **DPR**: два BERT-энкодера обучаются contrastive loss - документы кодируются offline, запрос online за 10 мс, ANN поиск ещё 5 мс
  • **Hybrid search**: BM25 (точный match) + dense (семантика) объединяются через RRF без нормализации - лучше каждого по отдельности на всех доменах
  • **RAG pipeline**: 8 компонентов, retrieval recall@k - жёсткий потолок. Chunking 512 токенов, BGE-M3, Qdrant HNSW, cross-encoder rerank top-5 - типичный production стек
  • **Bottleneck**: при низком recall первой стадии ни reranker, ни LLM не спасут. Сначала измерять recall@k, потом тюнить остальное

Связанные темы

Semantic search соединяет IR с LLM-системами и современным AI Engineering:

  • Neural Ranking — Bi-encoder и cross-encoder - архитектурная база dense retrieval
  • BM25 и TF-IDF — Первая стадия hybrid search - без BM25 теряется exact-match recall
  • Vector Databases — FAISS, Qdrant, Weaviate - storage и ANN search для dense embeddings
  • RAG Fundamentals — Dense retrieval - ядро RAG pipeline в production AI системах
  • Advanced RAG — Hybrid search, query expansion, multi-hop retrieval поверх базового DPR

Вопросы для размышления

  • Google обновил поиск на BERT в 2020 году, но BM25 по-прежнему является первой стадией в production pipeline крупных поисковых систем. Почему dense retrieval не вытеснил BM25 полностью, и в каких сценариях это могло бы произойти?
  • RAG pipeline состоит из 8 компонентов, каждый с независимыми failure modes. Как построить систему мониторинга, которая точно укажет на узкое место при деградации качества ответов?
  • Chunking strategy влияет как на retrieval recall, так и на LLM synthesis quality. Как найти оптимальный размер чанков для нового домена без перебора всех вариантов?

Связанные уроки

  • ir-05 — Bi-encoder и cross-encoder - архитектурная база dense retrieval
  • ir-03 — BM25 - первая стадия hybrid search pipeline
  • ir-07 — Vector DB - storage layer для dense embeddings
  • aie-12-rag-fundamentals — RAG строится на dense retrieval + cross-encoder rerank
  • aie-13-advanced-rag — Advanced RAG: hybrid search и query expansion поверх DPR
  • aie-09-embeddings — text-embedding-3-small - те же dense векторы что в DPR
  • la-15-svd
Semantic Search

0

1

Войти