AgeCode: ML System Design

Suggest заранее предлагает короткие запросы или статьи, а free-text search отвечает на конкретный intent пользователя. У них разные triggers, candidates, metrics и latency budget.

Suggest работает до того, как пользователь сформулировал полный вопрос. Он может показывать популярные темы, FAQ, короткие вопросы из заголовков и персонализированные подсказки по контексту страницы. Такие candidates часто считаются заранее и обновляются batch-процессом.

Свободный поиск стартует после ввода текста. Система нормализует запрос, ищет статьи или чанки, ранжирует кандидатов и может собрать ответ поверх найденного контекста. Здесь важны recall релевантной статьи, качество порядка, понятная выдача и latency ответа.

Разделение помогает не смешивать метрики. Для suggest команда смотрит usage, acceptance rate и downstream success. Для free-text search команда смотрит relevance labels, click/success, reformulation rate, time-to-answer, fallback и качество ответа, если включен RAG.

BM25 дешевый, интерпретируемый и сильный baseline для доменных текстов. Он быстро дает retrieval quality baseline, от которого можно сравнивать embeddings, reranker и RAG.

Для поиска по статьям сначала нужен простой измеримый baseline. BM25/TF-IDF быстро внедряется, хорошо работает по точным терминам, артиклам, названиям продуктов и доменной лексике, а ошибки легко анализировать.

Embeddings и RAG добавляют semantic matching, но стоят дороже и сложнее: нужно выбрать embedding model, chunking, vector index, reranking, оценку hallucination и latency/cost. Без baseline непонятно, стало ли лучше.

Практичный план: BM25 top-k как candidate generator, затем dense retrieval или hybrid search, затем reranker/cross-encoder, затем generation only if needed. Для suggest можно использовать top articles/queries, для free text — top answer/article plus related articles.

Offline нужны эталонные запросы, разметка релевантности, Recall@K, MRR и nDCG. Online смотрим CTR, повторные формулировки, время до ответа, solved/not solved, эскалации, fallback, обратную связь и latency.

Offline нужен датасет запросов и релевантных статей. Если есть graded relevance, используем nDCG@k. Если у запроса есть одна целевая статья, подходят MRR/hit rate/recall@k. Для candidate generator особенно важен recall@k: нужная статья должна попасть в top-k до reranker.

Online метрики зависят от продукта: клик по статье, нашел ли пользователь ответ, доля повторных запросов, time-to-answer, scroll depth, переход в поддержку, thumbs up/down, fallback rate, latency p95/p99.

Для RAG отдельно оценивают retrieval и generation: принес ли retriever правильный контекст, grounded ли ответ, нет ли hallucination, корректны ли ссылки. Без разделения сложно понять, где именно деградация.

Сигналы успеха: клик по результату, время до ответа, reformulation rate, возврат к выдаче, scroll/read depth, thumbs up/down, переход в поддержку и explicit solved feedback.

Online-метрика должна отражать действие пользователя, а не только клик. Клик по первой статье может быть хорошим сигналом, но пользователь мог сразу вернуться и переформулировать запрос. Поэтому полезны цепочки: query -> result click -> чтение -> отсутствие повторного запроса -> explicit feedback.

Для статей хорошо работают time-to-answer, число открытых статей до решения, reformulation rate, zero-result rate, bounce back to search, переход в поддержку, thumbs up/down, save/share и доля запросов, где пользователь отметил, что ответ найден.

Эти сигналы шумные, поэтому их связывают с offline-разметкой. Команда держит golden set запросов для релизов и одновременно смотрит online guardrails: latency, errors, fallback, долю пустой выдачи и жалобы на нерелевантные ответы.

Candidate stage объединяет BM25, dense retrieval и metadata filters, затем reranker упорядочивает top-K по query-document relevance. RAG включается только после выбора контекста.

Базовая схема делится на stages. Первый stage должен найти широкий набор кандидатов: BM25 хорошо ловит точные термины, dense retrieval ловит семантические совпадения, metadata filters ограничивают язык, продукт, дату, тип статьи и доступность. Результаты объединяются, дедуплицируются и режутся до top-K.

Второй stage - reranker. Cross-encoder, learning-to-rank модель или компактный LLM-reranker смотрит на query и текст статьи/чанка вместе. Он переставляет кандидатов так, чтобы наверху были материалы, которые реально отвечают на вопрос пользователя.

RAG не заменяет этот pipeline. Генератор подключается после retrieval/reranking, когда система уже выбрала контекст. Если пользователь просто хочет статью, генерация может быть лишней; если нужен короткий ответ с ссылками, RAG собирает ответ и показывает источники.

MVP берет заголовки, FAQ, headings и популярные queries. LLM может предложить short questions, но система проверяет grounding, дедупликацию, токсичность и кликабельность.

Suggest-вопрос должен вести к конкретной статье или группе статей. Для MVP можно использовать заголовок, подзаголовки, FAQ-блоки, внутренние anchors и реальные query logs. Это дает простые подсказки, которые легко объяснить редакторам.

LLM можно подключить как offline generator: модель читает статью и предлагает несколько коротких вопросов. Затем pipeline проверяет, что каждый вопрос поддерживается текстом статьи, не дублирует уже существующие подсказки, не обещает того, чего в статье нет, и укладывается в язык продукта.

После публикации suggest оценивается отдельно от поиска: acceptance rate, downstream click, solved feedback, жалобы и доля подсказок, которые ведут в пустые или нерелевантные результаты. Редакторский review полезен для медицинских, юридических и финансовых тем.

Baseline: precompute related articles по текстовой/embedding близости. Более сильная схема: query-aware related articles через candidates + reranker, обученный на кликах, переходах и разметке.

Есть два режима. Precomputed related articles дешевы и стабильны: для каждой статьи заранее считаем похожие статьи по BM25/embeddings/co-clicks. Это хорошо для блока "похожие материалы" без учета конкретного вопроса.

Query-aware related articles лучше, если пользователь пришел с конкретным вопросом. Тогда related candidates должны учитывать и текущий query, и найденную top article, и контекст пользователя. Candidate generator может быть hybrid search, а final reranker — cross-encoder или LLM reranker, если latency/cost позволяют.

Для обучения reranker полезны click logs, последовательные переходы между статьями, explicit feedback, разметка релевантности и "нашел ответ". Важно не забыть privacy, latency и fallback на precomputed related, если online reranker недоступен.

Полезны clicks, dwell time, reformulations, final solved article, skips, support escalation и explicit feedback. Их нужно дебайсить от позиции, интерфейса и популярности статьи.

Online-сигналы дают дешевые labels, но они смещены. Клик по верхнему результату зависит от позиции. Длинное чтение может означать пользу или сложность текста. Повторный запрос может означать, что статья не помогла, но иногда пользователь просто уточнил тему.

Для reranker полезны пары и списки: пользователь выбрал статью A вместо B, открыл несколько результатов и остановился на одном, поставил positive feedback, не ушел в поддержку, не переформулировал запрос. Negative signals: быстрый bounce, skip результата, повторный query с тем же intent, жалоба, escalation.

Перед обучением эти события агрегируются с учетом позиции, query frequency, типа устройства и freshness статьи. Ручная разметка остается нужна как clean validation set, чтобы implicit feedback не закрепил bias старой выдачи.

LLM оправдан, когда нужно синтезировать ответ, сравнить несколько источников или понять сложный intent. Для простого поиска статей cross-encoder дешевле и стабильнее.

LLM поверх поиска нужен не всегда. Если пользователь ищет конкретную статью, lexical+dense retrieval и reranker обычно быстрее, дешевле и предсказуемее. LLM добавляет latency, cost, privacy risk и возможность unsupported statements.

LLM полезен, когда пользователь задает сложный вопрос, а ответ лежит в нескольких статьях. Тогда pipeline берет top chunks после reranker, собирает context, просит модель ответить с ссылками на источники и возвращает fallback, если контекст не поддерживает ответ.

Если LLM используется как final reranker, его стоит ограничивать top-N кандидатами и проверять стабильность: одинаковые запросы не должны получать хаотичный порядок. Для enterprise-контента также нужны private deployment, audit logs и правила по данным, которые нельзя отправлять внешнему провайдеру.