---
title: Понимание запроса и суммаризация
description: "Что происходит с запросом до поиска: намерение, исправление, переписывание и разложение на подвопросы; и обратная задача — сжать длинный контекст в ответ с цитатами."
---

## Две стороны одной функции

Понимание запроса и суммаризация кажутся разными задачами, но это два конца одного процесса:

- **На входе** короткая и неточная формулировка, которую нужно превратить в хороший поисковый запрос.
- **На выходе** длинный набор найденного, который нужно сжать в ответ, не потеряв смысл и не потеряв источники.

Модель полезна на обоих концах, но по разным причинам: на входе — потому что понимает разговорный язык, на выходе — потому что умеет работать с большим объёмом текста.

## Понимание запроса

| Шаг | Что делает | Пример |
|---|---|---|
| **Нормализация** | Регистр, опечатки, раскладка, лишние символы | «rjgjvbxrf» → «компьютер» |
| **Определение намерения** | Купить, узнать, сравнить, найти конкретное | «цена» → транзакционный |
| **Извлечение ограничений** | Числа, даты, бренды, категории | «до 8000», «на выходных», «Nike» |
| **Переписывание** | Расширение синонимами, профессиональные термины | «не греет» → «низкое энергопотребление» |
| **Декомпозиция** | Составной вопрос на подвопросы | «сравни тарифы для ИП и ООО» → два запроса |
| **Контекст диалога** | Подстановка темы из предыдущих реплик | «а сколько это стоит?» → подставить предмет |

Порядок важен: дешевле сначала нормализовать и извлечь ограничения кодом, а модель звать только там, где без неё нельзя. Нормализация опечаток через LLM — дорогой способ решить задачу, с которой справляется словарь и расстояние Левенштейна.

## Fan-out: один вопрос — много запросов

Ответные движки и продвинутые поисковики не выполняют один запрос. Они разворачивают вопрос в набор подвопросов («fan-out»), ищут по каждому, затем объединяют и синтезируют ответ. Это объясняет, почему в ответе могут оказаться источники, которые не отвечают на исходную формулировку буквально.

Для внутреннего поиска тот же приём полезен, когда вопрос составной: «какие документы нужны для возврата товара, купленного по карте» — это и регламент возврата, и способы оплаты, и сроки.

Цена — несколько вызовов модели и поиска на один запрос. Оправдано там, где ответ важнее задержки.

## Суммаризация

Задача выглядит простой («сократи»), но у неё есть жёсткие требования, если результат идёт пользователю:

- **Не терять цифры и условия.** «До 30 дней» и «до 30 рабочих дней» — разные утверждения.
- **Не менять модальность.** «Может быть возвращён» не равно «будет возвращён».
- **Сохранять источник.** Каждое утверждение должно быть проверяемо; в ответных движках цитата — часть формата.
- **Признавать противоречия.** Если в двух документах разные сроки, честнее показать расхождение, чем выбрать один молча.
- **Укладываться в формат.** Сниппет на 300 знаков и обзор на 3000 слов — разные задачи с разными правилами.

## Длинный контекст: что важно знать

- **«Помещается» не значит «прочитано».** Модель может потерять факт из середины документа; важное лучше ставить в начало и в конец.
- **Стоимость растёт линейно.** Суммаризация 200 страниц на каждый запрос — дорогое удовольствие; кэширование и предварительные выжимки окупаются.
- **Иерархия лучше одного вызова.** Сначала выжимки по разделам, потом общий вывод — точнее и дешевле, чем «прочитай всё».
- **Карта документа.** Для больших корпусов полезно хранить оглавление и краткие описания разделов — это дешевле, чем full-text.

## Где ломается

- **Переписывание меняет смысл.** «Дешёвый» превратилось в «бюджетный сегмент», и поиск ушёл в другую категорию. Переписанный запрос стоит логировать и проверять.
- **Слишком много подвопросов.** Ответ становится общим, потому что каждый подвопрос размыл фокус.
- **Галлюцинация в суммаризации.** Модель добавляет «очевидное» условие, которого в тексте не было.
- **Потеря редкого случая.** Сжатие отбрасывает исключения — а именно они чаще всего и важны.
- **Сниппет без источника.** Пользователь не может проверить утверждение и либо верит зря, либо не верит вовсе.

## Что проверять

- Логируются ли **исходный и переписанный** запросы.
- Есть ли **набор эталонных вопросов** с правильными ответами и цитатами.
- Проверяется ли суммаризация на **числах и условиях** отдельно от общего качества.
- Обрабатываются ли **противоречия между источниками** явно.
- Укладывается ли задержка в ожидания интерфейса: понимание запроса на каждый ввод символа недопустимо дорого.

## Связанные материалы

- [Поиск по сайту](https://wpcraft.ru/kb/ai/search/site-search.md) — куда уходит переписанный запрос.
- [Ответные движки](https://wpcraft.ru/kb/ai/search/answer-engines.md) — где fan-out и цитаты видны пользователю.
- [Чанкинг](https://wpcraft.ru/kb/ai/rag/chunking.md) — как устроен контекст, который потом сжимается.
- [Оценка качества](https://wpcraft.ru/kb/ai/agents/evaluation.md) — как измерять суммаризацию.

## Материалы и источники

- [Google: AI features in Search](https://developers.google.com/search/docs/appearance/ai-features) — как поиск формирует ответы и цитаты
- [Anthropic: Contextual Retrieval](https://www.anthropic.com/research/contextual-retrieval) — работа с фрагментами и их контекстом
- [Lost in the Middle (Liu et al., 2023)](https://arxiv.org/abs/2307.03172) — как модели теряют информацию в середине длинного контекста
- [RAGAS](https://docs.ragas.io/) — метрики обоснованности и полноты ответа