Поиск для локальной модели с малым окном контекста
Команды с требованиями к хранению данных, локальный контур, on-premise
Локальная модель на 32k - разумный компромисс: данные не уходят наружу, стоимость предсказуема. Но одна длинная страница легко съедает всё окно, и на ответ уже ничего не остаётся. Проблема не в модели, а в том, сколько текста вы в неё кладёте.
Обновлено 27 сентября 2026
Что мешает сейчас
- Одна страница со скриптами и меню - десятки тысяч токенов, окно закрыто.
- Обрезать текст вслепую - потерять ответ, который был ниже отреза.
- Локальная модель хуже держит длинный контекст и теряет середину.
- Внешний API нельзя пустить внутрь контура, а без сети модель слепа.
Как это делается
- 01
Уберите лишнее до подачи
Страница читается в чистом Markdown без навигации, рекламы и скриптов. Это не косметика: на вход модели уходят именно те токены, которые она оплачивает временем и качеством.
- 02
Подавайте окнами
read_url отдаёт длинный документ частями: offset в запросе, meta.nextOffset в ответе. Вы читаете ровно столько, сколько помещается, и не теряете продолжение.
- 03
Отдавайте результат вместо источника
verify_claim переваривает несколько страниц и возвращает короткий вердикт с цитатами. answer_search возвращает готовый ответ по пяти страницам. Пятьдесят тысяч токенов чужого текста превращаются в сотни токенов результата.
- 04
Забирайте поля, а не текст
extract отдаёт объект по вашей схеме: если нужна цена, модель получит цену, а не страницу вокруг неё.
Инструменты в этом сценарии
read_urlextractverify_claimanswer_searchЧто на выходе: Контур остаётся закрытым: наружу уходит запрос, внутрь возвращается короткий результат. Локальная модель работает по свежим данным, не расширяя окно и не теряя качество.
Дальше по теме
Осталось непонятное?
срезAI - не универсальный поиск: у него есть задачи, под которые он не подходит, и мы говорим об этом прямо. Опишите свою - скажем честно, решается она нашим API или чужим.