AI Engineer dari Nol
Dari "apa itu AI" sampai chatbot RAG yang benar-benar berjalan di production — mencakup cara kerja LLM, tool use, AI agent, koneksi ke database lewat embedding & MCP, retrieval augmented generation, dan arsitektur deploy-nya di AWS.
Roadmap ini ditulis untuk software engineer, bukan ilmuwan data — fokusnya membangun sistem di atas model yang sudah ada lewat API, bukan melatih model dari nol. Kalau kamu sudah bisa ngoding tapi belum pernah menyentuh AI/LLM sama sekali, ini titik mulai yang tepat.
- Durasi
- ~10 minggu
- Beban
- ~6 jam/minggu
- Prasyarat
- Pernah ngoding, paham dasar API/HTTP
- Target akhir
- Chatbot RAG siap production
Untuk siapa roadmap ini
"Dari nol" di sini berarti nol AI/LLM, bukan nol pemrograman. Kamu diasumsikan sudah bisa menulis kode dan paham dasar cara kerja API/HTTP. Roadmap ini tidak mengajarkan matematika di balik model — fokusnya cara memakai model yang sudah jadi (Claude, GPT, dan sejenisnya) lewat API untuk membangun produk software nyata.
Kalau kamu belum pernah ngoding sama sekali, mulai dari Python Dasar untuk Pemula dulu. Kode contoh di roadmap ini memakai Python dan Anthropic SDK sebagai ilustrasi konkret — tapi konsepnya (prompting, tool use, RAG, agent) berlaku sama untuk provider dan bahasa apa pun.
Kenapa Claude sebagai contoh: materi-materi berikutnya memakai dokumentasi resmi Anthropic sebagai sumber utama, plus dokumentasi OpenAI, AWS, dan proyek open source (pgvector, MCP, LangChain) untuk topik lintas-provider seperti embedding dan observability. Ini keputusan praktis, bukan klaim satu provider "lebih benar" — dijelaskan lebih lengkap di Fase 0.
Yang sengaja dilewati
| Topik | Alasan |
|---|---|
| Melatih/fine-tuning model dari nol | Pekerjaan ML engineer/researcher, bukan AI engineer — dibedakan di Fase 0 |
| Matematika di balik transformer | Tidak dibutuhkan untuk memakai model lewat API secara efektif |
| Self-hosting model open-weight (Llama, dsb.) | Fokus roadmap ini memakai API provider terkelola; konsepnya tetap sama kalau kamu pindah ke self-hosted |
| Framework agent pihak ketiga (LangChain, dsb.) secara mendalam | Konsep di baliknya (agentic loop, tool use) diajarkan langsung dari API dasar — memindahkannya ke framework apa pun jadi lebih mudah |
| Computer vision / model multimodal mendalam | Roadmap ini fokus teks — LLM & RAG untuk aplikasi berbasis bahasa |
Bentuk roadmap ini
| Bagian | Fase | Menjawab |
|---|---|---|
| Dasarnya | 0 – 1 | Apa itu AI/LLM, dan cara memanggil API-nya dengan benar |
| Membangun dengan LLM | 2 – 3 | Integrasi ke backend, tool use, dan AI agent |
| Data & pengetahuan | 4 – 5 | Menghubungkan LLM ke data sendiri lewat embedding, vector DB, dan RAG |
| Produk nyata | 6 – 7 | Studi kasus chatbot penuh, sampai deploy ke production |
Urutannya disengaja. Fase 6 (chatbot) baru masuk akal setelah Fase 1-5 selesai — chatbot production adalah gabungan dari prompting, tool use, agent, dan RAG, bukan topik yang berdiri sendiri. Jangan lompat ke Fase 6 atau 7.
Dasar AI & Profesi AI Engineer
Tujuan: paham perbedaan AI/ML/deep learning/LLM, tahu cara kerja dasar LLM (token, training, context window), dan paham posisi profesi AI engineer beserta peta provider model.
Materi
-
Apa itu AI, Machine Learning, dan Deep LearningResmiTiga istilah yang sering dipakai bergantian padahal tidak sama — dan kenapa perbedaannya menentukan alat apa yang kamu pakai untuk masalah apa.aws.amazon.comBaca rangkuman →
-
Apa itu LLM dan bagaimana ia bekerjaResmiToken, prediksi kata berikutnya, dan kenapa model yang sama bisa 'berhalusinasi' dengan penuh percaya diri — dasar yang menjelaskan semua materi setelah ini.docs.claude.comBaca rangkuman →
-
Apa itu AI Engineer, dan peta provider modelArtikelKenapa 'AI engineer' jadi peran tersendiri yang bukan ML engineer maupun software engineer biasa — dan peta cepat provider model yang akan kamu temui.latent.spaceBaca rangkuman →
Kamu bisa menjelaskan beda AI/ML/deep learning/LLM dengan contoh konkret, tahu kenapa LLM bisa "berhalusinasi" dari cara kerjanya, dan bisa menyebutkan tiga sumbu yang dipakai memilih model (kualitas, biaya, latensi).
Interaksi Pertama dengan LLM
Tujuan: bisa memanggil LLM API dengan percaya diri — mengatur prompt & parameter yang tepat, memilih streaming vs non-streaming, dan memaksa output dalam format terstruktur.
Materi
-
Prompting dasar & parameter modelResmiSystem prompt vs user prompt, dan tiga parameter (temperature, max_tokens, top_p) yang menentukan seberapa 'liar' jawaban model.docs.claude.comBaca rangkuman →
-
Panggilan API pertama & streamingResmiKenapa hampir semua chatbot production memakai streaming, dan bagaimana bentuknya di sisi kode — server-sent events, bukan satu respons besar.docs.claude.comBaca rangkuman →
-
Structured output — memaksa model menjawab dalam format tetapResmiAplikasi butuh JSON yang bisa di-parse, bukan prosa. Dua pendekatan untuk memaksanya: minta baik-baik lewat prompt, atau paksa lewat skema.platform.openai.comBaca rangkuman →
Kamu punya skrip Python yang bisa memanggil Claude dengan system prompt & temperature yang disesuaikan tugas, bisa menjelaskan kapan pakai streaming vs tidak, dan bisa mengekstrak data terstruktur yang valid secara andal lewat skema, bukan sekadar minta lewat prompt.
Penerapan AI ke Software Engineering
Tujuan: bisa membuat model memanggil fungsi nyata di kodemu, membangun integrasi backend yang tahan terhadap kegagalan & rate limit, dan tahu cara menguji serta melindungi sistem dari prompt injection.
Ini fase yang mengubah "bisa panggil API" jadi "bisa bangun produk". Tool use adalah fondasi dari AI agent di Fase 3; arsitektur backend yang andal dan guardrails di sini dipakai di seluruh fase setelahnya, termasuk chatbot production di Fase 6.
Materi
-
Tool use / function calling — model yang bisa memanggil kodemuResmiMekanisme yang mengubah LLM dari 'mesin jawab teks' jadi bisa bertindak: cek cuaca, query database, kirim email — lewat fungsi yang kamu tulis sendiri.docs.claude.comBaca rangkuman →
-
Arsitektur integrasi AI di backend — retry, timeout, rate limitResmiPanggilan ke LLM API adalah panggilan jaringan ke layanan pihak ketiga yang lambat, kadang gagal, dan dibatasi kuota — bukan pemanggilan fungsi lokal yang selalu sukses.docs.claude.comBaca rangkuman →
-
Testing, evaluasi & guardrails dasarResmiKode LLM tidak bisa diuji dengan assertEqual biasa — outputnya tidak deterministik. Plus: prompt injection, kebocoran data sensitif, dan pertahanan dasarnya.docs.claude.comBaca rangkuman →
Kamu punya contoh tool use yang benar-benar memanggil fungsi Python-mu, kode pemanggilan API yang menangani rate limit dengan retry+backoff yang tepat, dan kamu bisa mendemonstrasikan sendiri serangan prompt injection sederhana beserta cara bertahan darinya.
AI Agents
Tujuan: bisa membangun agent yang memutuskan sendiri langkah-langkahnya sampai tugas selesai, mengelola riwayat supaya tidak menabrak context window, dan tahu kapan (dan kapan tidak) memecahnya jadi multi-agent.
Materi
-
Apa itu AI agent & agentic loopArtikelBedanya chatbot biasa dengan 'agent' bukan soal seberapa pintar modelnya — tapi apakah model boleh memutuskan sendiri langkah berikutnya, berkali-kali, sampai tugas selesai.anthropic.comBaca rangkuman →
-
Memory & state pada agentResmiAgent yang berjalan lama menghadapi masalah yang sama seperti chatbot: context window terbatas. Bedanya, agent juga harus mengingat hasil tool call sebelumnya, bukan cuma kata-kata.python.langchain.comBaca rangkuman →
-
Multi-agent & orchestrationArtikelSatu agent yang mengerjakan semuanya sendiri bisa 'kehilangan fokus' pada tugas kompleks. Memecahnya jadi beberapa agent khusus adalah pola yang sama seperti memecah monolith jadi service.anthropic.comBaca rangkuman →
Kamu punya agent loop yang berjalan sampai beberapa langkah dengan batas maksimum yang jelas, tahu strategi meringkas riwayat panjang, dan bisa menjelaskan kapan pola orchestrator-worker sepadan dengan biaya token ekstranya — dan kapan satu agent saja sudah cukup.
Koneksi AI, Database & LLM
Tujuan: paham cara teks diubah jadi vektor yang bisa dibandingkan maknanya, bisa menyimpan & mencarinya lewat pgvector di Postgres, dan tahu cara menghubungkan LLM ke sumber data lewat protokol standar MCP.
Materi
-
Embedding & representasi vektorResmiCara komputer 'mengerti' makna teks bukan lewat kata kunci, tapi lewat koordinat di ruang berdimensi ratusan — dan kenapa 'anjing' dan 'kucing' berdekatan di ruang itu.platform.openai.comBaca rangkuman →
-
Vector database & semantic search dengan pgvectorResmiMenyimpan sejuta embedding sebagai list Python tidak akan skalabel. pgvector menambahkan tipe data dan index vektor langsung ke Postgres yang sudah kamu pakai.github.comBaca rangkuman →
-
Menghubungkan LLM ke sumber data lewat MCPResmiTool use di Fase 2 mendefinisikan tool satu-satu secara manual per aplikasi. MCP adalah protokol standar yang membuat tool/data source bisa dipakai ulang lintas aplikasi AI mana pun.modelcontextprotocol.ioBaca rangkuman →
Kamu bisa membuat embedding dari teks, menyimpan & mencarinya dengan cosine similarity di pgvector, dan bisa menjelaskan kapan menulis MCP server sendiri masuk akal dibanding tool use manual.
RAG — Retrieval Augmented Generation
Tujuan: bisa membangun pipeline RAG lengkap dari dokumen mentah sampai jawaban, memahami trade-off ukuran chunk & strategi retrieval, dan bisa mengukur kualitasnya secara objektif — bukan "terasa lebih baik".
Fase ini menyatukan Fase 0 (halusinasi), Fase 2 (guardrails), dan Fase 4 (embedding) jadi satu pola yang paling banyak dicari orang: membuat LLM menjawab berdasarkan dokumen milikmu sendiri, bukan cuma pengetahuan umum dari data latihannya.
Materi
-
Apa itu RAG & pipeline dasarnyaResmiModel tidak tahu apa isi dokumen internal perusahaanmu, dan context window ada batasnya. RAG adalah pola yang membuat model 'membaca' data spesifikmu tanpa harus dilatih ulang.aws.amazon.comBaca rangkuman →
-
Chunking & kualitas retrievalArtikelCara memotong dokumen jadi chunk ternyata menentukan kualitas RAG lebih dari model apa yang dipakai untuk menjawab. Potongan terlalu kecil kehilangan konteks; terlalu besar mengaburkan relevansi.anthropic.comBaca rangkuman →
-
Evaluasi RAGResmiTanpa cara mengukur, kamu tidak akan tahu apakah mengganti ukuran chunk dari 500 ke 300 kata benar-benar memperbaiki sistem atau cuma perasaan. Evaluasi RAG mengubah tebakan jadi angka.docs.claude.comBaca rangkuman →
Kamu punya pipeline RAG yang berjalan dari dokumen mentah sampai jawaban bersumber, paham trade-off ukuran chunk, dan punya dataset evaluasi kecil untuk membandingkan precision/recall retrieval sebelum & sesudah perubahan.
Use Case: Chatbot
Tujuan: menyatukan seluruh fase sebelumnya jadi studi kasus penuh — chatbot dengan riwayat percakapan multi-turn, RAG untuk menjawab dari knowledge base, dan guardrails yang membuatnya aman dihadapkan ke pengguna nyata.
Materi
-
Arsitektur chatbot productionResmiChatbot bukan satu panggilan API — ia sistem yang menyimpan riwayat, mengelola sesi tiap pengguna, dan menyatukan semua konsep dari fase sebelumnya jadi satu produk.docs.claude.comBaca rangkuman →
-
RAG + chatbot — menjawab dari knowledge base sendiriResmiChatbot customer service yang bisa menjawab dari dokumen kebijakan perusahaan, bukan cuma dari pengetahuan umum model — dengan riwayat percakapan multi-turn di atasnya.docs.claude.comBaca rangkuman →
-
Guardrails & UX chatbot productionResmiChatbot yang teknis berfungsi belum tentu siap production — butuh jalan keluar saat model tidak yakin, batas topik yang jelas, dan cara mendeteksi saat pengguna butuh manusia sungguhan.docs.claude.comBaca rangkuman →
Kamu punya chatbot yang menyimpan riwayat di database (bukan variabel di memori), bisa menjawab pertanyaan lanjutan yang bergantung konteks sebelumnya lewat RAG, dan punya jalur fallback/eskalasi yang jelas untuk pertanyaan di luar topik atau percakapan yang berputar tanpa progres.
Deployment ke Production
Tujuan: bisa mengoperasikan aplikasi AI di production — mengukur biaya & performanya, menekan biaya lewat caching & model routing, dan men-deploy arsitekturnya dengan aman di AWS.
Materi
-
Observability aplikasi AI — logging, tracing, metrikResmiLog 'request berhasil, status 200' tidak cukup untuk aplikasi AI. Kamu butuh tahu prompt apa yang dikirim, berapa token terpakai, dan langkah mana yang gagal di tengah agent loop.opentelemetry.ioBaca rangkuman →
-
Cost management — token, caching, model routingResmiBiaya AI app tidak seperti biaya server biasa yang tetap tiap bulan — ia bertambah linear dengan pemakaian, per token, dan bisa meledak tanpa disadari kalau riwayat chatbot dikirim ulang mentah-mentah tiap turn.docs.claude.comBaca rangkuman →
-
Deploy arsitektur produksi ke AWSResmiMenyatukan semua fase jadi satu arsitektur yang benar-benar bisa di-deploy: container, database, secret, dan pipeline CI/CD — materi penutup roadmap ini.docs.aws.amazon.comBaca rangkuman →
Kamu bisa menjelaskan metrik apa yang wajib dipantau untuk aplikasi AI, tahu cara menekan biaya lewat prompt caching & model routing, dan punya gambaran arsitektur deploy lengkap — container, secrets, dan evaluasi sebagai bagian CI/CD.
Rekomendasi best practice
Ringkasan keputusan yang, kalau harus memilih satu jawaban, inilah jawabannya. Konteksnya: aplikasi backend biasa yang menambahkan satu atau lebih fitur berbasis LLM — chatbot, ekstraksi data, atau agent. Setiap baris punya materi yang membahas alasannya.
Tumpukan yang direkomendasikan
| Lapisan | Pilihan | Alasan singkat |
|---|---|---|
| Model utama | Claude Sonnet | Keseimbangan kualitas & biaya untuk sebagian besar tugas |
| Tugas sederhana bervolume tinggi | Claude Haiku (model kecil) | Query rewriting, klasifikasi, deteksi eskalasi — jauh lebih murah |
| Embedding | Voyage AI atau OpenAI | Anthropic tidak punya model embedding sendiri |
| Vector store | pgvector di Postgres yang sudah ada | Satu database, query relasional + vektor sekaligus |
| Riwayat percakapan | Disimpan di database, bukan memori proses | Wajib begitu ada lebih dari satu instance server |
| Format output terstruktur | Skema lewat tool/structured output | Dijamin valid, bukan sekadar "diminta baik-baik" |
| Retry API | Exponential backoff + jitter | 429/529 hampir selalu sementara |
| Observability | OpenTelemetry GenAI conventions | Standar terbuka, bisa dibaca tooling apa pun |
| Compute | ECS Fargate | Beban kerjanya I/O-bound (menunggu API LLM), bukan butuh GPU |
| Rahasia (API key) | AWS Secrets Manager | Sama sensitifnya dengan kredensial database |
| CI/CD | Dataset evaluasi sebagai test suite | Regresi kualitas terdeteksi sebelum deploy, bukan lewat komplain pengguna |
Sepuluh yang paling menentukan
- temperature bukan tombol "lebih pintar". Ia cuma mengatur keacakan pemilihan
token. Untuk tugas yang butuh konsistensi (ekstraksi, klasifikasi), pakai
temperature=0. - Model tidak mengingat apa pun antar panggilan. Setiap "memory" — riwayat chatbot, konteks agent, preferensi pengguna — pada akhirnya cuma soal apa yang kamu masukkan ke context window saat itu.
- Paksa format lewat skema, jangan cuma minta lewat prompt. "Jawab dengan JSON" tidak dijamin; tool/structured output dijamin sesuai skema oleh provider.
- Panggilan LLM adalah panggilan jaringan, bukan fungsi lokal. Latensinya tinggi, bisa gagal, dan dibatasi rate limit — desain retry & timeout sejak awal, bukan setelah insiden pertama.
- Jangan mulai dari agent kalau workflow eksplisit sudah cukup. Agent lebih mahal, lebih sulit didebug, dan hasilnya kurang bisa diprediksi — pakai hanya saat jalur langkahnya memang tidak bisa ditentukan di muka.
- Kualitas RAG ditentukan retrieval, bukan model generasinya. Chunk yang tidak relevan menghasilkan jawaban yang meyakinkan tapi salah, seberapa pun canggih modelnya.
- Perlakukan argumen tool call seperti input pengguna yang tidak dipercaya. Ia berasal dari teks yang bisa dipengaruhi prompt injection — validasi sebelum dieksekusi, terutama untuk tool yang berefek samping.
- Riwayat panjang menabrak dua batas sekaligus: context window dan biaya. Ringkas
atau pangkas secara sengaja, jangan biarkan array
messagestumbuh tanpa batas. - Bangun dataset evaluasi sebelum mengoptimasi, bukan sesudah. Tanpa itu, setiap perubahan prompt/chunking cuma tebak-tebakan yang "terasa lebih baik".
- Pasang budget alert sejak hari pertama. Biaya LLM API bertambah linear dengan pemakaian — tagihan pertama yang mengejutkan hampir selalu berarti tidak ada yang memantaunya sejak awal.
Kesalahan yang paling mahal
| Kesalahan | Akibatnya | Dibahas di |
|---|---|---|
| Riwayat chatbot disimpan di variabel proses, bukan database | Riwayat hilang begitu ada lebih dari satu instance server | Fase 6 |
| Tidak ada batas langkah maksimum pada agent | Agent bisa berputar tanpa akhir, biaya token membengkak | Fase 3 |
| Mengeksekusi argumen tool call sebagai perintah shell/SQL mentah | Prompt injection berubah jadi command/SQL injection sungguhan | Fase 2 |
| Chunk RAG tanpa metadata sumber | Tidak bisa melacak jawaban salah berasal dari dokumen mana | Fase 5, 6 |
Menaikkan temperature untuk "memperbaiki" jawaban yang salah | Hasilnya makin tidak konsisten, bukan makin akurat | Fase 1 |
| API key LLM di environment variable plaintext / ter-commit ke git | Kuota & biaya bisa disalahgunakan siapa pun yang menemukannya | Fase 7 |
| Tidak ada dataset evaluasi tetap | Perubahan prompt/chunking tidak bisa dibandingkan objektif sebelum-sesudah | Fase 5 |
| Container di-shutdown paksa saat sedang streaming jawaban | Jawaban ke pengguna terpotong di tengah kalimat | Fase 7 |
Satu hal yang tidak akan diselesaikan tooling apa pun: LLM tetap probabilistik. Guardrails, evaluasi, dan observability mengurangi risiko dan membuatnya terukur — bukan menghilangkan sifat dasar ini sepenuhnya. Rancang sistemmu dengan asumsi model akan salah sesekali, bukan berasumsi ia selalu benar.
Aturan main
- Bangun, jangan cuma baca. Hampir semua materi di sini punya latihan konkret di akhirnya — butuh API key sungguhan untuk sebagian besar, dan itu yang membuatnya melekat.
- Ukur sebelum dan sesudah. Klaim soal kualitas retrieval, biaya, atau latensi di roadmap ini bisa kamu buktikan sendiri dengan dataset kecil — lakukan.
- Satu perubahan pada satu waktu. Mengganti model dan mengganti strategi chunking bersamaan membuat hasilnya tidak bisa dibaca.
- Jangan lompat ke Fase 6 atau 7. Chatbot production adalah gabungan semua fase sebelumnya — melewatkannya berarti menambal masalah yang sebenarnya sudah dibahas.
- Pantau tagihan API-mu selama belajar. Pasang budget alert di dashboard provider sebelum menjalankan latihan yang memanggil API berkali-kali.
- Tulis dataset uji untuk setiap perubahan prompt. Sebelum mengoptimasi, bukan sesudah menebak-nebak.
Sebelum & sesudah ini
Roadmap ini mengandaikan kamu sudah bisa ngoding tapi belum pernah menyentuh AI/LLM. Kalau belum pernah ngoding sama sekali, mulai dari Python Dasar untuk Pemula. Kalau kamu ingin memperdalam sisi Python untuk AI engineering — idiom, async, FastAPI — Python untuk AI Engineer membahasnya lebih detail. Dan kalau kamu ingin mendalami sisi AWS/Bedrock-nya lebih jauh — Knowledge Bases, Guardrails, evaluasi model — AWS untuk AI Engineer menempuh jalur yang paralel dengan sudut pandang AWS.