Fase 7 · Observability, Biaya & Evaluasi

AWS X-Ray

X-Ray menjahit satu permintaan yang melewati banyak layanan jadi satu jejak. Untuk aplikasi RAG yang menyentuh knowledge base, model, dan beberapa Lambda, ini satu-satunya cara melihat gambaran utuh.

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

Intisari

Satu trace = satu permintaan; segment per layanan; subsegment per operasi.
Service map menggambarkan hubungan antar komponen beserta latensi dan tingkat errornya.
Untuk Lambda cukup aktifkan active tracing; SDK boto3 bisa di-patch otomatis.
Annotation terindeks dan bisa dicari; metadata tidak.
Sampling mengurangi biaya — kamu tidak perlu melacak setiap permintaan.

Yang terlihat

Trace: tanya-kebijakan-cuti           total 4.820 ms
├─ API Gateway                          12 ms
└─ Lambda tanya-bedrock              4.795 ms
   ├─ Init (cold start)                380 ms
   ├─ bedrock-agent-runtime: Retrieve  620 ms
   ├─ dynamodb: GetItem                 18 ms
   └─ bedrock-runtime: Converse      3.740 ms   ← di sinilah waktunya habis

Tanpa tracing, yang kamu tahu cuma "permintaan itu 4,8 detik". Dengan tracing, kamu tahu retrieval cepat dan model yang lambat — dan itu mengarahkan optimasi ke tempat yang benar (model lebih kecil, prompt lebih pendek, streaming) alih-alih ke tempat yang salah (menyetel vector store).

Mengaktifkan

lambda_.Function(
    self, "FungsiTanya",
    tracing=lambda_.Tracing.ACTIVE,          # itu saja untuk Lambda
    ...
)

from aws_xray_sdk.core import xray_recorder, patch_all

patch_all()          # semua panggilan boto3 otomatis jadi subsegment


@xray_recorder.capture("susun_konteks")
def susun_konteks(potongan):
    ...

Annotation vs metadata

segmen = xray_recorder.current_segment()

# Annotation: TERINDEKS — bisa dicari dan difilter
segmen.put_annotation("model", MODEL_ID)
segmen.put_annotation("tenant", tenant)
segmen.put_annotation("guardrail_intervensi", diblokir)

# Metadata: TIDAK terindeks — untuk konteks saat trace dibuka
segmen.put_metadata("potongan_terambil", [p["location"] for p in potongan])

Perbedaan ini menentukan apakah tracing-mu berguna. Hanya annotation yang bisa dipakai untuk memfilter, misalnya "tampilkan semua trace lambat untuk tenant X yang memakai model Y". Jumlah annotation per trace terbatas, jadi pilih yang benar-benar kamu pakai untuk mencari — sisanya jadikan metadata.

Sampling

Aturan	Masuk akal untuk
Beberapa permintaan per detik + persentase kecil sisanya	Default yang wajar
100% untuk jalur error	Yang gagal justru yang paling ingin kamu lihat
100% untuk satu tenant	Saat menyelidiki keluhan spesifik
Persentase kecil untuk jalur normal	Menekan biaya tanpa kehilangan gambaran

Yang khas untuk aplikasi LLM

Pertanyaan	Terjawab oleh
Retrieval atau generasi yang lambat?	Perbandingan subsegment
Berapa besar dampak cold start?	Segment Init
Berapa lama loop tool berjalan?	Beberapa subsegment Converse berurutan
Apakah guardrail menambah latensi berarti?	Selisih dengan dan tanpa guardrail
Tenant mana yang paling lambat?	Filter berdasarkan annotation

Baris ketiga penting untuk agent: loop tool use menghasilkan beberapa pemanggilan model berurutan, dan jejaknya memperlihatkan berapa giliran yang benar-benar terjadi. Agent yang diam-diam memakai lima giliran padahal seharusnya dua akan terlihat langsung di sini — sesuatu yang sulit dilihat dari log saja.

Latihan: aktifkan active tracing pada Lambda-mu, patch_all() boto3, dan tambahkan annotation untuk model serta jumlah potongan yang terambil. Jalankan sepuluh permintaan, buka service map, dan jawab dengan angka: berapa persen waktu habis di retrieval dan berapa persen di model?

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