AI / LLM
RAG architecture: соберите и оцените retrieval-pipeline
Читать про промахи retrieval — не то же, что поймать один на своём корпусе. Соберите RAG-pipeline от начала до конца, затем гоняйте его на eval-наборе, пока числа — recall, grounding, latency, стоимость — не скажут, что он действительно извлекает прежде, чем отвечать, а не уверенно выдумывает.
Превратите ментальную модель юнита в измеримый инженерный цикл: chunk и проиндексируйте корпус, retrieve широко затем rerank узко, соберите контекст, обходящий lost-in-the-middle, поставьте gate по score для отказа и доказывайте каждое решение числами до/после — а не на ощущениях.
Собрать рабочий RAG-pipeline над реальным корпусом документов и настроить его на отложенном eval-наборе так, чтобы recall retrieval, grounding ответов и p99 latency/cost вышли на цель — с доказуемым сдерживанием уверенной галлюцинации через abstain-gate.
- Таблица до/после на ТОМ ЖЕ eval-наборе: recall@k, precision/MRR финальной стадии, доля grounding/faithfulness, доля отказов на вопросах вне корпуса, p99 latency и стоимость на запрос — измеренные, а не оценочные.
- Хотя бы на одном вопросе вне корпуса корректно произошёл отказ («я не знаю»), потому что score retrieval/rerank упал ниже gate — демонстрируя, что защита от уверенной галлюцинации работает.
- Разбивка latency/cost по стадиям, показывающая, куда уходят время и токены, с обоснованием решения по размерности или k его измеренным эффектом на recall vs p99.
- Краткий разбор: на какую стадию pipeline (chunking, embedding, retrieval, rerank, сборка, gate) нацелено каждое изменение настройки и почему именно эта стадия дала наибольший рычаг для улучшаемой метрики.
- Добавьте гибридный retrieval (BM25/ключевые слова + плотные векторы со score fusion) и измерьте, поднимает ли он recall на запросах с точными терминами и акронимами, где чистые embeddings промахиваются.
- Внедрите отравленный/противоречивый чанк в корпус и покажите, что pipeline либо отказывает, либо выявляет конфликт, либо защищён фильтрацией по контролю доступа/доверию источника — затем количественно оцените влияние на grounding.
- Добавьте задачу свежести/переиндексации и тест, доказывающий, что обновление документа отражается в ответах в пределах целевого лага, закрывая режим устаревшего индекса.
- Проведите ablation по порядку контекста (лучшее-по-краям vs сырой порядок retrieval vs решающий-чанк-в-середине) на длинных контекстах и количественно оцените падение точности lost-in-the-middle на собственном eval-наборе.
Это цикл, который вы будете гонять на каждой реальной RAG-системе: индексируйте с осознанным размером чанка и overlap, retrieve широко затем rerank узко, собирайте контекст с лучшими доказательствами по краям, ставьте gate по score, чтобы промах вёл к отказу, а не к галлюцинации, и проверяйте на отложенном eval-наборе recall, grounding, latency и стоимость до и после каждого изменения. Один раз собрав и оценив это на реальном корпусе, вы доведёте до автоматизма продакшен-версию, где тихий промах retrieval стоит доверия.