Главная мысль урока: качество ассистента закладывается до всякого ИИ — на этапе подготовки базы. По сходящимся оценкам консалтингов, ~70% корпоративных RAG-проектов не доживают до продакшна, и чаще всего убийца прячется здесь: кривой парсинг PDF, расплющенные таблицы и бездумная нарезка. Мусор на входе = уверенная чушь на выходе.
Враг №1: мусор на входе
Помните конвейер индексации из урока 10? Его первый этап — парсинг: извлечение текста из ваших PDF, презентаций, таблиц. Звучит скучно — а на деле это половина проекта.
Классический провал выглядит так: PDF-парсер «расплющивает» таблицу с тарифами в кашу из символов. Поиск таблицу больше не находит, зато находит соседний абзац «про похожее» — и модель уверенно отвечает по нему. Ответ звучит гладко и совершенно неверен. (разбор провалов RAG, 2026)
Лекарство — парсеры, понимающие структуру документа (structure-aware: открытые docling, unstructured и аналоги). Таблицы они сохраняют как таблицы — со связями строк и столбцов, — а не как поток слов.
И второй пункт гигиены: чистка базы до индексации. Устаревшие версии документов, черновики, дубли — всё это будет находиться поиском наравне с актуальным. База знаний — как склад: бардак не исчезает от того, что наняли быстрого кладовщика.
Размер чанка: есть проверенные цифры
Из урока 4 вы знаете: документы режутся на чанки — кусочки по одной мысли. Теперь конкретика 2026 года, что заказывать:
Фактологические вопросы («какой тариф у курса X?») — чанки 256–512 токенов (примерно треть-полстраницы).
Аналитические вопросы («сравни подходы из модуля 3») — крупнее, 1024+.
Не знаете, что будет — старт с 400–512, и резать по структуре документа: по заголовкам и разделам, а не по счётчику символов.
Важный результат исследования Chroma (единственное систематическое сравнение стратегий нарезки): простой механический разрезатель на ~400 токенов находит 89,5% нужного — почти столько же, сколько дорогие «умные» методы. А вот огромные чанки (800+) роняют точность в разы. (Chroma Research, Evaluating Chunking Strategies)
Вывод для заказчика: дешёвая разумная нарезка — сильная база. Дорогой «семантический чанкинг, потому что модно» — повод спросить, чем он лучше на ваших документах.
Враг №2: чанк, вырванный из контекста
Даже идеально нарезанный чанк страдает амнезией. Кусочек «выручка выросла на 3%» — чья выручка? за какой период? Внутри чанка ответа нет — он остался в начале документа, в другом чанке. Поиск такой кусочек либо не найдёт, либо найдёт не к месту.
Перед индексацией LLM дописывает к каждому чанку 50–100 токенов контекста: «Этот фрагмент — из условий тарифа „Профи“ курса X, раздел о возвратах…». Чанк перестаёт быть сиротой.
Цифры Anthropic: −49% неудачных поисков, а вместе с реранкером — −67%. Разовая стоимость обогащения — около $1 за миллион токенов документов. (Anthropic, Contextual Retrieval)
Лекарство 2 · Late chunking (поздняя нарезка)
Хитрость в порядке действий: сначала весь документ проходит через эмбеддинг-модель, и только потом результат режется на чанки. Каждый чанк «помнит» документ целиком.
Дешевле первого способа — не нужны LLM-вызовы; продаётся и как готовый сервис. (Jina AI, Late Chunking)
Запоминается парой: contextual retrieval — дороже и точнее, late chunking — дешевле и проще. Для базы с важными деталями (тарифы, условия) просите первое.
🔬 Под капотом: как чанк «вспоминает» документ при поздней нарезке
Пример из первоисточника Jina. В документе про Берлин есть фраза «Its population exceeds 3.85 million» — «его население превышает 3,85 млн». Отдельным чанком она бесполезна: слово «его» ни на что не указывает.
При поздней нарезке весь документ сначала проходит через эмбеддинг-модель, и внимание (то самое, из урока 2) успевает связать «его» со словом «Берлин» из соседнего абзаца. Когда после этого считаются точки чанков, точка фразы про население уже «впитала» Берлин — и найдётся по запросу «население Берлина».
Ограничение: нужна эмбеддинг-модель с длинным контекстом, чтобы документ влез целиком.
Правило финального теста
Какую бы стратегию ни предложил разработчик, есть честный способ выбрать: протестировать 2–3 варианта нарезки на 50–100 ваших документах и 20–30 реальных вопросах и сравнить цифрами, какая находит лучше. Это день работы, который экономит месяцы переделок. Как именно мерить «находит лучше» — следующий урок.
Зачем это вам как заказчику
«Как вы парсите PDF и что происходит с таблицами?» Ответ «обычным экстрактором текста» при базе с таблицами — красный флаг.
«Какой размер чанка и почему? Резали по структуре или по счётчику?»
«Как чанки сохраняют контекст документа?» Ждите слов «contextual retrieval» или «late chunking».
Чистка базы — ваша работа, не разработчика: только вы знаете, какие документы устарели.
Проверьте себя
Повторение урока 10. Нарезка документов на чанки — это какой конвейер и когда оплачивается?
Верно! Нарезка — часть подготовки библиотеки (индексации). На каждый вопрос работает другой конвейер: поиск → реранкер → генерация.
Вспомните два конвейера из урока 10: нарезка происходит при подготовке базы (индексация, платится один раз), а не при каждом вопросе.
Ассистент уверенно называет неверные тарифы, хотя таблица тарифов есть в базе (PDF). Самая вероятная причина?
Именно! Классика провалов RAG: таблица умерла на этапе парсинга, модель отвечает по «похожему» тексту. Лечится structure-aware парсером, а не сменой модели.
Смена модели не воскресит таблицу, убитую парсером. Это типовой провал этапа подготовки: проверяйте, как парсятся таблицы.
Чем contextual retrieval отличается от late chunking?
Точно! Оба лечат «амнезию чанка», но по-разному: дописать контекст словами (LLM-вызовы, ~$1/млн токенов) или дать чанку «впитать» документ на этапе эмбеддинга.
Это два разных лекарства от одной болезни — амнезии чанка. Contextual retrieval = LLM дописывает контекст (дороже/точнее), late chunking = эмбеддинг всего документа до нарезки (дешевле/проще).
Разработчик предлагает: «нарежем по 1000 символов с перекрытием 200, как все делают». Ваша реакция?
Верно! «1000 символов + overlap» — наследие первых туториалов. Стандарт 2026 — нарезка по структуре, 256–512 токенов для фактов, и выбор по тесту на ваших данных, а не по привычке.
«Как все делают» — это 2023 год. Но и самое дорогое не нужно: дешёвая разумная нарезка очень сильна. Правильный ход — тест 2–3 стратегий на ваших документах с цифрами.
Практика: посмотрите на свои чанки
🛠 Задание на 10 минут
Возьмите один реальный документ из будущей базы (методичку, регламент с таблицей).
Откройте Claude Code и попросите: «Разрежь этот документ на чанки по ~400 токенов по структуре (заголовки, разделы). Покажи первые 5 чанков и отметь места, где мысль оказалась разрезана пополам или чанк непонятен без контекста документа».
Посмотрите на «чанки-сироты» своими глазами — теперь вы знаете, зачем нужно контекстное обогащение.
Если в документе есть таблица — спросите: «Как эта таблица переживёт извлечение текста из PDF? Что с ней будет в RAG-индексе?»
Что дальше
База подготовлена и нарезана. Следующий урок — поиск: гибрид и реранкер в деталях, и главный навык заказчика — как измерить качество поиска цифрами до запуска (золотой набор и recall).