Как настроить разбиение документов, поиск и реранжирование в Open WebUI

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

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

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

Какие сведения должны дойти до ответа

Возьмём тот же источник, что в уроке об эмбеддингах и смене модели:

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

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

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

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

До знакомства с настройками определим, что будем проверять:

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

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

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

Как разбиение готовит текст для поиска

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

Названия полей и поведение далее относятся к Open WebUI v0.12.4, исследованной 26 октября 2026 года по местной дате, 25 октября по UTC. Версия и работающий экран вашей установки при подготовке урока не проверялись.

В выбранном пути обработка получает от загрузчика текстовые единицы с дополнительными сведениями об источнике. Такая единица не обязательно совпадает со страницей PDF. Затем код разбиения создаёт части, которые также называют фрагментами или chunks. Из них подготавливаются поисковые представления.

Chunk Size / «Размер фрагмента» ограничивает длину части в единицах выбранного разделителя. Более крупная часть может вместить заголовок вместе со строкой таблицы, но также включить постороннее для вопроса содержание. Более мелкая может отделить условие от сведений, к которым оно относится. По одному размеру нельзя определить, какой вариант подойдёт вашим вопросам.

Chunk Overlap / «Перекрытие фрагментов» задаёт перекрытие соседних частей: часть содержания может повторяться около границы. Это помогает понять назначение поля, но не даёт обещания, что на каждой границе повторятся ровно столько же видимых символов или обязательно сохранится нужное условие.

Сначала посмотрите, какой Text Splitter / «Разделитель текста» действует. В исследованной реализации единицы различаются:

• Character измеряет длину строки функцией Python len. Это не число слов или страниц и не точный подсчёт видимых графем: один воспринимаемый знак может состоять из нескольких элементов строки.
• Token (Tiktoken) измеряет текст в токенах выбранной кодировки Tiktoken. Токены — единицы, на которые текст разбирается для обработки; они не совпадают автоматически со словами.
• Token (Transformers) использует длину по применяемому токенизатору — инструменту разбиения текста на токены. Он не обязан совпадать с токенизатором чат-модели.

И размер, и перекрытие следует читать в этих единицах. Для Transformers пустое поле модели токенизатора не означает автоматический переход на Tiktoken: используется доступный токенизатор embedding-функции либо возникает ошибка. В сборке Slim разбиение через Transformers недоступно. Выбирать новый токенизатор ради самого прохождения урока не требуется.

Для документов с разметкой Markdown есть ещё один уровень подготовки. При включённом Markdown Header Text Splitter / «Разделение текста по заголовкам Markdown» текст сначала разделяется по заголовкам уровней H1–H6, а затем проходит основной разделитель. Заголовки сохраняются в тексте при этой предварительной обработке, но это не обещает их повторения в каждой конечной части.

Поле Chunk Min Size Target / «Минимальный размер чанка» при включённой обработке Markdown задаёт цель объединения небольших секций. Алгоритм пытается присоединять соседние секции: возможны объединение вперёд и добавление назад, с учётом совместимости источника и максимального размера. Значение 0 отключает объединение. Это попытка достичь целевого размера, а не гарантия для каждой части и не проверка смысловой целостности таблицы.

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

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

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

Как вопрос превращается в кандидатов поиска

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

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

Различим способы первоначального отбора через их работу:

• Векторный, или смысловой, поиск сопоставляет числовое представление запроса с представлениями подготовленного текста. Он позволяет искать близость формулировок, а не только повторение тех же слов. Близость при этом не удостоверяет, что найдено нужное условие.
• Лексический поиск сопоставляет текст по правилам конкретной реализации. Для него существенны используемые слова и способ их обработки. Он не даёт универсальной гарантии нахождения любого точного обозначения или кода.
• Гибридный поиск, Hybrid Search, сочетает лексический и векторный отбор. В рассмотренных реализациях результаты объединяются с учётом их мест в ранжированных списках. Это не простое сложение исходных оценок разных способов поиска.

Для вопроса о чае важен конечный смысл: можно ли из отобранного текста установить обязательность своей кружки. Название способа поиска этого не доказывает. Гибридный поиск также нельзя заранее объявить лучшим для любого документа.

Top K ограничивает применимый отбор. Обозначим его значение буквой k. Чтобы правильно понять этот предел, нужно различать способ обращения к источнику и реализацию поиска. Стандартное подключение документа и вызов поискового инструмента моделью — разные способы обращения. Внутри обращения поиск, в свою очередь, может использовать реализацию адаптера хранилища, называемую native hybrid, либо общую ветвь приложения, называемую legacy. Эти два различия не сводятся к одному режиму «native».

У гибридных ветвей различается размер набора перед дополнительной оценкой:

• В native hybrid адаптер ограничивает возвращаемый набор значением k ещё до этой оценки.
• В legacy hybrid от каждой из двух ветвей может поступить до k результатов. До дальнейшего отбора их объединение может содержать до 2 × k уникальных кандидатов на один запрос к одной коллекции хранилища.

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

Лексическая составляющая тоже устроена неодинаково. Legacy использует BM25; в рассмотренной ветви Milvus также применяется BM25, а pgvector использует полнотекстовый поиск PostgreSQL. Поэтому общее описание — «лексический плюс векторный поиск». Эти различия нужны для понимания действующей настройки; выбирать другую базу данных здесь не требуется.

У поисковых инструментов модели свои правила лимита. Их полезно знать, чтобы не переносить совет про административный Top K на любой вызов:

• query_knowledge_files использует собственный аргумент count, по умолчанию равный 5. Отдельно предусмотрена подстановка 5, если переданное строкой значение не удалось преобразовать в число. Общий rag.top_k этот инструмент не читает. Его внутренний поиск при этом учитывает применимые настройки гибридного отбора, реранжирования и порога.
• query_chat_files читает серверный Top K — rag.top_k, с предусмотренной подстановкой 5. Если count не задан, используется этот предел; заданное количество ограничивается диапазоном от 1 до этого Top K. При Full Context поиск по частям может обходиться.

Числа здесь описывают поведение двух инструментов, а не рекомендуют размер выдачи. Полное сравнение способов обращения и передачи контекста относится к уроку 07.06. Для дальнейшей практики будем устанавливать именно тот путь, на котором выбранное поле действует.

У найденного набора уже есть границы. Следующий этап может работать только с текстами, которые в него попали.

Что меняет реранкер после поиска

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

Так разделяются роли моделей: embedding-модель готовит числовые представления, реранкер оценивает пары запроса и найденного текста, чат-модель позднее составляет ответ. Ни перестановка кандидатов, ни новая оценка не восстанавливают сведения, потерянные до индексации.

При обычном успешном выполнении дополнительный отбор устроен так:

1. Получить оценки соответствия кандидатов запросу.
2. Применить предусмотренный порог и упорядочить оставшиеся результаты по оценке.
3. Оставить ограниченное число результатов для передачи дальше.

Top K Reranker / «Top K реранкера» относится к выходу после оценки. Уменьшение этого значения само по себе не уменьшает число пар, которые отправлены на оценивание. Увеличение не расширяет исходный набор кандидатов. Кроме того, выход может ограничиваться Top K: при обычном завершении этой ветви на запрос к коллекции остаётся не больше меньшего из двух значений. Переносить это правило на весь чат или исключительные случаи отказа нельзя. Порядок фильтрации и ограничения выхода установлен по потребителю настройки.

Relevance Threshold / «Порог релевантности» действует на оценку кандидата в применимой ветви. При включённой фильтрации остаются оценки не ниже порога. Значение 0 отключает эту фильтрацию полностью; оно не означает, что отрицательные косинусные оценки обязательно будут отброшены.

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

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

В настройках предусмотрены способы выполнения Default (SentenceTransformers) и External. В Slim внутренние возможности ограничены: для этого этапа предусмотрены внешний реранкер либо косинусная переоценка без отдельной модели. Перечень вариантов задаёт реализация выбора реранкера; название поля не подтверждает, что модель действительно загружена и работает.

При External фактический запрос и тексты кандидатов передаются по настроенному адресу сервиса. Реального получателя, допустимость передачи и условия обработки выясняют по подключению. Из названия External не следуют локальность, стоимость или правила хранения данных. Для проверки одного поля отбора нет необходимости подключать новый сервис или скачивать модель.

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

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

Сохраните исходный результат и примените одно изменение

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

Для изменения нужен разрешённый тестовый экземпляр и полномочия на все данные, которые реально затронет выбранное действие. Уточните фактических получателей текста и допустимые ресурсы обработки. Само название «тестовая среда» не устанавливает её содержимое или подключённые сервисы.

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

Различите то, что видите. Оригинал показывает содержание файла. Indexed text, если он доступен, показывает сохранённый текст, по которому можно проверить условие кружки и связь табличных значений. Раскрытая цитата показывает предоставленные для неё фрагменты. Ответ модели — отдельное изложение этих сведений.

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

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

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

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

Та же запись затем дополнится наблюдениями «после» и выводом. Не нужно заводить отдельный набор таблиц на каждый этап. Источник, его сохранённый текст, состав подключённых данных, embedding-модель, чат-модель, используемый реранкер и остальные настройки в сравнении сохраняются. Для переписки нужны сопоставимые условия, поскольку её содержание может влиять на поисковые запросы.

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

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

Запишите прежнее и выбранное новое значение, основание выбора и ожидаемое наблюдение. Направление изменения определяется вашей гипотезой и ограничениями среды. Готового совета всем увеличить размер, поднять Top K или снизить порог здесь нет. Если основания для разумной гипотезы не хватает, полезный следующий шаг — получить конкретное недостающее свидетельство.

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

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

Общий Reindex не входит в упражнение с одной памяткой. Он последовательно затрагивает файлы Knowledge и связанные с ними отдельные файловые коллекции, поисковые представления названий и описаний Knowledge, затем Memory. Выбор памятки не сужает этот охват. Старые коллекции удаляются до построения новых; возможен частичный результат, а общего автоматического возврата всех стадий к прежнему состоянию при сбое не установлено. Используется сохранённый текст из SQL-базы, без повторного чтения PDF и OCR; самостоятельные файлы, загруженные только в чат, не охвачены. Неизвестный исход того же запуска выясняют до повторения, а возврат значения настройки не восстанавливает удалённые векторы. Эти последствия разобраны в уроке о смене embedding-модели и переиндексации. Reset и удаление uploads здесь также не предлагаются.

Сохраните выбранное изменение и проверьте действующее состояние. Когда применимость и условия установлены, в исследованной версии настройки находятся в Settings → Admin → Documents. Параметры разбиения собраны в Content Extraction / «Извлечение содержимого», параметры поиска — в Retrieval / «Поиск». Набор видимых полей зависит от режима: при обходе embedding и поиска поля разбиения скрыты, при Full Context гибридные настройки не показываются.

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

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

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

Сравните опоры и ответы и выберите следующий шаг

После подтверждённого применения повторите прежние точные вопросы в сохранённых условиях. Дополните ту же запись: сначала реально доступная опора «после», рядом — ответ, затем сопоставление с исходным наблюдением. Критерии не меняются под понравившуюся выдачу.

Для чая проверьте, читается ли обязательность собственной кружки. Для воды — связаны ли 0,50 л и 20,00 руб. с одной порцией воды, сохранены ли единицы и назначение значений. Для бутылки — указан ли способ выдачи без добавленных правил. Нужное отношение может читаться в нескольких доступных частях вместе; помещать его в один физический фрагмент необязательно.

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

Теперь выберите вывод по вашим наблюдениям:

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

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

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