Lewati ke konten

AI & Data

AI engineer

AI engineer membangun produk yang komponen terpentingnya adalah model yang tidak mereka latih sendiri. Pekerjaannya adalah retrieval dan grounding, desain context, evaluation harness, guardrail, serta menjaga latensi dan pengeluaran tetap di dalam anggaran sementara model di bawahnya terus berubah. Panduan ini menguraikan cakupan perannya, kapan peran ini benar-benar tepat, dan bagaimana pekerjaannya menyatu dengan tim produk.

Diskusikan kebutuhan AndaCara kerja penambahan kapasitas tim

Apa yang dikerjakan seorang AI engineer?

AI engineer membangun produk perangkat lunak yang perilakunya bergantung pada sebuah foundation model — biasanya large language model yang diakses lewat API penyedia atau dijalankan sebagai model open-weight yang di-hosting sendiri. Cakupannya meliputi mengambil context yang tepat dan menambatkan output padanya, merancang dan memberi versi pada instruksi yang dikirim ke model, membangun evaluation harness yang memperlihatkan apakah sebuah perubahan benar-benar memperbaiki sesuatu, memasang guardrail terhadap respons yang dimanipulasi atau tidak aman, serta mengendalikan waktu respons dan pengeluaran begitu trafik sungguhan datang. Ini software engineering yang diterapkan pada komponen yang bersifat probabilistik alih-alih deterministik, dan jarang melibatkan pelatihan model.

Yang menentukan peran ini adalah adanya dependency yang tidak sepenuhnya bisa diperiksa engineer-nya. Model punya versi, harga, rate limit, dan sekumpulan perilaku yang bergeser ketika penyedianya merilis pembaruan. Karena itu hampir seluruh upaya engineering tercurah pada apa yang mengelilinginya: apa yang diletakkan di dalam context window, apa yang dilakukan terhadap hasil yang kembali, apa yang dilakukan sistem ketika responsnya keliru, dan dari mana semua itu bisa diketahui.

Pengukuran adalah tempat kesulitannya menumpuk. Demo mudah dirakit, karena sekumpulan input yang dikurasi akan membuat hampir semua konfigurasi tampak kompeten. Membuktikan bahwa versi kedua lebih baik daripada versi pertama jauh lebih sulit, karena dua respons bisa sepenuhnya berbeda kata-katanya namun sama-sama benar, atau nyaris identik namun berbeda pada satu fakta yang justru menentukan. Regression set, rubrik penilaian, judge otomatis yang dikalibrasi terhadap label manusia, dan skor terpisah untuk retrieval dan generation adalah instrumen yang biasa dipakai, dan tim yang tidak memilikinya sedang merilis berdasarkan kesan.

Ragam kegagalannya berbeda dari perangkat lunak konvensional. Pernyataan muncul tanpa dukungan dari sumber mana pun. Retrieval mengembalikan paragraf yang terbaca relevan padahal bukan. Instruksi menyusup ke model di dalam konten yang dikirim pengguna. Kualitas melorot setelah perubahan di sisi penyedia yang tidak menghasilkan error dan tidak memicu alert satu pun. Biaya membengkak seiring panjang percakapan dengan cara yang tidak muncul dalam load test. Masing-masing entah dirancang lebih dulu, atau ditemukan oleh pelanggan.

Menilai kebutuhan

Kapan tim membutuhkan kapabilitas ini

Fitur berbasis foundation model biasanya bermula dari sesuatu yang dirakit seseorang dalam satu akhir pekan, dan versi akhir pekan itu memang mengesankan. Jarak antara versi tersebut dan sesuatu yang bisa diandalkan pelanggan adalah tempat peran ini membuktikan nilainya.

  • Sebuah prototipe harus menjadi produk

    Demonya menangani input yang memang menjadi acuan pembuatannya dan melempem pada segala hal lain. Membuatnya bisa diandalkan berarti membatasi ruang input, memutuskan apa yang terjadi di luar batas itu, dan menaruh angka pada kualitas yang tetap bertahan ketika ada yang menyanggahnya.

  • Jawaban harus bertumpu pada materi milik Anda sendiri

    Respons harus berasal dari dokumen internal, tiket, kontrak, atau data produk, bukan dari apa pun yang diserap model selama pelatihan. Itu membawa serta strategi chunking, pemilihan embedding, hybrid search, reranking, kesegaran data, dan keharusan bahwa seorang pengguna tidak pernah menarik dokumen yang tidak berhak ia baca.

  • Tidak ada yang bisa memastikan sistemnya membaik atau tidak

    Perubahan dirilis karena terasa lebih baik pada segelintir pemeriksaan manual. Ini keadaan yang paling umum pada fitur foundation model di production, dan itu membuat setiap keputusan berikutnya menjadi tebakan, termasuk keputusan apakah fitur itu layak dipertahankan.

  • Teks yang tidak tepercaya masuk ke model

    File yang diunggah, email masuk, pesan pelanggan, halaman hasil scraping. Begitu konten yang diambil bisa membawa instruksi, pertanyaannya berhenti menjadi apa yang diperintahkan kepada model dan berubah menjadi apa yang diizinkan untuk model lakukan.

  • Pengeluaran naik lebih cepat daripada pemakaian

    Retry, riwayat percakapan yang terus bertambah, context yang kebesaran, tidak ada caching, dan setiap request diarahkan ke model terbesar yang tersedia. Kurva biaya sebuah fitur probabilistik bukan kurva biaya yang biasa diproyeksikan tim.

  • Penyedia mendeprecate versi yang menjadi fondasi Anda

    Tenggat migrasi tiba untuk sebuah komponen yang perilakunya tidak dispesifikasikan di mana pun. Tanpa regression suite, satu-satunya cara mengetahui apa yang berubah pada versi baru adalah dengan merilisnya.

Disiplinnya

Kapabilitas inti

  • Desain retrieval

    Batas chunk, pemilihan embedding, hybrid search yang menggabungkan leksikal dan vektor, reranking, dan penyaringan berbasis metadata. Sebagian besar laporan yang dibuka dengan kalimat modelnya salah sebenarnya adalah kegagalan retrieval, dan memisahkan keduanya adalah langkah diagnosis yang pertama.

  • Grounding dan atribusi

    Membuat sebuah jawaban bisa ditelusuri ke paragraf yang mendukungnya, dan merancang apa yang terjadi ketika tidak ada paragraf yang mendukungnya. Sistem yang menolak menjawab umumnya lebih berharga daripada sistem yang berimprovisasi, dan perilaku itu harus dibangun, bukan sekadar diminta.

  • Penyusunan context

    Memutuskan apa yang menempati jendela yang terbatas: instruksi, bukti hasil retrieval, riwayat percakapan, hasil pemanggilan tool, skema output. Merumuskan kalimat instruksi adalah bagian yang terlihat; menganggarkan dan mengurutkan isi jendelanya adalah bagian yang substansial.

  • Evaluation harness

    Kumpulan kasus terkurasi yang mencerminkan input sesungguhnya, rubrik yang akan dinilai sama oleh orang kedua, judge otomatis yang diperiksa terhadap label manusia, dan sebuah regression run yang berdiri di antara perubahan prompt dan sebuah rilis.

  • Penggunaan tool dan orkestrasi

    Function calling, loop berlangkah banyak, kondisi berhenti, perilaku retry, dan idempotensi di setiap langkah yang punya efek keluar. Loop yang tidak bisa berhenti dan aksi yang terulang adalah cacat khas di wilayah ini.

  • Guardrail dan ketahanan terhadap penyalahgunaan

    Memperlakukan output model sebagai input yang tidak tepercaya, memvalidasinya terhadap sebuah skema sebelum ia menyentuh apa pun yang berkonsekuensi, dan membatasi tool mana yang bisa dijangkau alih-alih bergantung pada model untuk menolak.

  • Pengendalian latensi dan biaya

    Streaming, caching, mengarahkan permintaan yang sederhana ke model yang lebih kecil, memangkas context, dan menghitung biaya per tugas yang tuntas alih-alih per panggilan — angka yang kedua itulah yang mengikuti tagihan.

  • Output terstruktur

    Generasi yang dibatasi skema, validasi, perbaikan saat gagal, dan parsing deterministik di batas sistem, agar kode di hilir tidak pernah diminta menafsirkan prosa yang besok mungkin ia tafsirkan berbeda.

  • Pemantauan di production

    Trace lengkap termasuk context yang diambil, review manusia terjadwal atas respons yang disampel, alert atas pergerakan kualitas dan bukan hanya atas error, serta jalur yang membawa kegagalan yang dilaporkan pengguna kembali ke dalam evaluation set.

  • Penanganan data di batas sistem

    Tahu persis apa yang keluar dari lingkungan Anda, apa yang disimpan penyedia, apa yang disamarkan sebelum dikirim, dan bagaimana isolasi antar tenant ditegakkan di dalam index yang dipakai bersama beberapa pelanggan.

Konteks

Ekosistem teknologi

Berikut teknologi yang umum dipakai dalam AI engineering. Daftar ini menggambarkan lanskap disiplin tersebut sebagaimana dipraktikkan secara umum di industri, dan bukan klaim tentang perkakas engineer mana pun. Framework di bidang ini berganti nyaris tiap tahun, sehingga cara seorang kandidat menalar soal retrieval, context, dan pengukuran adalah sinyal yang jauh lebih baik daripada nama yang muncul di proyek terakhirnya.

Bahasa dan runtime

  • Python
  • TypeScript
  • Go

Akses dan hosting model

  • OpenAI API
  • Anthropic API
  • Google Vertex AI
  • Amazon Bedrock
  • vLLM
  • Ollama

Framework orkestrasi

  • LangChain
  • LlamaIndex
  • Semantic Kernel
  • Haystack
  • DSPy

Retrieval dan search

  • pgvector
  • Pinecone
  • Qdrant
  • Weaviate
  • Elasticsearch
  • OpenSearch

Evaluasi dan tracing

  • Ragas
  • DeepEval
  • promptfoo
  • LangSmith
  • Langfuse
  • OpenTelemetry

Validasi dan guardrail

  • Pydantic
  • Instructor
  • Guardrails AI
  • NeMo Guardrails
  • JSON Schema

Lapisan aplikasi

  • FastAPI
  • Next.js
  • Vercel AI SDK
  • Redis
  • Celery

Working model

Bagaimana peran ini bekerja dengan tim Anda

Engineer bekerja di dalam tim Anda, mengikuti prioritas dan standar Anda. Anda yang mengarahkan pekerjaannya; Talent.ID menangani hubungan kerjanya. Pembagian di bawah ini adalah keseluruhan pengaturannya.

Tetap milik Anda

  • Produk
  • Prioritas bisnis
  • Roadmap
  • Arsitektur
  • Prioritas sprint
  • Standar engineering
  • Kolaborasi teknis sehari-hari

Ditangani Talent.ID

  • Hubungan kerja
  • Payroll
  • Benefit karyawan
  • Administrasi talenta
  • Hubungan karyawan berkelanjutan

Bagaimana kerja sama berjalan, langkah demi langkah

Contoh penerapan

Seperti apa ini dalam praktik

Skenario hipotetis, ditulis untuk menunjukkan bagaimana model kerjanya diterapkan. Ini bukan klien Talent.ID dan bukan proyek yang pernah dikerjakan.

Tantangan
Sebuah tim produk telah merilis asisten yang menjawab pertanyaan dari dokumen perusahaan. Ia bekerja baik saat didemokan dan tidak menentu pada materi pelanggan yang sesungguhnya, tim support mulai meneruskan jawaban-jawaban yang keliru, dan tak seorang pun di tim bisa menyatakan apakah perubahan bulan lalu menolong atau justru merusak, karena tidak ada yang diukur.
Pendekatan
Kapasitas engineering tambahan masuk mengikuti cara kerja tim yang sudah berjalan: konvensi repositori mereka, code review mereka, proses rilis mereka, dan arah arsitektur yang sudah mereka tetapkan. Keputusan produk dan kewenangan teknis tetap pada engineer internal, dan kapasitas tambahan mengambil pekerjaan evaluasi, retrieval, dan pemantauan di dalam sprint yang sama.
Yang ditambahkan ke tim
Tim memperoleh kapasitas pengiriman sambil tetap memegang kepemilikan atas produk dan arsitekturnya. Apa yang seharusnya dilakukan asisten itu, dan standar apa yang harus ia penuhi sebelum dirilis, tetap menjadi keputusan orang-orang yang bertanggung jawab atasnya.

Disiplin terkait

Pertanyaan umum

Pertanyaan yang sering diajukan

Apa beda AI engineer dan machine learning engineer?
AI engineer membangun di sekeliling model yang dihasilkan pihak lain; machine learning engineer menghasilkan dan memelihara modelnya sendiri. Yang pertama menghabiskan waktunya pada retrieval, context, evaluasi, guardrail, dan perilaku produk yang sedang berjalan; yang kedua pada feature, pipeline pelatihan, infrastruktur serving, drift, dan pelatihan ulang. Tim yang mengintegrasikan foundation model milik penyedia membutuhkan yang pertama. Tim yang posisi kompetitifnya bergantung pada model yang dilatih atas datanya sendiri membutuhkan yang kedua.
Apakah AI engineer perlu melatih model?
Umumnya tidak. Fine-tuning muncul sesekali, paling sering untuk membetulkan format atau nada output alih-alih menambahkan pengetahuan, dan biasanya baru dijangkau setelah retrieval dan desain context sudah habis dieksplorasi. Jika kebutuhan yang sebenarnya adalah model yang dilatih atas data milik sendiri, itu disiplin berbeda dengan perkakas berbeda, dan mencari orangnya dengan judul peran ini berujung pada ketidakcocokan yang tidak menyenangkan bagi kedua pihak.
Apakah prompt engineering merupakan peran tersendiri?
Sebagai peran yang berdiri sendiri, ia jarang bertahan begitu bersentuhan dengan production. Susunan kata instruksi hanyalah satu artefak di antara retrieval, penyusunan context, evaluasi, guardrail, pemantauan, dan pengendalian biaya, dan justru artefak itulah yang paling mungkin ditulis ulang ketika salah satu yang lain diperbaiki dengan benar. Orang yang seluruh praktiknya adalah merangkai kalimat akan kesulitan di titik ketika masalah yang menarik ternyata bersifat arsitektural.
Mengapa evaluasi begitu menentukan bagi peran ini?
Karena tanpanya tidak ada cara membedakan perbaikan dari sekadar perubahan. Perangkat lunak konvensional memberi Anda test yang lulus atau gagal; komponen probabilistik memberi Anda respons yang berbeda, dan berbeda bukanlah arah. Tim tanpa evaluation harness menumpuk penyesuaian yang tak seorang pun bisa membenarkannya, dan pada akhirnya tidak sanggup menjawab apakah fiturnya lebih baik daripada enam bulan lalu.
Bisakah seorang backend engineer berpindah ke pekerjaan ini?
Sering, dan ini termasuk salah satu perpindahan yang paling berhasil. Bagian yang bisa dibawa besar: desain API, anggaran latensi, caching, queueing, observability, dan penanganan kegagalan adalah sebagian besar dari sistemnya. Yang harus dipelajari adalah toleransi yang sungguh-sungguh terhadap dependency yang tidak bisa direproduksi, serta kebiasaan mengukur perilaku secara statistik alih-alih menyatakannya lewat sebuah test.
Apakah retrieval masih perlu sekarang setelah context window menjadi sangat besar?
Untuk sebagian besar produk, ya. Jendela yang besar tidak menjawab dokumen mana yang mendukung sebuah klaim, tidak menegakkan siapa boleh melihat apa, dan tidak menghentikan biaya serta latensi yang membesar seiring segala hal yang Anda putuskan untuk disertakan. Retrieval tetap menjadi mekanisme untuk provenance, hak akses, dan penghematan, dan ketiga kebutuhan itu tidak lenyap seiring membesarnya jendela.
Bagaimana AI engineer bekerja bersama tim engineering yang sudah ada?
Di dalam model penambahan kapasitas tim engineering, arahnya milik Anda: arsitektur Anda, code review Anda, standar rilis Anda, dan apa pun yang menjadi sasaran sprint. Kolaborasi teknis sehari-hari berlangsung dengan engineer Anda sendiri. Talent.ID memegang sisi kepegawaiannya — payroll, benefit karyawan, administrasi talenta, dan hubungan kerja yang berkelanjutan.

Ceritakan kebutuhan tim Anda

Jelaskan kekurangannya — pekerjaannya, stack-nya, cara tim Anda berjalan — dan kami akan menyampaikan apa yang dapat kami dukung. Bila bukan sesuatu yang bisa kami bantu, kami akan mengatakannya.

Build your teamContact us