Как добавить файл и прошлый разговор в чат Open WebUI

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

Все данные, названия и реплики в этом примере условные: учебная карточка не загружалась в живой экземпляр, разговор не выбирался в меню, а генерация ответа не запускалась. На этой задаче мы разберём устройство интерфейса и серверных маршрутов по коду и документации стабильного релиза Open WebUI v0.12.3, чтобы вы могли осознанно передать материалы в свой запрос и проверить результат.

Разделите факты встречи и решение о форме объявления

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

Для нашего объявления понадобятся два разных источника и сам текст нового запроса. Первый источник — файл vstrecha-knizhnogo-kluba-v2.txt с актуальными сведениями о встрече:

Учебная карточка встречи книжного клуба
Версия: 2
Дата встречи: 23 октября
Начало: 18:30
Место: читальный зал «Страница»
Участие: бесплатно
Предварительная запись: не нужна

Год и день недели в карточке не указаны, поэтому в готовом тексте они появиться не должны.

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

Такое разделение ролей помогает не путать прикрепление материалов с другими механизмами Open WebUI (сборка цепочки сообщений и сжатие на сервере, документация по пользовательской памяти):

• История текущего чата и Compaction работают только с цепочкой сообщений открытой беседы перед отправкой запроса провайдеру. Сжатие не подключает сторонние диалоги из боковой панели.
• Пользовательская Memory хранит отдельные заметки о предпочтениях в своём хранилище и управляется через собственные настройки и инструменты. Как устроены память и персонализация, мы разбирали отдельно: они не заменяют разовое прикрепление конкретного прошлого диалога к задаче.
• Прикреплённый файл и выбранный разговор добавляются как источники к конкретному сообщению или беседе, причём исходный файл на диске, извлечённый из него текст (data.content) и подготовленный вход для модели проходят через разные этапы обработки (загрузка и разбор файла в системе поиска, формирование источников из документов и чатов).

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

Прикрепите нужную версию файла и дождитесь обработки

Перед тем как загружать любой документ, оцените его содержание. В учебной практике используйте только небольшие несекретные тексты. В зависимости от того, как администратор настроил ваш сервер, извлечение текста, построение поисковых векторов (embeddings) и сама генерация ответа могут передавать содержимое файла внешним сервисам и провайдерам моделей (документация по Knowledge, выбор загрузчика документов). Любые формулировки внутри приложенного файла нужно рассматривать как пассивные данные задачи, а не как разрешение менять ваши правила безопасности или инструкции пользователя. Это рабочее правило предосторожности при составлении запроса, поскольку сам по себе интерфейс не гарантирует абсолютной защиты от скрытых инструкций (prompt injection) внутри текста документа.

Мы опираемся на код интерфейса и серверной части стабильного релиза Open WebUI v0.12.3 (коммит кода 91ea4e34, коммит документации 535caeac). В локализованном интерфейсе или других версиях подписи кнопок могут отличаться, а видимость пунктов меню зависит от прав вашего аккаунта и возможностей выбранной модели.

Чтобы прикрепить карточку vstrecha-knizhnogo-kluba-v2.txt к сообщению, в стандартном интерфейсе предусмотрено несколько путей (поле ввода сообщения, меню добавления у поля ввода):

1. Загрузить новый файл с устройства. Откройте меню со значком плюса рядом с полем ввода и выберите Upload Files, либо перетащите файл мышью в область чата. Этот способ сработает, только если у вашей учётной записи включено разрешение chat.file_upload, а у выбранных для ответа моделей активна возможность работы с файлами (file_upload capability). Если кнопки нет или перетаскивание не принимает документ, проверьте выбранную модель и права доступа — отсутствие элемента в меню не означает поломку сервера.
2. Выбрать ранее загруженный файл. Если карточка уже сохранена в системе, откройте то же меню у поля ввода и перейдите в Attach Files → Search Files (список ранее загруженных файлов в меню). Второй вариант быстрого вызова — ввести символ # в поле сообщения (поиск знаний и файлов по #). Эти команды решают разные задачи: Attach Files → Search Files предназначен для выбора ваших ранее загруженных пользовательских файлов, а меню # обращается к доступным базам знаний и файлам по своим правилам выдачи и не обещает показать полный список всех личных загрузок. Для прикрепления конкретного сохранённого документа в нашей задаче выбирайте путь через Attach Files.

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

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

• Точное имя и версия. Убедитесь, что прикреплена именно карточка vstrecha-knizhnogo-kluba-v2.txt, а не черновик первой версии. Если вы случайно выбрали не тот документ, удалите его карточку кнопкой закрытия до отправки сообщения.
• Завершение обработки. Рекомендуется дождаться, пока индикатор загрузки сменится на готовое состояние (uploaded или processed), и проверить, не появилось ли в интерфейсе сообщение об ошибке или предупреждение (пока загрузка в чат не завершена, стандартная кнопка отправки в поле ввода блокируется). При этом сама карточка над полем ввода и статус uploaded показывают лишь состояние выбора и завершения шага загрузки: интерфейс может присвоить статус uploaded даже тогда, когда сервер вернул предупреждение при обработке. Карточка не доказывает, что текст извлёкся без потерь, что модель его прочитала или что ответ будет верным.
• Режим передачи в карточке файла. Если нажать на прикреплённую карточку, открывается окно просмотра (модальное окно элемента файла). Когда для вложения доступно редактирование режима, там виден переключатель между Using Focused Retrieval и Using Entire Document (включение второго варианта записывает в свойства элемента признак context=full, а возврат к первому сбрасывает его). Посмотрите, какое положение установлено сейчас: для новых загрузок в профиле пользователя может быть включён параметр defaultUploadContext=full, поэтому заранее угадать активный режим на чужой установке нельзя. Как этот переключатель меняет путь текста к модели, разберём через один раздел.

Проверьте, какой текст получился из файла

Даже когда на карточке написано vstrecha-knizhnogo-kluba-v2.txt и загрузка прошла без видимых ошибок, модель при текстовом разборе работает не с исходным файлом на диске.

Внутри Open WebUI данные документа проходят цепочку преобразований (обработка файла и сохранение data.content, извлечение контекста из источников):

1. Хранимый оригинал — сам файл, который вы загрузили.
2. Извлечённый текст (data.content) — текстовая строка, которую загрузчик (loader) собрал из файла во время процедуры process_file и сохранил в базе.
3. Поисковый индекс и фрагменты (chunks) — при индексации для поиска система разбивает извлечённый текст на куски и сохраняет их векторные представления. Индекс помогает находить подходящие места по запросу, но сам по себе не равен тексту, который попадёт в текущее сообщение.

Чтобы убедиться, что нужное сведение вообще доступно для текстовой передачи, откройте карточку прикреплённого файла до или после отправки запроса (окно просмотра Content и Preview). Вкладка Content показывает сохранённый извлечённый текст data.content, а вкладка Preview (если она доступна для формата) отображает исходный вид документа. Сам интерфейс предупреждает, что при извлечении текста исходное форматирование может не сохраниться.

Для нашей задачи понадобится одна предметная проверка: открыть вкладку Content у карточки второй версии и глазами сверить с оригиналом строку Начало: 18:30, дату 23 октября и название зала «Страница». Такая ручная сверка версии, даты и нужного факта — наша рабочая методика контроля, а не автоматическая проверка со стороны Open WebUI. При извлечении часть сведений может потеряться или исказиться, поэтому Content всегда стоит сопоставлять с исходным документом.

Особенно важно учитывать устройство разных маршрутов при работе с PDF и изображениями (загрузчик PDF, маршрутизация загрузчиков и OCR):

• Текстовый PDF и скан документа. Стандартный загрузчик PDF (pypdf) постранично извлекает текстовый слой документа. Если вам прислали отсканированное объявление в PDF без пригодного текстового слоя, нужный текст может оказаться недоступен: его получение зависит от того, включено ли извлечение изображений из PDF с оптическим распознаванием (extract_images с участием RapidOCR) или настроен ли внешний загрузчик и движок OCR на сервере. Поэтому режим «весь документ» всегда означает передачу только доступного извлечённого текста из data.content, без гарантии сохранения сложной вёрстки, таблиц или встроенных иллюстраций оригинала.
• Картинка для зрения модели (vision) и распознавание текста (OCR). Когда вы прикрепляете обычное растровое изображение к сообщению в чате, интерфейс направляет его по маршруту vision для визуального осмотра моделью, если выбранная модель поддерживает работу с изображениями (обработка изображений в поле ввода, ветка изображений при загрузке файлов). Это отдельный путь: загрузка картинки в чат для мультимодальной модели не создаёт проверенный текстовый индекс документа, и наоборот — серверный OCR для документов не заменяет поддержку vision у самой модели.

Различайте поиск фрагментов, весь текст и чтение инструментами

Если во вкладке Content есть строка Начало: 18:30, следующий шаг — понять, кто и как доставит этот текст во входные сообщения модели. В Open WebUI возможны два разных принципа доставки: либо сервер сам подбирает текст из прикреплённых материалов и вставляет его в запрос до вызова модели, либо модель во время ответа отдельно запрашивает данные встроенным инструментом, а сервер исполняет её вызов (обработка файлового контекста в middleware.py, условия подключения встроенных инструментов в tools.py, реализация инструментов чтения файлов в builtin.py).

Сопоставим три способа получения текста из файла:

Эти три строки не являются тремя взаимоисключающими кнопками одного меню. Первые два варианта переключаются внутри карточки файла и работают через серверный обработчик files_handler, когда у модели включена возможность file_context. При отправке сообщения сервер формирует один или несколько поисковых запросов (а если генерация поисковых запросов отключена или не удалась, использует текст вашего последнего сообщения), отбирает подходящие фрагменты с учётом настроек количества и порога отбора (top_k, threshold, гибридного поиска и переранжирования) либо берёт весь доступный извлечённый текст data.content для режима Using Entire Document, после чего вставляет собранный блок источников прямо в список сообщений messages.

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

Встроенные инструменты Open WebUI в целом подключаются, когда запрос идёт из интерфейса в обычной пользовательской сессии, выбран не-legacy (Native) режим вызова функций и у самой модели включена поддержка системных инструментов (builtin_tools). А специальный набор файловых инструментов чата (list_chat_files, query_chat_files, grep_chat_files, view_file) становится доступен модели только тогда, когда к этим общим условиям добавляется полный файловый гейт (проверка условий в tools.py):

• включена категория встроенных инструментов files;
• у модели активна возможность загрузки файлов (file_upload), а у пользователя есть право chat.file_upload;
• возможность серверной подстановки file_context у модели выключена;
• к текущему чату действительно прикреплены файлы.

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

Для коллекций из раздела Knowledge действуют свои правила (документация по Knowledge, маршрутизация знаний в middleware.py). В режиме Native для самостоятельного обращения модели к базам знаний требуются тот же общий путь встроенных инструментов интерфейса и включённая категория knowledge. База знаний, привязанная к настройкам самой модели, объединяется с обычными файлами только в старом режиме Legacy, тогда как коллекция, прикреплённая пользователем прямо к чату в режиме полного текста, проходит по своей отдельной ветке обработки. Поэтому само присутствие плашки базы знаний в интерфейсе не доказывает, что модель прочитала её содержимое.

Если модель обращается к материалам через встроенные инструменты, учитывайте настройки подтверждения вызова (Tool Permissions), которые мы разбирали ранее (меню разрешений инструментов, обработка ask и full в middleware.py, настройка enable_tool_permissions в main.py). Диалог с кнопкой Allow появляется не всегда, а только при включённой настройке enable_tool_permissions и выбранном режиме Ask for approval; в режиме Full access инструмент выполняется без паузы. При этом согласие на запуск инструмента и право доступа к самому файлу или чату проверяются независимо друг от друга.

Выбор режима Using Entire Document не гарантирует более точного ответа. На примере короткой карточки из семи строк удобно рассмотреть передачу всего извлечённого текста, если в текущем запросе и контекстном окне модели достаточно свободного места. Но когда в запрос попадает объёмный документ или длинная переписка, полный текст расходует конечное окно модели и может потеснить реплики самой беседы (предупреждение о полном контексте в документации). Как объём передаваемых данных влияет на историю диалога, подробно описано в уроке про контекстное окно и Compaction.

Выберите прошлый разговор и проверьте нужную ветку

Вторая часть нашей задачи — передать модели решение о спокойном тоне без эмодзи из собственного прошлого разговора «Форма объявлений книжного клуба». Как и в случае с файлами, старый диалог нужно явно указать в качестве источника для новой беседы.

В интерфейсе поля ввода для этого есть два прямых действия (меню Reference Chats, список и поиск чатов Chats.svelte, перетаскивание элемента чата в MessageInput.svelte):

• открыть меню со значком плюса у поля сообщения, выбрать Reference Chats и найти нужную беседу в списке Chats или через строку поиска Search Chats;
• перетащить заголовок нужного разговора мышью прямо из боковой панели истории в область ввода сообщения.

Текущий открытый диалог автоматически исключается из списка выбора, чтобы беседа не ссылалась сама на себя. Когда вы выбираете разговор «Форма объявлений книжного клуба», над полем ввода появляется карточка прикреплённого чата (type=chat, со статусом processed).

Здесь важно учитывать, какие именно сообщения из выбранного разговора берёт сервер (формирование документа из чата в retrieval/utils.py). Переписка в Open WebUI может ветвиться, когда вы редактируете вопросы или генерируете несколько вариантов ответа (устройство веток мы разбирали в уроке про первый чат и варианты ответа). При обращении к прошлому чату сервер не склеивает все когда-либо созданные ветки в один текст. Он смотрит на активно выбранное в том разговоре последнее сообщение (history.currentId) и выстраивает от него одну хронологическую цепочку реплик по родительским ссылкам (parent-chain) от начала беседы до выбранного конца.

Из этого устройства следуют три практических ограничения, которые нужно проверить перед отправкой запроса:

1. Нужная реплика должна находиться в активной ветке. Если решение о спокойном разговорном тоне без эмодзи осталось в боковой альтернативной ветке, а прошлый разговор был оставлен на другом варианте ответа, в цепочку currentId эта фраза не попадёт. Откройте прошлый чат и убедитесь, что сейчас в нём выбрана именно та ветка, где зафиксирована договорённость.
2. Старые файловые вложения автоматически не подтягиваются. Прикрепление разговора превращает в текстовый источник только роли участников и текст сообщений выбранной цепочки. Если к тому прошлому чату были приложены какие-то исходные файлы, их оригиналы автоматически в новый чат не переносятся.
3. Прямая серверная подстановка требует прав доступа и активного маршрута file_context. Чтобы сервер превратил выбранную цепочку сообщений в текстовый документ-источник, у модели должен работать путь file_context, а пользователь должен иметь право на чтение этого разговора: быть его владельцем, администратором при включённом на сервере доступе ENABLE_ADMIN_CHAT_ACCESS либо иметь подтверждённый доступ к общему чату или папке (shared_chat / folder read access).

Если запрос идёт по маршруту Native, сервер через функцию add_file_context также может передать прикреплённый разговор как служебный XML-тег с типом, идентификатором и именем чата (type/id/name), чтобы модель при необходимости прочитала его инструментом view_chat (формирование тегов и проверка include_file_context в middleware.py). Такая передача через include_file_context включается только тогда, когда текущий открытый диалог — собственный сохранённый чат пользователя, задействован обычный путь встроенных инструментов интерфейса (пользовательская сессия из UI, не-legacy вызов функций и включённая у модели поддержка builtin_tools), а в запросе не переданы внешние payload_tools. В зависимости от настроек этот XML-тег и прямая серверная подстановка через files_handler могут работать одновременно. Но ни карточка разговора над полем ввода, ни переданный XML-тег сами по себе не содержат полного текста переписки и не доказывают, что модель вызвала инструмент чтения.

Отличайте выбранный чат от самостоятельного поиска моделью

Когда работает описанный выше путь встроенных инструментов интерфейса и включена категория chats, модель получает два инструмента для самостоятельной работы с историей: search_chats для поиска и view_chat для чтения найденной беседы (подключение категории chats в tools.py, условия передачи в middleware.py, код search_chats и view_chat в builtin.py). Из-за этого возникает соблазн не выбирать прошлый разговор вручную и просто попросить модель «вспомнить, как мы оформляем объявления». Однако явный выбор через Reference Chats и самостоятельный поиск моделью устроены по-разному.

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

• Поиск возвращает только короткие выдержки, а не всю переписку. Вызов search_chats ищет совпадения по заголовкам и тексту только среди собственных прошлых чатов пользователя, исключая текущий разговор и архивные чаты (archived). В ответ модель получает список карточек с идентификатором id, заголовком title, временем обновления updated_at и коротким текстовым фрагментом snippet. Это лишь подсказка для выбора, а не полный текст всех ваших диалогов.
• Чтение через view_chat ограничено только собственными чатами пользователя. В отличие от прямой серверной подстановки в Reference Chats, которая при наличии прав может прочитать общий чат или разговор из доступной папки, инструмент view_chat требует пользовательского контекста запроса и проверяет строгое владение беседой (chat_by_id_and_user_id). Прочитать чужой расшаренный разговор этим инструментом модель не сможет.
• Найденный фрагмент и прочитанная ветка могут не совпадать. Инструмент view_chat тоже собирает хронологическую цепочку сообщений только по родительским ссылкам от currentId (плюс заголовок и дату), не объединяя альтернативные ветки и не загружая старые вложенные файлы. Поэтому поиск search_chats может найти ключевое слово в сообщении из неактивной боковой ветки и показать его в snippet, а последующий вызов view_chat вернёт текущую ветку currentId, где этого решения нет.

Как и для файловых инструментов, появление окна Allow перед запуском search_chats или view_chat определяется уже разобранными настройками Tool Permissions, причём разрешение на запуск инструмента не заменяет проверку прав доступа к самому чату. Наличие режима Native не гарантирует, что модель решит запустить поиск, выберет нужный диалог или прочитает ветку с решением о форме объявления.

Сверьте объявление с карточкой и решением из чата

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

В новом чате прикрепите карточку vstrecha-knizhnogo-kluba-v2.txt и собственный разговор «Форма объявлений книжного клуба», предварительно проверив во вкладке Content строку Начало: 18:30, а в прошлом чате — что реплика про спокойный тон без эмодзи находится в активной ветке. Затем отправьте запрос:

Подготовь короткое объявление о встрече книжного клуба. Факты возьми из приложенной карточки версии 2, а решение о тоне и оформлении — из выбранного прошлого разговора. Не переноси из старого разговора даты, время и место других встреч. Не добавляй отсутствующие сведения. После объявления отдельно укажи время начала и назови источник этого факта; если источник недоступен, прямо сообщи об этом.

Последняя фраза запроса просит отдельно назвать источник времени начала или сообщить о его недоступности. Такое требование помогает задать удобную для проверки форму ответа, но не гарантирует честности модели, фактического чтения файла или отсутствия ошибок. Точно так же блок источников или цитата под ответом (source reference / citation) лишь помогают быстро открыть привязанный фрагмент в окне просмотра, но не доказывают, что модель верно перенесла смысл этого фрагмента в само объявление (просмотр источников и Content в интерфейсе, документация по работе с источниками Knowledge).

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

Если вы запускали генерацию, сверьте полученное объявление с карточкой версии 2: дата 23 октября, время начала 18:30, место «читальный зал „Страница“», бесплатное участие и отсутствие предварительной записи. Убедитесь, что в тексте не появились год, день недели, выдуманные контакты или старые время и место из других разговоров, а подача соответствует реплике из прошлого чата — спокойный разговорный тон без эмодзи и рекламных обещаний. Если запуск не проводился, готового ответа для вычитки нет, поэтому фиксируются сами критерии и отметка о невыполнении.

По итогам своей пробы запишите три наблюдения:

1. Выбранные материалы: какой файл (имя, версия 2, видимый статус и режим в карточке) и какой собственный прошлый разговор были выбраны, либо чего из этого на вашей установке не было.
2. Проверка содержимого до или после запроса: что вы увидели во вкладке Content по сравнению с оригиналом карточки (включая строку Начало: 18:30) и находилось ли решение о спокойном тоне без эмодзи в текущей выбранной ветке прошлого чата.
3. Фактический ответ и сверка с источниками: какой текст и источник времени 18:30 выдала модель и совпали ли факты и форма с исходными материалами; а для этого урока или при отсутствии запуска — отметка «не выполнялось» («не проверено»).

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

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