ollama の入力切り捨てをレスポンスだけで検知する — 3回作り直した記録A practical account of detecting silent input truncation in ollama—where…
匿名の公開いいねです。記事の保存・お気に入りではなく、Featured、Top 3、重要度、掲載順位には影響しません。仕組みとプライバシーAnonymous public likes are reactions, not saved articles or bookmarks. They do not affect Featured, Top 3, importance, or listing order.How it works and privacy
- ollama がコンテキスト長を超えた入力を無警告で切り捨てる問題に対し、レスポンスのみを手がかりに切り捨てを検知する手法を3度の試行錯誤を経て確立した実践記録。
- ローカルLLM運用の信頼性向上に役立つ知見をまとめている。
- A practical account of detecting silent input truncation in ollama—where prompts exceeding the context window are cut without warning—using only the model response as a signal, refined through three redesigns.
- The findings help improve reliability when running LLMs locally.
本ページの本文と要約は AI による自動生成です。日本語版と英語版は言語ごとに独立して生成されるため、表現や詳しさが異なる場合があります。正確性は元記事 (zenn.dev) をご確認ください。The body and summaries are AI-generated independently for each language, so wording and detail may differ. Verify accuracy at the original source (zenn.dev).
要約と収集メタデータに基づく AI 解説。元記事全文の転載・翻訳ではありません。AI explainer based on the summaries and collected metadata, not a copy or translation of the full source article.
無警告の切り捨て
ollamaでは、num_ctxを超えた入力がエラーなく切り捨てられ、HTTP 200が返り、done_reasonもstopになります。そこで、切り捨ての発生をレスポンスだけから判定する検知器が、3回の作り直しを通じて検討されました。
二つの応答値
対象は、/api/generateを非ストリームで呼び出し、送信したnum_ctxとnum_keepを手元に保持しているPython利用者です。検証環境はollama v0.32.1、Windows、Python 3.10以上とされています。
判定材料の一つは、prompt_eval_countとcontextの差です。prompt_eval_countが示すのは切り捨て後の値です。一方、rawが偽の場合に/api/generateから返されるcontextは、切り捨て前のプロンプトを再トークン化した列です。両者が入力の異なる段階を反映するため、その差を検知に利用します。
閉じた式で計算
切り捨て後のprompt_eval_countには、ollama v0.32.1のllm/llama_server.go上で、閉じた式によって値が決まるという性質があります。num_ctxとnum_keepはクライアントが送信しているため、期待される値を手元で計算できます。実測では、num_ctx=1024に対してnum_keepを変えながら挙動が確認されました。
3回の作り直し
最初の検査は、prompt_eval_count >= num_ctx - marginという条件で切り捨てを見ようとし、marginには512を設定していました。しかし1回目と2回目は、作成者が動作していると考えて外部レビューに出した後、本番相当の条件では発火しないと指摘されました。3回目は個々の判定自体は正しかったものの、判定同士の組み合わせに穴がありました。「試したら動いた」ことだけを根拠にすると、単独条件だけでなく条件の組み合わせにも見落としが生じうることを示す記録です。
Silent Input Truncation
Ollama can silently truncate input that exceeds num_ctx, making detection important for reliable local LLM operation. Instead of returning an error, it responds with HTTP 200 and sets done_reason to stop, so those fields alone do not reveal that truncation occurred.
The practical problem is therefore to detect truncation using only information contained in the response, while retaining the num_ctx and num_keep values sent with the request.
Response as a Signal
The method targets Python users calling /api/generate in non-streaming mode with Python 3.10 or later. It was verified with ollama v0.32.1 on Windows.
Two response values provide the initial evidence. prompt_eval_count represents the token count after truncation. By contrast, when /api/generate is called with raw set to false, the returned context is a re-tokenized sequence of the prompt before truncation. The difference between these post-truncation and pre-truncation representations becomes the first basis for detection.
The post-truncation prompt_eval_count also has another useful property. According to the account’s reading of llm/llama_server.go in v0.32.1, its value is determined by a closed expression. Because num_ctx and num_keep are supplied by the client, the expected value can be calculated locally.
Three Redesigns
The detector was rewritten three times. The first two versions were submitted for external review while their author believed they worked, but both were found not to trigger under production-equivalent conditions.
The first inspection attempted to identify truncation with prompt_eval_count >= num_ctx - margin, using a margin of 512. Measurements were also made with num_ctx set to 1024 while varying num_keep.
The third version had a different failure mode: each individual judgment was correct, but the way those judgments were combined left a gap. Across all three failures, the recurring mistake was treating “it worked when tested” as sufficient evidence. The account presents these failure patterns, rather than only the completed code, as the main practical lesson for anyone building a truncation detector.
ポコとTECHガイドPoko & TECH Guide
ポコと当サイトのTECHガイドが、記事の要約と収集した情報から読みどころを語るAI生成の対話です。Poko and TECH Dashboard's own TECH Guide discuss the article's highlights in an AI-generated conversation based on its summary and collected source details.
- ポコPoko検知器を3回も作り直して、最初の2回は本番相当で発火しなかったんだ。これって大きいこと？They rebuilt the detector three times, and the first two versions failed under production-like conditions. Is that a big deal?
- TECHガイドTECH Guide単なる失敗より、試運転だけでは見抜けない3つの壊れ方があった、という重い教訓じゃ。本文も完成品より、その過程に価値を置いておる。It’s an important lesson: quick tests missed three distinct failure modes. The piece treats that process as more valuable than the finished code.
- ポコPokoprompt_eval_count と context の差で検知するって、つまりどういうこと？Detecting it from the difference between prompt_eval_count and context—what does that actually mean?
- TECHガイドTECH Guideコンテキスト長は、モデルが一度に扱える入力の上限じゃ。ここでは切り捨て後の数と、切り捨て前を再トークン化した列の差を手がかりにするのう。The context length is the model’s input limit. Here, the detector uses the gap between the post-truncation count and a tokenized sequence representing the original prompt.
- ポコPoko僕ならローカルLLMへ長い文を送る処理に入れて、入力が黙って欠けたら気づけるようにしたいな。I’d add this when sending long text to a local LLM, so silent input loss doesn’t slip past me.
- TECHガイドTECH Guideただし確認環境は ollama v0.32.1、Windows、Python 3.10以上じゃ。非ストリームの /api/generate で num_ctx と num_keep を保持し、raw は偽という前提じゃよ。Just mind the tested setup: ollama v0.32.1, Windows, and Python 3.10 or later. It assumes non-streaming /api/generate calls, retained num_ctx and num_keep values, and raw set to false.
