Fase 3 · Bedrock Dasar

Parameter inferensi

Parameter inferensi mengubah cara model mengambil sampel token berikutnya. Memahaminya membuat pilihan nilai berhenti jadi tebak-tebakan.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~5 menit baca

Intisari

Model menghasilkan distribusi peluang token berikutnya; parameter ini membentuk ulang distribusi itu.
Temperature rendah = lebih deterministik. Tinggi = lebih bervariasi.
Top-K membatasi jumlah kandidat; Top-P membatasi massa peluang kumulatif.
maxTokens memotong panjang keluaran — pengendali biaya paling langsung.
Ubah satu parameter pada satu waktu. Menyetel temperature dan top-p bersamaan membuat efeknya tak terbaca.

Yang sebenarnya terjadi

Untuk setiap posisi, model menghitung peluang untuk setiap token yang mungkin. Contoh dari dokumentasi resminya, untuk prompt "I hear the hoof beats of…":

{ "horses": 0.7, "zebras": 0.2, "unicorns": 0.1 }

Parameter inferensi menentukan bagaimana satu token dipilih dari distribusi itu:

Parameter	Efek nilai rendah	Efek nilai tinggi
Temperature	Distribusi menajam — token berpeluang tinggi makin dominan	Distribusi merata — token tak biasa jadi mungkin
Top-K	Sedikit kandidat (K=2 → hanya "horses", "zebras")	Banyak kandidat
Top-P	P=0,7 → hanya "horses"	P=0,9 → "horses" dan "zebras"

Nilai untuk kasus nyata

Kasus	Temperature	Alasan
Ekstraksi data terstruktur / JSON	0	Kamu ingin hasil yang sama untuk masukan yang sama
Klasifikasi, routing	0 – 0,1	Konsistensi lebih penting dari variasi
Tanya jawab atas dokumen (RAG)	0 – 0,3	Jawaban harus setia pada konteks
Ringkasan	0,2 – 0,5	Sedikit keluwesan bahasa masih membantu
Menulis kreatif, brainstorming	0,7 – 1,0	Variasi memang yang dicari

Temperature 0 bukan jaminan determinisme penuh. Ia sangat mengurangi variasi, tapi implementasi di sisi layanan, pembaruan model, dan perutean lintas region tetap bisa menghasilkan perbedaan. Kalau aplikasimu butuh keluaran yang benar-benar dapat diulang, verifikasi hasilnya — jangan mengandalkan parameter saja.

Di Converse API

resp = runtime.converse(
    modelId=MODEL_ID,
    messages=pesan,
    inferenceConfig={
        "maxTokens": 512,          # batas panjang jawaban — pengendali biaya
        "temperature": 0.2,
        "topP": 0.9,
        "stopSequences": ["\n\nPengguna:"],
    },
    additionalModelRequestFields={"top_k": 50},   # khas model, bukan bagian standar
)

Di mana	Isi
`inferenceConfig`	Parameter yang dipahami semua model: `maxTokens`, `temperature`, `topP`, `stopSequences`
`additionalModelRequestFields`	Parameter khas satu penyedia, mis. `top_k` atau setelan reasoning

`maxTokens` dan biaya

Token keluaran biasanya beberapa kali lebih mahal daripada token masukan. maxTokens karena itu adalah rem biaya paling langsung yang kamu punya — sekaligus rem terhadap jawaban yang bertele-tele.

Tapi jangan lupa memeriksa stopReason. Kalau nilainya max_tokens, jawabanmu terpotong di tengah kalimat. Menyimpannya ke database sebagai jawaban final adalah bug diam yang baru ketahuan dari keluhan pengguna.

if resp["stopReason"] == "max_tokens":
    # Pilih satu: naikkan batas, perpendek konteks, atau minta jawaban lebih ringkas.
    # Jangan diam-diam menyimpannya sebagai jawaban utuh.
    ...

Latihan: jalankan satu prompt kreatif lima kali pada temperature 0 dan lima kali pada temperature 1, lalu bandingkan keragaman jawabannya. Setelah itu setel maxTokens ke 20 untuk pertanyaan yang butuh jawaban panjang, dan pastikan kodemu mendeteksi stopReason == "max_tokens".

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.