Merancang produk AI yang benar-benar dipakai: UX khusus AI (streaming, citations, feedback), evaluasi end-to-end retrieval + jawaban, serta metrik produk seperti retention dan helpfulness. Episode ini juga memandu menyusun evaluation set dan scorecard untuk fitur AI.

Selama 21 episode, fokusnya adalah engineering — model, pipeline, keamanan, biaya. Episode ini menggeser lensa ke apa yang sebenarnya menentukan sukses produk: apakah pengguna mau memakainya? Sebuah RAG yang sempurna secara teknis tetap gagal jika pengguna tidak percaya, tidak mengerti, atau tidak merasa terbantu.
Mengapa penting? Karena AI memperkenalkan pola interaksi baru yang tidak dimiliki aplikasi biasa: jawaban bisa salah tanpa error, hasil datang bertahap (streaming), dan pengguna butuh alasan untuk percaya (citations). Produk AI yang bagus adalah yang merancang semua itu secara eksplisit — lalu mengukurnya dengan metrik yang tepat.
Sudah kita bangun teknisnya di episode 5. Alasan UX-nya: menunggu 15 detik layar kosong adalah pengalaman terburuk; streaming membuat pengguna melihat proses berpikir berjalan. Standar 2026: token pertama dalam 1-3 detik.
Aplikasi AI yang memakai RAG harus menunjukkan dari mana jawaban berasal. Ini bukan fitur bonus — ini dasar kepercayaan. Pengguna yang ragu bisa memverifikasi; developer bisa menelusuri kesalahan.
"use client"
type AnswerProps = {
text: string
sources: { id: string; title: string; url: string }[]
}
export function Answer({ text, sources }: AnswerProps) {
return (
<div>
<p>{text}</p>
{sources.length > 0 && (
<ul>
{sources.map((s) => (
<li key={s.id}>
<a href={s.url} target="_blank" rel="noreferrer">
{s.title}
</a>
</li>
))}
</ul>
)}
</div>
)
}Setiap jawaban harus punya tombol "membantu / tidak membantu" — bukan sekadar dekorasi. Ini adalah sumber data evaluasi termurah dan paling representatif (mengisi dataset episode 15):
"use client"
export function Feedback({ messageId }: { messageId: string }) {
async function send(value: string) {
await fetch("/api/feedback", {
method: "POST",
body: JSON.stringify({ messageId, value }),
})
}
return (
<div>
<button onClick={() => send("helpful")}>Membantu</button>
<button onClick={() => send("not_helpful")}>Tidak membantu</button>
</div>
)
}Feedback negatif harus memicu alasan ("jawaban tidak sesuai / informasi salah / tidak ada sumber") agar bisa ditindaklanjuti ke root cause (retrieval? prompt? model?).
Di episode 7-8 dan 15 kita mengevaluasi retrieval dan jawaban secara terpisah. Di produk, yang penting adalah evaluasi end-to-end: dari pertanyaan pengguna sampai jawaban yang ditampilkan. Satu failure point di mana pun (retrieval, prompt, model) berarti pengalaman buruk.
def eval_end_to_end(dataset):
results = []
for item in dataset:
answer = run_app(item["question"]) # aplikasi asli
verdict = judge_pipeline(
question=item["question"],
answer=answer["text"],
retrieved=answer["sources"], # audit retrieval juga
expected=item["expected"],
)
results.append({
"question": item["question"],
"answer": answer["text"],
"sources_ok": verdict["sources_ok"], # retrieval benar?
"answer_ok": verdict["answer_ok"], # jawaban benar?
"score": verdict["score"],
})
return resultsSkor end-to-end inilah yang menjadi KPI teknis fitur AI — bukan sekadar skor RAGAS (episode 15), tapi "berapa persen pertanyaan nyata menghasilkan jawaban bagus dengan sumber tepat".
| Metrik | Mengukur | Target Arah |
|---|---|---|
| Time-to-first-token | Kecepatan persepsi | ↓ |
| Answer helpfulness | Kualitas jawaban | ↑ |
| Citation click-through | Kepercayaan pengguna | ↑ (idealnya sedang-tinggi) |
| Retry / rephrase rate | Kesulitan pengguna mendapat jawaban | ↓ |
| Cost per helpful answer | Efisiensi bisnis | ↓ |
Seperti produk biasa punya acceptance criteria, fitur AI butuh scorecard. Cara menyusunnya:
feature: support-rag-qa
thresholds:
helpfulness: 0.75
faithfulness: 0.85
time_to_first_token: 3s
segments:
- name: faq
sample_size: 60
must_pass: 0.9
- name: complex-context
sample_size: 40
must_pass: 0.7
- name: edge-cases
sample_size: 20
must_pass: 0.5Scorecard ini juga jadi bahasa bersama antara engineer, product, dan bisnis — angka yang sama dipakai untuk memutuskan rilis.
Tip
Metrik terpenting untuk memulai: helpfulness rate (dari feedback) + containment rate (untuk support). Keduanya murah diukur, langsung mencerminkan kualitas end-to-end, dan diterima tim bisnis. Mulai dari dua itu, tambahkan sisanya seiring kebutuhan.
Inti yang harus dibawa pulang:
Di episode 23 selanjutnya kita akan memetakan Ekosistem & Tren 2026 — model (GPT-5.x, Claude 4.x, Gemini 2.x, Llama 4, Qwen3, DeepSeek-R1+), frameworks (LangChain, LlamaIndex, Dify, Flowise), serving (vLLM, Ollama, TGI), platform (Hugging Face, OpenRouter), plus build vs buy. Sampai jumpa di episode 23!