Ollama context — это размер окна в токенах, которое модель видит за один запрос: туда обязаны уместиться документ, вопрос и ответ. Для длинного регламента окно задают явно, параметром num_ctx либо переменной OLLAMA_CONTEXT_LENGTH, а потерю фактов проверяют контрольными вопросами, поскольку окно нужного размера и внимательное чтение — разные свойства. Если документ короткий и входит с запасом, хватит проверки из последнего раздела.
Что такое окно
Окно измеряется в токенах и делится между документом, вопросом и ответом модели. По документации Ollama значение по умолчанию зависит от видеопамяти: на картах до 24 ГиБ оно составляет 4 тысячи токенов, поэтому для длинного регламента окно задают явно и затем проверяют.
Условный сценарий: отдел закупок хранит регламент на несколько десятков страниц, и сотрудник спрашивает модель, какой порог согласования действует для разовой закупки у единственного поставщика. Ответ лежит в середине документа, в разделе исключений. Если часть текста вышла за границу окна, ответ может строиться по оставшемуся, а тон останется таким же уверенным.
Число из документации относится к дате проверки и к конкретным версиям, поэтому сверяйте его на своей установке. Страница о длине контекста связывает значение с видеопамятью, а раздел FAQ в репозитории Ollama называет 4096 токенов без привязки к памяти: источники расходятся, и точное значение показывает только ваш сервер. Страницы пересчитывают в токены пробным подсчётом на своих файлах: число токенов зависит от языка и модели, формулой тут обойтись трудно. Подробнее о понятиях рассказывают термины окно контекста и токены.
Размер документа оценивайте до выбора окна. Возьмите самый длинный реальный регламент, прибавьте вопрос и запас на ответ: сумма даёт нижнюю границу. Лишний запас стоит памяти, поэтому окно под средний документ и отдельная схема для редких длинных файлов обычно разумнее одного большого значения для всех запросов.
Когда документов десятки, а вопрос касается одного места, выручает поиск по фрагментам. Общую схему такого поиска объясняет статья про RAG в компании; здесь разобрано, как управлять окном и что делать, если документ шире него.
Где задать окно
Документация Ollama называет несколько способов, и действуют они на разной ширине: от приложения до отдельного запроса.
| Способ | Область действия | Когда применять |
|---|---|---|
| Ползунок в настройках приложения | Все модели на этом компьютере | Рабочее место сотрудника с графическим приложением |
Переменная OLLAMA_CONTEXT_LENGTH при запуске сервера | Весь сервер, пока значение остаётся прежним | Общий сервер команды с единым правилом |
Параметр num_ctx в options запроса к /api/chat или /api/generate | Один запрос | Скрипт, которому нужно окно под конкретный документ |
Строка PARAMETER num_ctx в Modelfile | Собственная сборка модели | Окно закрепляют за моделью, которую использует отдел |
Команда /set parameter num_ctx в интерактивной сессии | Текущая сессия | Ручная проба перед написанием скрипта |
Проверяйте фактический результат: одной настройки мало. Команда ollama ps выводит загруженные модели, и колонка CONTEXT показывает окно, которое действует на самом деле. Рядом стоит колонка PROCESSOR: по документации, большее окно требует больше памяти, а перенос части модели на процессор советуют избегать. После каждой смены значения смотрите оба столбца.
Типичная ловушка — разные значения у приложения и у сервера. Сотрудник проверил модель в приложении при большом окне, а скрипт обращается к серверу с настройками по умолчанию, и результаты расходятся. Записывайте в описании скрипта, к какому серверу он ходит и какое окно ожидает, а при запуске сверяйте ожидаемое значение с выводом ollama ps.
Окно способны задать и скрипт, и сервер, и расхождение между ними быстро превращается в загадку для коллег. Назначьте одно место, где окно определяется для общего сервера, и записывайте в журнал значение, с которым фактически отработал запрос. Сервер в контейнере получает переменную через окружение, как описано в статье про Ollama в Docker.
Чанки вместо целого
Когда документ шире окна или вопрос касается одного пункта, документ режут на фрагменты, чанки, и в запрос отправляют только подходящие. Границы проводят по смыслу: по заголовкам и пунктам регламента. Нарезка по числу знаков отделяет исключение от правила, к которому оно относится, и модель отвечает по половине условия.
- Фрагмент несёт заголовок раздела и номер пункта, чтобы ответ сверялся с оригиналом.
- Соседние фрагменты перекрываются на пару предложений, так условие и исключение остаются рядом.
- Таблицы и перечни идут целиком одним фрагментом.
- Каждый фрагмент хранит имя файла и версию документа.
Отбор фрагментов под вопрос — задача поиска. Код сравнивает вопрос с фрагментами (приём описан в статье про эмбеддинги Ollama), а модель получает небольшое число найденных кусков и формулирует ответ по ним. Термин чанкинг объясняет, почему размер куска влияет на точность поиска.
Цена нарезки — риск: нужный пункт мог остаться вне выборки. Поэтому в ответе показывают источники, а сотрудник открывает пункт регламента сам, прежде чем действовать.
Сканы и таблицы проверяйте отдельно: текст после распознавания содержит ошибки, и контрольный факт, вставленный в чистый файл, о сканированной копии даёт мало сведений. Для скана нужен собственный набор вопросов по реальному результату распознавания.
Проверка потери фактов
Модель, получившая длинный документ целиком, способна пропустить факт из середины, и выяснить это удаётся только опытом на собственном тексте. Для опыта нужен тест с контрольными фактами.
- Возьмите копию регламента и вставьте в неё пять вымышленных фактов, которых нет ни в одном реальном документе: в начало, середину и конец.
- Для каждого факта подготовьте вопрос с однозначным ответом и запишите эталон.
- Задайте окно через
num_ctxи сверьте его командойollama ps. - Отправьте документ и вопросы по очереди, ответы сохраните в таблицу.
- Сравните ответы с эталоном кодом: нашлась ли ожидаемая фраза или число, и пометьте положение факта.
- Повторите опыт с увеличенным окном и с нарезкой на чанки, затем сопоставьте результаты.
Пропуски обычно группируются по положению. Если теряются факты из середины, увеличивайте долю нарезки; если ошибки разбросаны независимо от места, меняйте модель либо формулировку вопроса. Эталон храните рядом со скриптом, потому что тот же набор понадобится после смены модели или версии Ollama.
Результаты полезно показать тем, кто отвечает за сам документ: именно они скажут, какие ошибки терпимы, а какие закрывают допуск.
Какой документ вы хотите проверить на потерю фактов?
Допуск и контроль
Допуск к работе зависит от цены ошибки. Для справочного ответа сотруднику достаточно, чтобы контрольные факты находились, а модель показывала источник. Для документа, по которому платят или подписывают, ответ служит подсказкой, и решение принимает человек, сверивший пункт.
Распределение ролей получается таким. Код нарезает документ, ищет фрагменты, считает токены и сверяет цитату с оригиналом: строка из ответа обязана найтись в тексте фрагмента, иначе ответ отклоняется автоматически. Модель объясняет найденное простыми словами. Человек открывает пункт, на который сослалась модель, и подтверждает действие.
Отдельно решите, кто поддерживает набор. Регламент выходит в новой редакции, и контрольные факты устаревают вместе с прежней. Закрепите владельца набора, правило обновления эталона при выходе редакции и момент, когда прежние результаты считаются недействительными.
Для повторных проверок закрепите версию документа: изменённый регламент меняет эталон. Общую схему рабочего поиска по документам компании описывает страница про нейросети для документов.
Зафиксируйте в журнале три значения: окно, версию документа и долю найденных контрольных фактов. Если доля падает после обновления сервера или модели, откатывайте обновление до разбора причин.