Prompt panjang tidak otomatis berarti masalah konteks panjang. Beberapa prompt sebaiknya dipangkas, beberapa sebaiknya menggunakan retrieval, beberapa sebaiknya menyisakan ruang output lebih besar, dan beberapa memang benar-benar membutuhkan context window yang lebih besar. Context window routing adalah kebijakan yang menentukan jalur mana yang harus ditempuh sebuah request sebelum menghabiskan anggaran pada model yang salah.
Tujuannya sederhana: routing berdasarkan ukuran prompt yang sebenarnya, bentuk jawaban yang dibutuhkan, dan bukti yang Anda perlukan untuk kontrol biaya. Percakapan dukungan 6.000 token, review kontrak 70.000 token, dan pemindaian codebase 900.000 token tidak seharusnya memakai satu rute default hanya karena semuanya muat di balik API key yang sama.
Flatkey berguna dalam desain ini karena akses model, routing, peninjauan penggunaan, billing, dan kontrol operasional lebih mudah dikelola dari satu surface gateway daripada dari akun penyedia yang tersebar.
Gunakan framework di bawah untuk merancang aturan context window routing, lalu validasi baris model saat ini, family endpoint, dan unit penggunaan di Flatkey pricing sebelum rollout ke production.
Context window routing dimulai dengan anggaran token
Mulailah setiap keputusan rute dengan anggaran, bukan nama model.
required_context =
system_and_policy_tokens
+ user_input_tokens
+ retrieved_or_attached_context_tokens
+ tool_schema_and_tool_result_tokens
+ conversation_history_tokens
+ reserved_output_tokens
+ reserved_reasoning_tokens
+ safety_margin_tokens
Rute hanya layak jika konteks yang dibutuhkan muat di usable context window model setelah Anda menyisihkan ruang output dan reasoning. Panduan reasoning model dari OpenAI adalah pengingat yang baik di sini: ketika token yang dihasilkan mencapai context window atau max_output_tokens, respons bisa menjadi tidak lengkap, dan tim sebaiknya menyisakan ruang untuk reasoning dan output sambil mengkalibrasi beban kerja.
Cadangan itu penting untuk kontrol biaya. Jika sebuah request nyaris muat di context window, model tetap bisa gagal, terpotong, atau menghabiskan banyak biaya pada token input sebelum mengembalikan jawaban yang tidak berguna. Context window routing yang baik melindungi dari hal itu dengan mengarahkan request yang terlalu besar ke jalur yang tepat sebelum pemanggilan dilakukan.
Matriks routing yang praktis
Gunakan matriks ini sebagai langkah pertama untuk context window routing. Sesuaikan ambangnya dengan jumlah token nyata, katalog model, SLO latensi, dan evaluasi kualitas Anda.
| Class prompt | Sinyal tipikal | Rute yang direkomendasikan | Aturan kontrol biaya | Bukti yang diperlukan |
|---|---|---|---|---|
| Task singkat | Prompt kecil, jawaban kecil, tanpa histori panjang | Rute cepat berbiaya rendah | Hindari model long-context kecuali evaluasi memang mensyaratkannya | Token prompt, token output, tingkat keberhasilan |
| Chat normal | Histori sedang, tools, atau jawaban terstruktur | Rute seimbang dengan dukungan tool dan schema | Beri batas per percakapan atau pemilik | Model yang melayani, ukuran hasil tool, tingkat valid schema |
| Dokumen panjang | File besar, transkrip, kebijakan, atau kontrak | Rute long-context atau rute retrieval | Bandingkan biaya full-context dengan biaya retrieval | Token input, span yang dikutip, kualitas jawaban |
| Korpus sangat besar | Banyak file, codebase, log, atau arsip | Retrieval, chunking, compaction, lalu rute long-context selektif | Jangan memasukkan seluruh korpus secara default | Chunk yang diambil, konteks yang dibuang, tingkat cache hit |
| Prompt berat reasoning | Task panjang plus perencanaan, tools, atau reasoning kode | Rute dengan cadangan output dan reasoning yang eksplisit | Sisihkan ruang output sebelum mengirim prompt | Tingkat tidak lengkap, token reasoning/output, latensi p95 |
| Tinjauan kepatuhan atau keuangan | Konten sensitif dan kebutuhan audit | Rute terpin yang telah ditinjau | Blok fallback otomatis kecuali disetujui | Model yang diminta, model yang dilayani, owner, jejak biaya |
Inilah context window routing dalam bentuk operasional: setiap class memiliki rute, aturan biaya, dan bukti bahwa rute tersebut berhasil.
Jangan gunakan context window terbesar sebagai default
Context window yang besar itu berguna. Namun itu bukan pengganti routing yang gratis.
Dokumentasi long-context Gemini dari Google menjelaskan context window 1M token dan bagaimana long context dapat membuka workflow yang sebelumnya memerlukan summarization, retrieval, atau filtering. Dokumentasi context-window dari Anthropic menjelaskan konteks sebagai working memory yang mencakup isi request, hasil tool, dokumen, definisi tool, dan output. Kedua poin ini penting: jendela yang lebih besar memperluas apa yang mungkin dilakukan, tetapi semua yang Anda masukkan ke dalam jendela itu tetap harus dibayar, divalidasi, dan dicatat.
Default yang paling aman bukanlah "kirim semuanya." Default yang lebih aman adalah:
- Pertahankan prompt pendek pada rute yang efisien.
- Gunakan retrieval ketika jawaban bergantung pada irisan kecil dari korpus besar.
- Gunakan long context ketika model harus membandingkan banyak bagian sumber sekaligus.
- Sisihkan anggaran output dan reasoning sebelum memanggil reasoning model.
- Catat detail penggunaan yang cukup untuk membandingkan biaya per hasil yang diterima.
Itulah inti kontrol biaya dari context window routing.
Kapan retrieval mengungguli long context
Retrieval biasanya lebih baik ketika tugas memiliki kebutuhan bukti yang sempit. Contohnya termasuk "temukan klausul perpanjangan," "ringkas insiden ini dari tiga baris log yang relevan," atau "jawab dari dokumentasi API saat ini." Dalam kasus seperti itu, mengirim seluruh kontrak, arsip log, atau situs dokumentasi dapat meningkatkan biaya tanpa meningkatkan akurasi.
Gunakan retrieval ketika:
- Jawaban harus mengutip sejumlah kecil bagian.
- Sebagian besar korpus tidak relevan dengan pertanyaan pengguna.
- Korpus yang sama ditanyakan berulang kali oleh banyak pengguna.
- Anda perlu membatasi eksposur data berdasarkan tenant, project, tim, atau izin.
- Biaya input konteks penuh akan mendominasi nilai jawaban.
Context window routing seharusnya mengirim permintaan melalui retrieval terlebih dahulu, lalu meneruskan hanya chunk yang dipilih, metadata, dan instruksi ke model. Catat source ID yang diambil, jumlah token, dan hasil penerimaan jawaban. Jika jawaban gagal karena terlalu banyak konteks yang hilang, naikkan workflow itu ke route konteks yang lebih besar dan catat alasannya.
Saat konteks panjang mengalahkan retrieval
Konteks panjang lebih kuat ketika tugas membutuhkan perbandingan yang luas. Contohnya termasuk meninjau satu set kebijakan lengkap untuk mencari kontradiksi, menganalisis transkrip lengkap, membandingkan bagian-bagian di seluruh kontrak besar, atau menggunakan seluruh repositori sebagai set referensi untuk tugas perencanaan.
Gunakan route konteks panjang ketika:
- Tugas bergantung pada hubungan antarbanyak bagian yang berjauhan.
- Model memerlukan struktur seluruh dokumen, bukan hanya bagian-bagian terisolasi.
- Kualitas retrieval sulit diverifikasi sebelum generasi.
- Sumbernya adalah satu artefak terbatas, seperti satu PDF, satu transkrip, atau satu bundle kode.
- Nilai jawaban yang diharapkan membenarkan biaya input yang lebih besar.
Bahkan begitu, context window routing tidak boleh melewati pemeriksaan biaya. Ukur token input penuh, token yang di-cache jika tersedia, token output, latensi, tingkat retry, dan tingkat jawaban yang diterima. Kebijakan routing harus membuktikan bahwa route konteks panjang lebih baik daripada retrieval, bukan hanya lebih mudah diimplementasikan.
Prompt caching termasuk dalam keputusan route
Prompt caching dapat mengubah ekonomi prompt panjang yang berulang. Dokumentasi prompt caching OpenAI menjelaskan bahwa prompt panjang yang memenuhi syarat dapat memperoleh manfaat ketika konten statis muncul terlebih dahulu dan konten variabel muncul kemudian; dokumentasi itu juga menampilkan cached_tokens dalam detail penggunaan sehingga tim dapat memantau perilaku cache.
Context window routing harus memperlakukan cacheability sebagai sinyal kelas utama:
| Pola prompt | Implikasi routing |
|---|---|
| Kebijakan sistem yang stabil ditambah banyak pertanyaan pengguna | Letakkan konten stabil di depan dan ukur porsi cached-token |
| Bundle dokumentasi besar yang berulang | Pertimbangkan route konteks panjang yang sadar cache |
| Data spesifik pengguna yang sangat dinamis | Jangan berasumsi ada penghematan cache |
| Definisi tool bersama di banyak panggilan | Jaga skema tool tetap stabil bila memungkinkan |
| Prompt pendek di bawah ambang cache | Optimalkan route/model terlebih dahulu; caching mungkin tidak membantu |
Token yang di-cache dapat menurunkan biaya atau latensi bergantung pada perilaku penyedia, tetapi itu tidak menjadikan context window tak terbatas. Dokumentasi Anthropic menjelaskan perbedaan penting ini secara langsung: prefiks prompt yang di-cache tetap dapat mengisi context window. Kebijakan routing harus mencatat cache hit sebagai bukti biaya, bukan sebagai izin untuk mengabaikan batas token.
Sisihkan ruang output, reasoning, dan tool
Context window routing sering gagal karena tim hanya menghitung token input. Model tetap membutuhkan ruang untuk menjawab.
Untuk setiap route, tentukan:
- Token input maksimum: permintaan terbesar yang boleh diterima route.
- Token output yang disisihkan: ruang untuk jawaban yang terlihat, JSON, sitasi, atau argumen tool.
- Token reasoning yang disisihkan: ruang tambahan untuk model reasoning atau tugas yang sulit.
- Overhead tool: definisi tool, panggilan tool, dan hasil tool.
- Margin keamanan: buffer untuk variansi tokenizer dan pertumbuhan prompt.
Gunakan guard route seperti ini:
route: contract_review_long_context
max_context_window_tokens: provider_model_limit
max_input_tokens: 180000
reserved_output_tokens: 12000
reserved_reasoning_tokens: 25000
tool_overhead_tokens: 5000
safety_margin_tokens: 8000
on_over_budget:
first: summarize_or_retrieve
second: ask_for_scope_reduction
blocked: send_anyway
Angka-angka di atas adalah placeholder, bukan batas universal. Bagian yang penting adalah bentuk guardrail-nya: route memiliki plafon input, cadangan jawaban, cadangan reasoning, dan perilaku eksplisit saat melewati anggaran.
Kontrol biaya untuk context window routing
Jangan ukur biaya hanya per token. Ukur biaya per hasil yang diterima.
| Metrik biaya | Mengapa ini penting |
|---|---|
| Biaya per permintaan | Mendeteksi panggilan tunggal yang terlalu besar |
| Biaya per jawaban yang diterima | Memperhitungkan percobaan ulang, retrieval yang buruk, dan panggilan konteks panjang yang gagal |
| Biaya per alur kerja | Menunjukkan biaya sebenarnya dari tiket, tinjauan, ekstraksi, atau laporan |
| Biaya per pemilik | Menghubungkan penggunaan ke aplikasi, tim, pelanggan, atau lingkungan |
| Biaya input yang disesuaikan cache | Memisahkan prefiks stabil yang berulang dari konteks dinamis |
| Biaya fallback | Menunjukkan apakah fallback menyelamatkan keandalan atau menyamarkan rute utama yang buruk |
Templat kebijakan routing jendela konteks
Letakkan aturan dalam format yang dapat ditinjau oleh engineering, finance, dan procurement.
policy_name: context_window_routing_v1
owner:
team: ai_platform
approvers:
- engineering
- finance
workflow_classes:
short_task:
max_input_tokens: 8000
route: efficient_text_route
fallback: retry_same_route_once
normal_chat:
max_input_tokens: 32000
route: balanced_tool_route
fallback: reviewed_balanced_backup
long_document_review:
max_input_tokens: 180000
route: long_context_route
fallback: summarize_then_retry
huge_corpus_question:
route: retrieval_first_route
fallback: scoped_long_context_route
budget_rules:
reserve_output_tokens: required_by_workflow
reserve_reasoning_tokens: required_by_model_class
block_when_over_budget: true
require_cache_metrics_when_prompt_repeats: true
evidence:
required_fields:
- workflow_class
- requested_model
- served_model
- endpoint_family
- input_tokens
- cached_tokens
- output_tokens
- reasoning_tokens
- route_decision
- fallback_reason
- owner_key
- cost_or_balance_impact
acceptance_tests:
max_incomplete_rate: agreed_threshold
max_over_budget_rate: zero_for_production
min_answer_acceptance_rate: workflow_eval_threshold
finance_reconciliation_sample: required
Templat ini membuat routing jendela konteks dapat diuji. Jika rutenya berubah, pemiliknya bisa melihat alasannya. Jika prompt membesar, guardrail dapat memblokirnya. Jika permintaan berulang, metrik cache menjadi bagian dari peninjauan.
Pengujian penerimaan sebelum produksi
Jalankan pengujian ini sebelum Anda membiarkan routing jendela konteks menangani traffic produksi:
- Kirim prompt pendek dan pastikan ia tetap tidak menggunakan rute konteks panjang.
- Kirim prompt chat normal dengan tools dan pastikan definisi serta hasil tool dihitung.
- Kirim prompt dokumen panjang dan verifikasi ruang output yang dicadangkan tetap tersedia.
- Kirim prompt yang melebihi anggaran dan pastikan rute merangkum, melakukan retrieval, atau meminta pengurangan cakupan alih-alih mengirim secara membabi buta.
- Picu tugas yang berat pada reasoning dan periksa penanganan respons tidak lengkap.
- Ulangi prompt panjang yang stabil dan pastikan metrik token cache dicatat ketika penyedia mengeksposnya.
- Bandingkan jawaban retrieval-first dan full-context pada set evaluasi yang sama.
- Tinjau model yang diminta, model yang disajikan, keluarga endpoint, unit penggunaan, alasan fallback, serta dampak biaya atau saldo dalam log.
Untuk arsitektur yang lebih luas, padukan pemeriksaan ini dengan panduan Flatkey tentang AI API gateway, arsitektur LLM API gateway, load balancing dan failover AI API, dan desain kebijakan routing model.
Di mana Flatkey berperan
Flatkey seharusnya bukan satu-satunya tempat kebijakan itu berada. Seharusnya menjadi tempat di mana tim dapat membuat kebijakan lebih mudah dijalankan dan ditinjau.
Gunakan Flatkey untuk memusatkan akses model, peninjauan rute, pemeriksaan harga terkini, visibilitas penggunaan, kuota, log permintaan, dan peninjauan penagihan. Lalu simpan kebijakan context window routing di kode atau konfigurasi agar keputusan rute dapat diulang. Gateway memberi finance dan operations tempat yang lebih jelas untuk memeriksa penggunaan; kebijakan memberi engineering tahu rute apa yang diizinkan.
Uji coba pembuktian Flatkey yang praktis terlihat seperti ini:
- Pilih satu alur kerja dengan rentang ukuran prompt yang diketahui.
- Periksa model dan opsi endpoint saat ini di Flatkey pricing.
- Jalankan prompt pendek, normal, panjang, melebihi anggaran, dan yang berulang serta dapat di-cache.
- Tinjau log permintaan untuk keputusan rute, model yang dilayani, penggunaan, kolom cache jika tersedia, alasan fallback, dan key pemilik.
- Konfirmasikan perilaku kuota dan peninjauan biaya dengan pemilik alur kerja.
- Pindahkan hanya rute yang telah diuji ke produksi, lalu perluas context window routing baris demi baris.
Ketika pembuktian berhasil, dapatkan key dan jaga peluncuran awal tetap sempit. Tujuan context window routing bukan menambah kompleksitas; tujuannya adalah menghentikan pertumbuhan prompt agar tidak diam-diam berubah menjadi biaya yang membengkak, jawaban yang tidak lengkap, dan pilihan model yang tidak dapat ditinjau.
FAQ
Apa itu context window routing?
Context window routing adalah kebijakan yang memilih rute model, jalur retrieval, jalur compaction, atau perilaku penolakan berdasarkan ukuran prompt, output reserve, reasoning reserve, overhead alat, kontrol biaya, dan bukti yang diperlukan.
Apa perbedaan context window routing dengan model routing?
Model routing dapat memilih berdasarkan kualitas, harga, latensi, modalitas, wilayah, atau penyedia. Context window routing berfokus pada apakah permintaan muat dalam anggaran konteks yang dapat digunakan dan apakah rute yang lebih kecil, retrieval-first, cached, atau long-context adalah pilihan pengendalian biaya yang tepat.
Kapan tim sebaiknya menggunakan retrieval вместо model long-context?
Gunakan retrieval ketika jawaban bergantung pada sebagian kecil dari korpus besar, ketika izin akses penting, atau ketika input konteks penuh yang berulang akan mahal. Gunakan long context ketika tugas memerlukan perbandingan luas di banyak bagian sumber yang berjauhan.
Mengapa menyisihkan token output dan reasoning?
Sebuah prompt bisa muat di sisi input dari jendela konteks tetapi tetap gagal karena tidak ada cukup ruang tersisa untuk reasoning atau jawaban yang terlihat. Menyisihkan token output dan reasoning mengurangi respons yang tidak lengkap dan pemborosan biaya.
Apakah prompt caching menghilangkan kebutuhan akan context window routing?
Tidak. Prompt caching dapat mengurangi latensi atau biaya input untuk prefiks yang berulang, tetapi token yang di-cache tetap harus dipertimbangkan dalam jendela konteks. Context window routing harus mencatat metrik token cached sambil tetap memberlakukan batas anggaran.
Bagaimana Flatkey membantu dengan context window routing?
Flatkey memberi tim satu permukaan gateway untuk akses model, peninjauan rute, pemeriksaan harga, analitik penggunaan, log permintaan, kuota, dan peninjauan penagihan. Itu memudahkan validasi apakah context window routing mengendalikan ukuran prompt dan biaya sesuai desain.
