Bingung membuat portofolio AI engineer? Ini 10 ide proyek LLM dan RAG dari pemula sampai lanjut, lengkap dengan apa yang dibuktikan dan template README.
Anda sudah belajar backend, mencoba memanggil API model bahasa, dan paham konsep RAG. Sekarang pertanyaannya: proyek apa yang layak masuk portofolio? Banyak calon AI engineer berhenti di sini, lalu membuat “chatbot serbabisa” yang mirip milik ratusan orang lain. Hasilnya portofolio yang tampak ramai tetapi tidak membuktikan apa-apa.
Artikel ini memberi 10 ide proyek berbasis LLM API dan RAG, dikelompokkan dari pemula sampai lanjut. Untuk tiap ide, kami jelaskan masalah yang diselesaikan, apa yang dibuktikan kepada perekrut, dan tantangan yang membuatnya layak dipamerkan. Di bagian akhir ada template README, urutan pengerjaan, dan kesalahan yang sebaiknya dihindari.
Portofolio AI Engineer: Yang Sebenarnya Perlu Dibuktikan
Perekrut teknis jarang terkesan oleh kemampuan “memanggil API model”. Itu bisa dilakukan siapa saja dalam sepuluh menit. Yang membuat seorang calon AI engineer berbeda adalah bukti bahwa ia bisa membawa fitur AI dari ide sampai layak dipakai. Ini pendapat kami berdasarkan bagaimana pekerjaan itu sendiri tersusun, bukan hasil survei perekrut. Sebuah proyek yang baik menunjukkan lima hal:
Kemampuan
Bagaimana membuktikannya di proyek
Rekayasa backend
API yang rapi, penanganan error, batas waktu, dan pencatatan (log)
Keluaran terstruktur dan validasi, bukan teks bebas yang dipercaya begitu saja
Pengukuran kualitas
Dataset uji dan hasil evaluasi sebelum dan sesudah perbaikan
Kesadaran biaya dan risiko
Catatan biaya per permintaan dan penanganan masukan yang berbahaya
Kalau Anda tertarik pada proyek yang bersifat agen (AI yang mengambil keputusan dan memakai alat), panduannya sudah ada di artikel portofolio programmer dengan proyek AI agent. Artikel ini melengkapinya dengan proyek yang lebih dasar dan lebih mudah diukur, yang justru sering menjadi pondasi sebelum membuat agen.
10 Ide Proyek Portofolio
Level pemula
1
Pengklasifikasi Tiket Pelanggan
Masalah: keluhan pelanggan masuk sebagai teks bebas dan harus diarahkan ke tim yang tepat.
Yang dibuktikan: keluaran terstruktur dengan kategori tertutup, validasi, dan percobaan ulang. Pola desainnya ada di structured output LLM.
Tantangan yang membuatnya menarik: tambahkan kasus jebakan dan laporkan berapa persen jawaban yang valid dan yang benar.
2
Ekstraktor Data dari Dokumen
Masalah: faktur, surat, atau formulir berisi data penting yang harus diketik ulang.
Yang dibuktikan: membaca teks dokumen, mengubahnya menjadi JSON, dan memeriksa konsistensi (misalnya total sama dengan jumlah baris). Dasar pemanggilan modelnya ada di panduan Gemini API dengan Python.
Tantangan: tangani kolom yang tidak ada dengan nilai kosong, bukan karangan.
Yang dibuktikan: klasifikasi sentimen dan topik dalam batch, agregasi ke dasbor sederhana, dan ringkasan mingguan.
Tantangan: bandingkan hasil model dengan label manual pada sampel, lalu laporkan kesesuaiannya.
7
Dasbor Evaluasi Versi Prompt
Masalah: tim mengubah prompt tetapi tidak tahu apakah hasilnya lebih baik.
Yang dibuktikan: harness evaluasi yang menyimpan skor per versi dan per jenis kasus, seperti dibahas di evaluasi LLM.
Tantangan: tampilkan kasus di mana rata-rata naik tetapi satu kategori memburuk.
Level lanjut
8
Gateway AI Kecil dengan Catatan Biaya
Masalah: beberapa fitur memanggil model tanpa kendali dan tagihan sulit dilacak.
Yang dibuktikan: satu pintu masuk yang mencatat token dan biaya, memberi batas per pengguna, dan menyimpan hasil yang berulang. Perhitungannya mengacu pada biaya token LLM API.
Tantangan: tunjukkan penghematan terukur setelah pembatasan dan penyimpanan hasil diterapkan.
9
Asisten SQL Baca-Saja dengan Pagar Pengaman
Masalah: non-teknis ingin bertanya ke database dengan bahasa biasa.
Yang dibuktikan: model menyusun query, sistem memvalidasinya (hanya SELECT, tabel yang diizinkan, batas baris) sebelum dijalankan.
Tantangan: uji dengan masukan yang mencoba menyuruh model menghapus data, lalu tunjukkan bahwa pagar Anda menahannya.
10
Pipeline Email ke Tiket dengan Antrean Tinjauan Manusia
Masalah: email masuk campur aduk, dan tidak semua aman diproses otomatis.
Yang dibuktikan: alur end-to-end: ekstraksi, klasifikasi, keputusan otomatis hanya bila yakin, dan sisanya masuk antrean tinjauan.
Tantangan: ukur berapa persen yang bisa diotomatisasi tanpa menurunkan ketepatan.
Urutan Pengerjaan yang Realistis
Anda tidak perlu mengerjakan sepuluh proyek. Tiga proyek yang dikerjakan sampai tuntas lebih meyakinkan daripada sepuluh yang setengah jadi. Berikut kombinasi yang menunjukkan perkembangan kemampuan:
Tahap
Proyek
Fokus pembuktian
Minggu 1-2
Proyek 1 (pengklasifikasi tiket)
Keluaran terstruktur, validasi, evaluasi dasar
Minggu 3-5
Proyek 3 atau 5 (RAG)
Pencarian, database, hak akses, evaluasi pencarian
Minggu 6-8
Proyek 8 atau 10 (sistem utuh)
Biaya, keamanan, jalur cadangan, pemantauan
Jangka waktu di atas hanya panduan kasar. Sesuaikan dengan waktu yang Anda punya, dan jangan mengorbankan mutu demi kecepatan. Jalur belajar yang mendasarinya bisa dilihat di roadmap AI engineering dari backend.
Template README untuk Proyek AI
README sering menjadi satu-satunya bagian yang dibaca perekrut. Susun agar menjawab pertanyaan penting dalam dua menit.
NAMA PROYEK: satu kalimat manfaat, bukan nama teknologi
1. Masalah
Siapa penggunanya dan apa yang sulit bagi mereka?
2. Ringkasan solusi
Diagram alur sederhana + tangkapan layar atau GIF demo.
3. Keputusan teknis
Kenapa memilih model, skema, dan penyimpanan ini? Apa alternatif
yang ditolak dan alasannya?
4. Hasil evaluasi
Jumlah kasus uji, persen valid, persen benar per jenis kasus,
perbandingan versi prompt.
5. Biaya dan kinerja
Rata-rata token dan biaya per permintaan, latensi.
6. Batasan dan risiko
Apa yang belum ditangani? Kasus gagal yang sudah diketahui.
7. Cara menjalankan
Langkah singkat, contoh konfigurasi, tanpa menyertakan kunci API.
Bagian 3, 4, dan 6 yang paling jarang ada di portofolio pemula, dan justru yang paling membedakan Anda. Kejujuran tentang batasan memberi kesan matang, bukan lemah.
Kesalahan Umum pada Portofolio AI
Jangan sertakan data pribadi atau rahasia. Pakai data sintetis atau data publik yang boleh dipakai ulang. Jangan mengunggah dokumen perusahaan, data pelanggan, atau kunci API ke repositori publik.
Pembungkus tipis. Proyek yang hanya meneruskan pertanyaan ke API tanpa validasi, evaluasi, atau penanganan gagal tidak membuktikan banyak hal.
Salinan tutorial tanpa perubahan. Perekrut sering mengenali proyek yang sama persis dengan contoh populer. Ubah kasus penggunaan, data, dan tambahkan evaluasi sendiri.
Tanpa angka. “Chatbot yang akurat” tidak berarti apa-apa. “78 dari 100 kasus uji dijawab benar, dan 9 di antaranya ditolak karena tidak ada di dokumen” jauh lebih kuat.
Terlalu banyak proyek setengah jadi. Pilih sedikit dan tuntaskan.
Tidak ada demo. Sediakan video pendek atau demo daring supaya orang bisa melihat hasilnya tanpa memasang apa pun.
Catatan kritis: portofolio bagus tidak menjamin dapat pekerjaan, dan tidak ada daftar proyek yang otomatis membuat Anda diterima. Portofolio hanya mengurangi keraguan perekrut. Sisanya bergantung pada kebutuhan perusahaan, wawancara, dan persaingan. Gunakan lowongan nyata untuk menyesuaikan pilihan proyek Anda.
Buat satu halaman ringkas per proyek. Masalah, demo, dan tiga angka terpenting di bagian atas.
Tulis satu catatan teknis pendek tentang keputusan terpenting atau kegagalan yang Anda pelajari. Tulisan seperti ini memperlihatkan cara berpikir Anda.
Rapikan repositori. Struktur folder jelas, ada pengujian, dan riwayat perubahan yang bermakna.
Siapkan cerita 2 menit untuk wawancara: masalah, keputusan sulit, hasil, dan apa yang akan diperbaiki.
Perbarui secara berkala. Tambahkan hasil evaluasi baru atau perbaikan agar terlihat bahwa proyek dirawat.
Cocokkan Proyek dengan Lowongan Nyata
Sebelum memilih proyek, kumpulkan beberapa lowongan yang Anda incar dan catat skill yang berulang. Lalu pilih proyek yang paling banyak membuktikan skill itu.
Proyek apa yang cocok untuk portofolio AI engineer pemula?
Mulailah dari proyek yang hasilnya bisa diukur: pengklasifikasi tiket dengan keluaran terstruktur, ekstraktor data dari dokumen, atau tanya-jawab dari satu dokumen kebijakan dengan RAG. Ketiganya kecil, tetapi bisa dilengkapi evaluasi.
Berapa banyak proyek yang sebaiknya ada di portofolio?
Tiga proyek yang tuntas dan terdokumentasi lebih baik daripada sepuluh yang setengah jadi. Pilih yang menunjukkan perkembangan, dari keluaran terstruktur, RAG, sampai sistem utuh dengan biaya dan keamanan.
Apakah harus memakai model tertentu?
Tidak. Yang dinilai adalah cara Anda merancang, mengukur, dan menangani kegagalan, bukan merek model. Tulis kode agar model mudah diganti, dan jelaskan alasan pilihan Anda.
Apakah proyek RAG saja sudah cukup?
RAG adalah topik populer, sehingga banyak portofolio serupa. Pembedanya adalah evaluasi, pemisahan pengukuran pencarian dan jawaban, hak akses, dan catatan biaya. Tambahkan unsur itu supaya proyek Anda menonjol.
Bagaimana cara menunjukkan hasil tanpa membocorkan data?
Gunakan data sintetis atau data publik yang lisensinya membolehkan. Jelaskan asal datanya di README dan jangan pernah mengunggah kunci API atau dokumen perusahaan.
Apakah perlu deploy proyek ke internet?
Sangat membantu tetapi tidak wajib. Demo daring atau video singkat sudah cukup asal orang bisa melihat cara kerjanya. Bila Anda men-deploy, pasang batas penggunaan agar tidak terkena tagihan tak terduga.
Seberapa penting hasil evaluasi di portofolio?
Sangat penting. Angka evaluasi menunjukkan bahwa Anda tidak hanya membuat demo yang tampak bagus, tetapi tahu seberapa sering sistem benar dan di mana ia gagal.
Kesimpulan
Portofolio AI engineer yang kuat bukan kumpulan chatbot, melainkan beberapa proyek kecil yang tuntas dan terbukti: keluaran yang divalidasi, pencarian yang diukur, biaya yang dicatat, dan batasan yang diakui. Sepuluh ide di atas bisa dipilih sesuai level, dan tiga di antaranya sudah cukup untuk menceritakan perkembangan kemampuan Anda.
Wawasan yang sering terlewat: perekrut membaca proyek Anda untuk menilai cara Anda berpikir, bukan sekadar hasil akhirnya. Karena itu bagian keputusan teknis, hasil evaluasi, dan batasan di README bisa lebih berharga daripada fitur tambahan. Pilih tiga proyek, tuntaskan dengan angka dan catatan jujur, lalu sesuaikan dengan lowongan yang Anda incar.
