Как Open WebUI обращается к документам: RAG, полный контекст и инструменты модели

Вы готовите точное сообщение участникам встречи по памятке буфета. Как помощник получит нужный текст и кто решит обратиться к источнику ещё раз? Open WebUI может заранее подобрать фрагменты либо подготовить весь сохранённый текст файла. Если у модели есть разрешённые совместимые инструменты, она также может сама выбрать поиск или чтение и использовать полученный результат перед ответом.

Предварительный отбор будем называть классическим RAG, подготовку полного сохранённого текста отдельного файла — Full Context, а выбор обращений моделью — agentic retrieval, или агентным поиском и чтением. Эти возможности связаны: заранее подготовленный контекст чата может сочетаться с инструментами. Чтобы понять доступный путь, нужно различить место подключения источника, охват подготовленного текста и того, кто выбирает обращение.

Продолжим вымышленную ситуацию из урока о разбиении документов, поиске и реранжировании. Там мы разбирали подготовку и отбор частей. Теперь выясним, как текст становится доступен модели и что меняет возможность запросить его самостоятельно. Обработка памятки и сравнение ответов в Open WebUI при подготовке этого урока не выполнялись.

Что должно сохраниться в ответе по памятке

Источник остаётся прежним:

Памятка буфета на встрече. Версия 1.

Напиток | Объём одной порции, л | Цена одной порции, руб.
Чай | 0,25 | 35,50
Вода | 0,50 | 20,00

Чай выдают только в своей кружке.
Воду выдают в бутылке.

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

Это критерии будущей проверки, а не полученные ответы Open WebUI. В ответе о воде не должно появиться ни требования принести свою бутылку, ни разрешения повторного наполнения.

Отсутствие времени установлено чтением всей памятки. Поиск по вопросу о часах может вернуть текст о буфете; пустой результат не обязателен. Не требуется и буквальное предложение «время не указано» внутри возвращённого текста. В произвольном документе отсутствие находки по одному запросу ещё не устанавливает отсутствие сведений во всём источнике.

Набор вопросов тоже имеет границы. Он отдельно не проверяет цену и объём чая, название и версию памятки, весь индекс или другие документы. Даже точные ответы на все четыре вопроса не будут проверкой всей базы знаний.

Теперь отделим четыре объекта:

Оригинал → сохранённый извлечённый текст → реально выбранный или возвращённый текст → ответ.

Оригинал — документ, который читает человек. При обычной обработке файла загрузчик извлекает из него текст, а Open WebUI сохраняет этот текст отдельно. Подготовка векторного индекса — следующий, отдельный этап. Для ответа затем могут быть выбраны части сохранённого текста, подготовлен весь текст или возвращён результат инструментального чтения. Ответ модели — ещё одно изложение, которое нужно отличать от этих входных сведений.

Если условие или заголовок потерялись при извлечении, последующий поиск по сохранённому тексту их не восстановит. Открытый PDF показывает оригинал; доступный Indexed text позволяет сверить сохранённое представление. Сам просмотр PDF не подтверждает качество извлечения. Подробный порядок такой сверки остаётся в уроке о PDF, сканах, таблицах и OCR.

Техническое описание ниже относится к Open WebUI v0.12.4 и отдельно зафиксированной документации на 26 октября 2026 года. Оно основано на коде и документации; версия, экраны и действующая конфигурация вашей установки здесь не проверены.

Если захотите наблюдать эти пути на своём документе, используйте разрешённый несекретный источник. Место обработки зависит от сервисов извлечения текста и провайдеров embedding-модели и модели ответа — это отдельно оговорено в документации Knowledge. Локально открытый интерфейс сам по себе не означает, что текст обрабатывается только на вашем компьютере.

Когда приложение выбирает фрагменты, а когда готовит полный текст

Возьмём вопрос о том, что принести для чая. В применимом автоматическом пути приложение заранее получает текст, по которому можно составить ответ:

1. Open WebUI формирует поисковое обращение к подключённому источнику.
2. Поиск возвращает подходящие тексты.
3. Приложение добавляет полученные сведения в сообщения модели, после чего та формулирует ответ.

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

Для нашей задачи полезен текст, из которого читается обязательность кружки. Само слово «чай» ещё не даёт этой связи. При этом классический путь не означает обязательно один векторный поиск по дословному вопросу: применимые способы отбора могут различаться. Настройку частей, Top K и реранкера мы уже разобрали в предыдущем уроке.

Теперь изменим предмет рассмотрения: вместо отбора частей приложению можно поручить подготовить полный сохранённый текст обычного файла. Этому соответствует Using Entire Document в окне прикреплённого элемента. В применимой ветви Open WebUI берёт сохранённое извлечённое содержимое файла. Если памятка сохранилась верно, строка воды и заголовки находятся в составе этого текста.

Такой Full Context можно рассматривать сразу, когда короткий источник существенно нужен для задачи целиком и позволяют условия передачи и контекста. Сначала получать плохой ответ с фрагментами не требуется. У нашей памятки есть и другая возможность: она настолько короткая, что может целиком попасть уже в первый результат обычного поиска. Тогда охват текста может не различаться. Искусственно отделять заголовки от строки воды ради демонстрации не нужно.

Здесь полезно различить два похожих названия. File Context — возможность в настройках модели, которая допускает автоматическую обработку контекста вложений чата. Full Context в рассматриваемом случае определяет, что готовится для отдельного файла: весь сохранённый текст вместо выбранных фрагментов. Автоматический обработчик проверяет именно File Context. Это условие нужно и для автоматической подачи полного текста чат-вложения. Режим вызова инструментов Native сам по себе обработчик не выключает.

Охват подготовленного текста и доступность инструментов — разные решения. Для одного элемента в применимой автоматической ветви готовятся focused-фрагменты либо full-текст. Выбор полного текста сам по себе не включает и не выключает уже доступные инструменты модели. Например, подготовленный контекст вложения чата может сочетаться с разрешёнными инструментами Knowledge. У инструментов обычных файлов чата есть отдельные условия, которые разберём по месту подключения.

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

Подготовить весь текст ещё не значит обеспечить его полное прохождение и правильное использование. У модели конечное контекстное окно. Документ делит его с перепиской, инструкциями, определениями инструментов, их результатами и местом для ответа. Документация предупреждает, что большой документ может вытеснять историю разговора; описания инструментов тоже занимают контекст. Из этого следует практическая граница: допустимый объём нужно связывать с конкретной моделью, провайдером и конфигурацией. Универсального безопасного числа страниц или токенов для всех установок нет.

Кроме переключателя отдельного файла существуют глобальные настройки с похожим смыслом. Они работают иначе; ниже отделим их друг от друга. Пока главное различие установлено: приложение заранее готовит определённый объём текста. Возможность модели самой выбрать следующее обращение нужно рассмотреть отдельно.

Как модель выбирает поиск, чтение и продолжение

Для этого хода предположим, что та же памятка уже доступна через разрешённую Knowledge, подключённую к модели или папке. Речь о доступном наборе источников для этой модели или папки; создавать новую базу ради объяснения не нужно. Такая предпосылка отличается от обычного файла, прикреплённого внутри чата. Инструментальные пути этих подключений не следует смешивать.

В обычном разговоре через интерфейс для рассматриваемых встроенных инструментов нужны действующий Native, включённые у модели Builtin Tools, категория Knowledge, права на источник и совместимость модели и провайдера с вызовами инструментов. В коде обычная ветвь проверяет режим вызова и возможность Builtin Tools, а набор Knowledge регулируется отдельно. Предположение о доступности этих условий позволяет объяснить механизм, но не подтверждает их наличие у читателя.

На вопросе о цене и объёме воды роли распределяются так:

1. Человек задаёт вопрос по разрешённому источнику.
2. Модель выбирает действие из доступных: например, смысловой поиск или чтение уже известного файла.
3. Код инструмента исполняет обращение и возвращает результат модели.
4. Модель использует результат: может сформулировать ответ либо выбрать ещё одно разрешённое обращение.

Такой выбор поиска и чтения называют agentic retrieval. Отличие проявляется в управлении обращением: модель может учитывать полученный результат при выборе следующего действия. Код инструмента выполняет конкретный запрос; решение продолжить принимает модель в пределах доступных возможностей.

Сначала рассмотрим достаточный результат. Если после первого обращения строка воды читается вместе с заголовками и единицами, модель может ответить сразу. Один поиск или прямое чтение могут завершить работу с источником. Не нужен обязательный порядок «перечислить файлы → найти фрагменты → прочитать документ».

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

Поиск и чтение решают разные задачи. В обычном наборе Knowledge предусмотрены несколько видов обращений:

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

Этот набор формируется с учётом прикреплённых источников и включённых категорий. Прикреплённая Knowledge задаёт область обращения вместе с правами доступа. Если прикреплённой Knowledge нет, доступны предусмотренные инструменты обнаружения доступных пользователю баз. Это не обещание доступа ко всем документам организации или исчерпывающего поиска по ним. Прикрепление у модели или папки — условие нашей сцены; возможный случай Knowledge из чата рассмотрим отдельно.

Смысловой инструмент query_knowledge_files использует тот же механизм retrieval с embedding-функцией. У него собственный аргумент count, который передаётся во внутренний поиск как предел количества результатов. Поэтому административный Top K не является прямым управлением этим вызовом. Применимые настройки внутреннего поиска сохраняют свою роль. А прямое чтение сохранённого текста — другое действие: из устройства смыслового поиска не следует, что любому чтению нужны embeddings.

Результат инструмента тоже имеет границы. Например, view_file может возвращать сохранённый текст частями. В обычной ветви объём и смещение задаются в символах; адресация по строкам имеет собственный порядок продолжения. Это различие видно в реализации чтения. Символы не равны токенам модели. Один вызов не удостоверяет прочтение всего файла, но частичного результата может быть достаточно для конкретного вопроса.

Продолжение зависит и от условий выполнения. Оно возможно, пока модель возвращает вызовы и не исчерпан предел итераций, если он установлен; ошибка или достижение предела могут остановить цикл. Итерация может включать несколько вызовов, поэтому предел итераций нельзя считать ни количеством отдельных инструментальных обращений, ни денежным бюджетом.

Доступность инструмента не гарантирует удачного выбора модели, полного чтения или точного ответа. Реализация содержит проверки доступа; их описание по коду не является проверкой безопасности всей установки. Для практического выбора теперь нужно понять, где подключён ваш источник и какие из этих возможностей к нему относятся.

Как определить доступный способ обращения к источнику

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

Источник прикреплён внутри чата. Если разрешено и доступно в вашей версии, существующий источник можно выбрать через # или прикрепление; новая загрузка для этого не обязательна. Откройте прикреплённый элемент и посмотрите выбранный способ подготовки текста. В окне элемента Using Entire Document устанавливает локальный признак полного текста, а Using Focused Retrieval снимает его.

Для автоматической подачи контекста вложений чата нужен включённый File Context. Это относится и к обычным файлам, и к применимым коллекциям внутри чата. Надпись Focused или Full показывает выбор элемента, но сама по себе не доказывает весь действующий путь: на обработку влияют также глобальные настройки и возможности модели.

Knowledge подключена к модели или папке. Здесь существенен Function Calling, то есть режим вызова инструментов. В v0.12.4 native-ветвь действует, когда итоговое значение function_calling не равно legacy. Если после применения наследуемых параметров значение осталось не задано, действует Native. Но видимая надпись Default ещё не раскрывает, какое значение унаследовано. Старое название Default для нынешнего Legacy относится к прежней терминологии, что разъясняется в документации режимов вызова.

В Native модель обращается к Knowledge модели или папки через подходящие инструменты. Флаг полного текста у такой Knowledge сам по себе не включает предварительную автоматическую подачу. Её постановка в автоматическую обработку находится в legacy-ветви и требует применимого File Context.

Отсюда следует конкретное условие недоступности: если источник подключён только как Knowledge модели или папки, действует Native и Builtin Tools выключены, он может остаться без обсуждаемых автоматического и встроенного инструментального путей. Это объяснение сочетания настроек, а не диагноз конкретного неверного ответа. Legacy присутствует в коде для совместимости, но закреплённая документация называет его неподдерживаемым; переключение в него не стоит использовать как обычное исправление.

Коллекция или заметка добавлена в чат, а File Context выключен. Область прикреплённой Knowledge не ограничивается только моделью и папкой. В этом случае элементы коллекций и заметок чата — collection и note — также включаются в набор прикреплённых источников Knowledge. Это возможность при соответствующих условиях встроенных инструментов и доступа. Обычный файл, прикреплённый внутри чата, относится к отдельной ветви Chat Files.

Нужно обратиться инструментом к обычному файлу чата. Для Chat Files действуют общие условия Native, включённых Builtin Tools, совместимости и прав. Дополнительно нужны включённая категория Files, разрешённая у модели возможность загрузки файлов file_upload, наличие файла в чате и пользовательское разрешение chat.file_upload. File Context должен быть выключен — это отдельное условие формирования набора Chat Files.

Категория Knowledge регулируется отдельно от Files. Поэтому возможность сочетать заранее подготовленный контекст чата с Knowledge tools не означает, что при включённом File Context доступны и Chat Files tools. Перечисленные условия относятся к обычной сессии чата в интерфейсе; у внутренних разговоров заметок и обращений через API могут быть другие условия.

Узнавать настройки модели имеет смысл при соответствующих правах. В описанных источниками интерфейсах это Workspace → Models → Edit, разделы Knowledge и Capabilities. Function Calling может задаваться для чата в Chat Controls → Advanced Params, для модели и глобально в Settings → Admin → Models → Model Defaults. Документация описывает эти уровни отдельно. Они помогают понять наследование; менять их все или получать административный доступ для сравнения не требуется. Эти маршруты взяты из кода и документации, а не из проверки экрана вашей установки.

Похожие настройки полного контекста делают разную работу. Если вам встречаются их названия, различайте:

• Using Entire Document у отдельного обычного файла — подготовку его сохранённого извлечённого текста в применимой ветви.
• RAG_FULL_CONTEXT — получение всех элементов применимых существующих индексированных коллекций. Это не обязательно одна строка первоначально сохранённого текста: остаются особенности частей, их перекрытия, порядка и метаданных.
• BYPASS_EMBEDDING_AND_RETRIEVAL — отдельный обход, который затрагивает получение контекста и новую обработку файлов. После извлечения и сохранения текста он позволяет пропустить запись в векторное хранилище. Это не другое название переключателя одного вложения.

Для локальной Knowledge в применимой ветви полного текста или bypass читается сохранённое содержимое её файлов. У внешнего источника сначала выполняется внешнее retrieval-обращение. Поэтому Full Context нельзя понимать как обещание выгрузить весь внешний корпус.

Наконец, выключенный File Context означает пропуск автоматической подготовки и подачи контекста. Он не отменяет прежнее извлечение и индексацию и не отправляет исходный файл через файловый API провайдера. Правильно доступные инструменты всё ещё могут получать сохранённый текст. Поэтому для выбора полезнее назвать известное подключение и его условия, чем судить по одному слову Full или Native.

Как выбрать достаточный путь и при желании сравнить доступное

У каждого способа есть положительное назначение. Выбор не требует сначала добиться неудачи другого способа. Сопоставим, какую работу он выполняет и когда она нужна:

Таблица сравнивает применимость, а не ранжирует качество. Подготовленный текст чата может сочетаться с инструментальными обращениями. Для маленькой памятки доступные варианты могут дать одинаково достаточную опору; такой результат не требует усложнять источник.

По последовательности операций можно объяснить возможные затраты. Автоматический путь может добавлять подготовку поискового запроса, вычисление embeddings и реранжирование — эти операции предусмотрены обработкой поиска. Полный текст может увеличить объём запроса к модели. Инструменты могут добавлять обращения и продолжения. Это причинное объяснение, а не измерение скорости или стоимости: самого быстрого, дешёвого или точного варианта для всех задач оно не устанавливает.

Сравнение запросов необязательно. Если хотите его провести в уже доступных разрешённых условиях, продолжайте одну запись из предыдущего урока. Сохраните точный документ и версию, прежние вопросы и критерии, результат доступной сверки сохранённого текста, версию Open WebUI, модель и провайдера, сопоставимую переписку, место подключения и известные действующие настройки. Неизвестные значения так и обозначьте; подставлять вместо них значения по умолчанию из документации не нужно.

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

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

• Если доступной опоры достаточно и ответ сохраняет нужные отношения, текущий путь можно оставить для этих вопросов и условий.
• Если сохранённый текст расходится с оригиналом, вернитесь к сверке извлечения. Смена способа обращения не восстановит потерянные сведения.
• Если нужная связь есть в сохранённом тексте, но не видна в доступной опоре, можно рассмотреть другой доступный способ получения текста. Это ещё не доказательство, что связь не поступила модели: часть контекста может быть скрыта.
• Если видимая опора достаточна, а ответ искажает условие или числа, обнаружено расхождение ответа с опорой. Смена доставки пока не доказана как средство его исправления.

При записи сохраняйте различия состояний. Пустой результат означает, что конкретное обращение не вернуло результатов; ошибка сообщает о проблеме выполнения. Недоступный путь ограничивает сравнение и не считается проигравшим. Частичное чтение устанавливает неполноту этого результата, но может быть достаточным для вопроса. Скрытый контекст или не показанный вызов оставляет соответствующий этап неизвестным. В частности, сообщение File not found возвращается и при отсутствии файла, и при отсутствии доступа; по нему одному выбрать причину нельзя.

Только если есть содержательное основание и доступная возможность, рассмотрите одну альтернативу на тех же вопросах. Сохраняйте источник, модель, провайдера и сопоставимую переписку. Если ради другого пути изменились место подключения, режим вызова, модель или несколько настроек, отметьте это: вы сравнили сочетания условий, а не изолировали действие одного механизма. Различие сгенерированных поисковых запросов также ограничивает причинный вывод.

Для такого наблюдения не нужны три обязательных опыта, новая Knowledge, другой платный провайдер, смена embedding-модели, Reset, Reindex или удаление данных. Задержку и стоимость записывайте лишь при фактическом измерении, с единицами, источником показателя и условиями. Предполагаемые цифры результатом сравнения не являются.

Если различий на памятке не обнаружено, можно так и завершить запись. Если запросы не выполнялись, у вас остаются источник, критерии и понимание применимости, но результатов работы Open WebUI пока нет. Это разные итоги; ни один не устанавливает превосходства способа. Подробная проверка цитат и оценка качества ответов — отдельная тема следующего урока.

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