Какую задачу на самом деле решает поиск с генерацией

Модель знает язык, но не знает вашей папки с договорами

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

Что именно вы получаете

Свежесть без переобучения. Документ отредактировали — переиндексировали фрагмент, и следующий ответ уже другой. Дистанция между правкой в источнике и изменением ответа измеряется минутами, а не циклами обучения.
Проверяемость. Ответ можно сопроводить ссылкой на фрагмент. Пользователь открывает документ и убеждается сам, а вы при жалобе видите, что именно система прочитала.
Разграничение доступа. Фильтр по правам применяется к поиску, поэтому один и тот же ассистент отвечает разным людям по разному набору документов. В дообученной модели знания невозможно разграничить: они размазаны по весам.
Масштаб коллекции. Индекс на десятки миллионов фрагментов — обычная инженерная задача. Контекст модели на десятки миллионов токенов — нет.

Где проходит граница ответственности

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

вопрос
  │
  ├─► поиск ──► 5 фрагментов ──┐        отказ здесь: нужного текста нет
  │                            │
  └────────────────────────────┴─► промпт ──► модель ──► ответ
                                                  отказ здесь: текст был, ответ неверный

Почему поиск — узкое место

Если нужного фрагмента нет в контексте, дальше уже ничего не спасает. Более сильная модель не восстановит отсутствующий факт, строгий промпт не превратит незнание в знание, температура ноль не поможет. В разборах провалившихся систем доля ошибок, чья первопричина лежит до генерации, обычно составляет от двух третей до четырёх пятых. Отсюда практический порядок работ: сначала измеряют, попадает ли эталонный фрагмент в выдачу, и только потом обсуждают формулировку ответа.

Инсайт. Схема нужна не потому, что модель мало знает, а потому, что нужен адрес источника. Даже если бы модель знала все ваши документы наизусть, вам всё равно требовалась бы ссылка, по которой пользователь проверит ответ, а вы расследуете жалобу.

Частая ошибка. Считать, что подключение поиска само по себе убирает выдумывание. Оно меняет его характер: модель перестаёт выдумывать факты из воздуха и начинает достраивать недостающие детали вокруг найденного фрагмента — правдоподобно и незаметно.

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

Шпаргалка

Схема меняет вход модели, а не саму модель.
Поиск и генерация — два механизма с разными отказами и разными метриками.
Нет фрагмента в контексте — никакой промпт не поможет.
Ссылка на источник нужна и пользователю для проверки, и вам для расследования.

1. Почему разграничение прав доступа проще реализовать через поиск, чем через дообучение модели?

2. Что означает утверждение, что поиск — узкое место системы?

3. Как меняется характер выдумывания после подключения поиска?

🔒 Ответьте на вопрос верно, чтобы перейти к следующему уроку.