Gabay sa Mahabang Context ng Kimi K3: Pagkasyahin ang Buong Libro at Repository sa 1 Milyong Token

Ang mahabang context ay ang signature na kakayahan ng linya ng produkto ng Kimi, at itinulak ng kimi-k3 ang window sa 1,000,000 token na pinagbabahagi ng input at output. Para maramdaman ang laki: isang request ang kaya ang buong teknikal na libro, lahat ng core file ng maliit na repository, o isang taong meeting notes. Pero ang "kasya" at "gumagana nang maayos" ay magkaibang bagay — kapag lumaki ang window, mas kailangang maingat mong pamahalaan ang kalidad ng input at ang gastos.

Ano ang tunay na kasya sa 1 milyong token

Para sa sanggunian: ang 500-pahinang teknikal na libro ay mga 250,000–400,000 salitang Ingles; ang core code ng katamtamang web project ay karaniwang sampung-libuhang linya; ang taunang meeting notes ay bihirang lumagpas sa 300,000 karakter. Lahat ito ay kasya sa 1 milyong token na window — iyan ang praktikal na kahulugan ng "book-scale na context".

Aling trabaho ang sulit gamitan ng buong window

Pag-unawa sa buong teksto na may cross-section na dependensi. Mga kontrata, prospectus, mahahabang research report — nakakalat ang mga konklusyon sa iba't ibang kabanata at nagtuturo ang mga probisyon. Nawawala ang cross-reference sa chunking; ang isang buong pagbasa ang nagtatayo ng kumpletong larawan.

Repository-level na Q&A. Ilagay ang lahat ng core file ng maliit-hanggang-katamtamang proyekto sa context at sasagot ng model ang cross-file na tanong tulad ng "sino ang tumatawag sa function na ito" o "aling module ang masisira kapag nagbago ang interface na ito" nang walang retrieval pipeline. Sa mas malaking repository, gawin muna ang isang round ng file selection — itago ang core modules, entry points, at type definitions — pagkatapos ay buhusan nang buo.

Naipon na conversation o pipeline context. Sa matagalang proyekto, kailangang laging nariin ang mga naunang desisyon at konklusyon. Sapat ang 1 milyong token para sa buwan-buwang decision chain ng isang proyekto, tinatanggal ang pangangailangan sa madalas na summarization machinery.

Dalawang-hakbang na pattern: hanapin, pagkatapos basahin

Ang pagbuhos ng lahat sa window ay magastos at maingay. Ang mas murang production pattern ay may dalawang yugto:

Yugto isa: paliitin. Gumamit ng maliit na modelo o keyword search para piliin ang mga kaugnay na bahagi ng corpus. Hindi layunin nito ang sagutin ang tanong — ito ay pagliitin ng materyal mula sa "lahat" tungo sa "kaugnay".

Yugto dalawa: malalimang pagbasa. Ibuhos nang buo ang napiling materyal sa kimi-k3 upang gumana ito nang may kumpletong context para sa pagsusuri, pag-iisip, at pagbuo.

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["EXAIV_API_KEY"],
    base_url="https://exaiv.com/api/ai/v1",
)

# Stage two: hand the filtered full text to kimi-k3
resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You are a contract review assistant. Answer only from the given text."},
        {"role": "user", "content": "Below is the full agreement. List every clause unfavorable to party B:\n\n" + contract_text},
    ],
)
print(resp.choices[0].message.content)

Ang bayad ng pattern na ito ay precision: walang di-kaugnay na materyal sa deep-read stage, kaya hindi diluted ang atensyon ng modelo — mas matatag ang mga sagot kaysa sa buhos-lahat approach.

Kontrol sa gastos

Malinaw ang istruktura ng gastos sa mahabang context: input token ang nangingibabaw. Apat na lever para mapababa ang bill:

Bigyan ayon sa pangangailangan. Ang pagtatanong kung ano ang ginagawa ng isang function ay hindi nangangailangan ng buong repository — ipadala ang mga kaugnay na file. Ang mahabang context ay ceiling ng kakayahan, hindi default na setting.

Gamiting muli ang stable prefix. Panatilihin sa unahan ng messages ang system prompt at ang nakapirming bahagi ng mga dokumento nang hindi nagbabago, para tumama ang prefix caching. Sinusuportahan ng kimi-k3 ang automatic prefix caching; ang mga paulit-ulit na request sa parehong mahabang dokumento ay mas mura nang malaki kapag nag-hit.

Putulin ang ingay. Ang log, HTML tag, at base64 image ay token-dense at information-light — linisin muna bago ipakain. Kung 30% ng iyong 1 milyong token ay log noise, nasunog mo nang walang saysay ang 30% ng budget.

Takdahan ang haba ng output. Parehong window ang sinasakop ng output. Magtakda ng makatwirang max_tokens ceiling para hindi sumulat ng sanaysay ang tumalang modelo na ikaw ang magbabayad.

Mga karaniwang bitag

Nawawala sa gitna. Sa napakahahabang context, minsan mas mahina ang paggamit ng impormasyon sa gitna ng window kaysa sa simula at dulo. Nabubuwag ito kung ilalagay ang pinakamahahalagang instruksyon sa system prompt at sa dulo ng user message, at ang kritikal na materyal sa malapit sa mga gilid.

Pagpapanatili ng buong conversation history. Kakainin ng naipong messages ang window. I-summarize nang pana-panahon — panatilihin ang konklusyon at desisyon, i-retire ang process detail.

Pagtingin sa context bilang memory. Walang memory ang modelo sa mga request — bago ang bawat simula. Para sa persistent na memory, ikabit ang kinakailangang background material bawat ulit, o magpanatili ng summary file na i-inject mo sa bawat request.

Pagpapabaya sa tokenizer differences. Malaki ang pagkakaiba-iba ng token density sa halo-halong Tsino-Ingles na teksto, code, at special na simbolo; hindi maaasahan ang pagtatantya mula sa bilang ng mga karakter. Sukatin nang isang beses gamit ang totoong datos bago magtakda ng budget.

Demonstrasyon ng repository Q&A

Ang repository-level na Q&A ang nagpapakita ng pattern na ito mula simula hanggang wakas. Pumili muna ng core files, pagkatapos magtanong nang may buong context:

core_files = ["src/app.ts", "src/routes.ts", "src/services/payment.ts"]
repo_text = "\n\n".join(
    f"// ===== {p} =====\n{open(p).read()}" for p in core_files
)

resp = client.chat.completions.create(
    model="kimi-k3",
    messages=[
        {"role": "system", "content": "You answer questions about this repository. Cite file names."},
        {"role": "user", "content": f"{repo_text}\n\nQuestion: where is the refund policy enforced, and what breaks if we change it?"},
    ],
)

Dalawang gawi ang nagpapatibay sa paraang ito. Una, panatilihing stable ang file inventory sa mga tanong para tumama ang prefix cache — ang ikalawang tanong ay nagkakahalaga lamang ng bahagi ng una. Ikalawa, hilingin sa modelo na mag-cite ng file names sa mga sagot; ang citations ay nagpapabilis ng review at agad naglalantad ng hallucination.

Pagmomonitor ng paggamit ng token

Ang mahahabang workload ay nararapat sa malinaw na pagbabantay. Bawat response ay may dalang usage object:

print(resp.usage.prompt_tokens)      # gastos ng bahaging input
print(resp.usage.completion_tokens)  # gastos ng bahaging output
print(resp.usage.total_tokens)

I-log ito per request at i-aggregate bawat workload. Tatlong signal ang mahalaga: ang ratio ng prompt-sa-completion (nagsasabi kung tamang lever ang pagputol ng input), token bawat tanong (nagsasabi kung sobrang bukal hati ang selection stage), at ang cache-hit behavior sa mga paulit-ulit na tanong (nagsasabi kung tunay na stable ang prefix mo). Ang buong monitoring playbook ay nasa token tracking guide.

FAQ

Ano ang sinasagot ng artikulong ito

• ano ang talaga ang kasya ng 1 milyong token context
• paano mag-analisa ng mahabang dokumento
• paano kontrolin ang gastos ng long context

Mabilisang mapa ng senaryo

Tumingin sa hinaharap

Nagpapatuloy na nagbabago ang catalog at mga weights; ang mga integration at calling convention dito ay sumusunod sa opisyal na dokumento sa oras ng paglalathala.

Mga pinagmulan at beripikasyon

Ang mga pangunahing katotohanan sa artikulong ito ay mula sa opisyal na model card ng Kimi K3 (spec ng context) at platform tokenizer measurements at na-verify noong 2026-11-09. Ang model ID, presyo at availability ay sumusunod sa live catalog ng platform — sinadyang walang nakapirming numerong mabilis mals. Ang mga sample code ay sumusunod sa API contract sa oras ng paglalathala; tingnan ang opisyal na dokumento bago ikonekta sa production.

Saklaw at audience

Audience: mga developer na humahandle ng mahabang dokumento o malalaking repository. Saklaw: mga pattern ng paggamit ng long context, kontrol sa gastos, at mga hangganan. Hindi saklaw: disenyo ng RAG architecture o pagpili ng vector store.

Tala ng patnugot at pagwawasto

Isinulat ng EXAIV content team mula sa mga mapapatunayang katotohanan, na may sinusuri na mga pinagmulan at code bago ilathala. Kung may luma o mali, ang opisyal na release page at live catalog ang batayan — magbigay-alam sa feedback channel ng page para maayos namin ito.

Kaugnay na babasahin

• Gabay sa pagkonekta sa Kimi K3
• Gabay sa RAG Knowledge Base
• Qwen KV Cache at mahabang context
• Pagsubaybay sa token at gastos
• Gabay sa structured output