Как запретить обрезку текста в Ollama Embed API через truncate:false

• POST /api/embed принимает boolean-параметр truncate.
• По умолчанию truncate равен true и конец слишком длинного input обрезается.
• При truncate:false API возвращает ошибку, если input превышает context length.
• Параметр применяется к тексту или списку текстов в поле input.
• Правильное исправление длинного документа — явное разбиение на chunks, а не повтор с молчаливой обрезкой.

Эти пункты задают границу решения. Не расширяйте их предположениями: наличие поля не гарантирует истинность содержимого, HTTP 200 не подтверждает бизнес-состояние, а комментарий в коде не заменяет assert.

Подготовка стенда

• Зафиксируйте версию SDK, Ollama и точное имя тестовой модели.
• Используйте fake tool или provider stub для сценариев с побочными эффектами.
• Удалите токены, персональные данные, реальные счета и внутренние пути.
• Добавьте счётчики model calls и tool executions.
• Настройте завершение процесса с ошибкой при несовпадении контракта.

Тестовый ввод должен быть небольшим, но реалистичным. Идентификаторы T-781 и INV-781 в статье вымышлены. Для длинного текста создавайте синтетическую строку без копирования пользовательских документов.

Пошаговые действия

1. Для индексатора задайте truncate:false во всех embed-запросах.
2. Проверяйте HTTP status до чтения embeddings.
3. При ошибке длины разбейте документ по смысловым границам и сохраните chunk id плюс позицию.
4. Негативный тест отправляет заведомо длинную тестовую строку; точный предел берётся из вашей модели, а не выдумывается в статье.

После каждого действия сохраняйте минимальное доказательство: класс объекта, длину списка, status code, обязательное поле JSON или порядок событий. Полный prompt и raw payload в журнал не нужны.

Копируемый пример

Сохраните пример как отдельный файл языка javascript. Значения в угловых скобках — заполнители; их нельзя выдавать за реальные digest или идентификаторы.

const payload = {
  model: "all-minilm",
  input: documentText,
  truncate: false
};
const res = await fetch("http://localhost:11434/api/embed", {
  method: "POST",
  headers: {"content-type": "application/json"},
  body: JSON.stringify(payload)
});
if (!res.ok) {
  const detail = await res.text();
  throw new Error("embed rejected: " + res.status + " " + detail);
}
const data = await res.json();
if (!Array.isArray(data.embeddings) || data.embeddings.length !== 1)
  throw new Error("unexpected embeddings shape");

Python запускайте в virtualenv проекта, JavaScript — как .mjs в Node.js с fetch. Не смешивайте глобальную и проектную версии. Если импорт отсутствует, сначала проверьте установленную версию, а не подбирайте похожий API.

Реалистичный вход

Вход A — один короткий абзац. Вход B — синтетический текст, который гарантированно превышает context length установленной embedding-модели.

Ожидаемый результат

A возвращает один vector. B при truncate:false завершается ошибкой и не попадает в индекс как будто документ обработан полностью.

Ожидание перенесите в assert или throw. Если текст модели недетерминирован, сравнивайте структурный инвариант. Если API возвращает массив, проверяйте число элементов и форму каждого.

Негативная проверка

Уберите truncate:false. Запрос B может вернуть embedding усечённого текста; тест должен показать, почему успешный status без контроля параметра опасен.

Негативный тест должен ломать ровно одно условие. Сетевая ошибка не равна 404, пустой список не равен PASS, новый запуск не равен resume, а локально созданный UUID не равен response ID провайдера.

Готовый prompt для ревью

Проверь embed-клиент: truncate явно false, ошибка длины не проглатывается, документ режется на адресуемые chunks, число embeddings совпадает с числом входов.

Верни таблицу: условие, доказательство из кода или очищенного лога, PASS/FAIL, минимальное исправление. Если доказательства нет — FAIL. Не додумывай версии, статусы и результаты.

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

Независимая проверка

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

Для agent run отдельно считайте model responses, tools и RunItem: это разные сущности. Для Ollama проверяйте HTTP и тело. Если операция изменяет модель или индекс, после неё используйте read-only endpoint или схему хранилища как второе доказательство.