AI agent untuk estimasi biaya proyek

Masalahnya ada di data, bukan rumus

Di Wilayah Kerja Rokan ada aliran proyek pendukung yang tidak pernah berhenti: pembangunan gathering station dan fasilitas produksi, penggelaran flowline dan trunkline, gardu serta jaringan listrik untuk pompa, sampai pekerjaan sipil seperti jalan akses dan pondasi. Nilainya besar dan berulang, jadi estimasi yang meleset di tahap awal langsung terasa di anggaran tahunan.

Tim cost estimate menyimpan hampir semua pengetahuannya di spreadsheet Excel. Histori pengadaan, rekap proyek yang sudah selesai, kontrak konstruksi yang sedang berjalan, tabel indeks harga dengan komponen seperti CPI, indeks baja, dan indeks minyak. Berkas ini dibuat untuk dibaca mata manusia: header bertingkat, sel gabungan, catatan menempel di pinggir, satu sheet memuat beberapa tabel yang tidak berhubungan. Isinya kaya, tapi strukturnya berantakan.

Kenapa modelnya lokal

Data biaya dan kontrak dari PHR sensitif, jadi tidak boleh diproses lewat API LLM publik. Prototype ini memakai LLM open-weight yang di-host sendiri di server internal DTETI FT UGM, dan seluruh inferensi terjadi di sana.

Ada harganya. Model open-weight sekelas ini tidak sekuat model frontier untuk penalaran panjang yang bertahap. Selisih itu jadi pekerjaan kami di sisi arsitektur. Tugas dipecah ke sub-agen yang lebih kecil, tiap tool dibuat mengembalikan konteks yang sudah matang alih-alih data mentah, dan prompt disusun rapat supaya tidak ada ruang salah tafsir.

Dua tahap yang bisa diuji terpisah

Prototype kami pisah jadi dua bagian. Ingestion mengubah Excel berantakan jadi tool yang siap dipanggil agen: Excel mentah dibersihkan jadi CSV, di-embedding, masuk ke vector database, lalu dibungkus sebagai tool. Langkah pertamanya yang paling sulit, karena berarti menebak maksud spreadsheet yang dibuat orang lain bertahun-tahun lalu.

Inference adalah tahap kerja agen, dan ini sistem multi-agen. Agen memakai tool hasil ingestion untuk menyusun estimasi dengan metode yang dipakai estimator sungguhan: top-down, parametric, dan bottom-up. Hasil akhirnya berupa berkas Excel.

RAG seragam tidak cukup

Sebelum menulis kode, kami belajar domain cost estimate dulu. Bagaimana seorang estimator berpikir, berkas mana yang dia buka lebih dulu, kapan dia menarik indeks harga, bagaimana dia menyesuaikan proyek lama ke harga hari ini. Dari situ kami mencari pola yang bisa dipakai dan menirukan langkahnya satu per satu. Sebuah AI agent bekerja mirip manusia; kalau kami tidak paham urutan kerja manusianya, workflow yang kami rancang pasti meleset.

Alur dokumen → chunk → embedding → retrieval → generation cocok untuk kumpulan teks yang homogen. Data cost estimate tidak begitu.

Tabel indeks harus di-lookup persis. Histori proyek dicocokkan berdasarkan kemiripan, sementara kontrak berjalan disaring dulu berdasarkan status. Tiap watak data minta pendekatannya sendiri, dan itu yang kami rancang di tahap ingestion.

Tracing supaya bisa dievaluasi

Setelah kedua tahap berjalan, kami pasang tracing. Tanpa itu kami buta terhadap apa yang sebenarnya dikerjakan agen. Tracing merekam jalur yang diambil agen, isi proses berpikirnya, tool yang dipanggil beserta argumennya, konteks yang dikembalikan tiap tool, dan angka tiap run seperti latency dan pemakaian token.

Waktu agen salah langkah, kami bisa menemukan titik belokannya. Kalau akarnya penalaran, kami perkuat system prompt. Kalau tool memberi konteks yang tidak nyambung, tool itu yang kami perbaiki. Tracing juga berjalan di ingestion, karena transformasi dari Excel berantakan ke data terstruktur harus dipastikan benar sebelum masuk ke vector database. Kesalahan yang lolos di tahap ini muncul lagi sebagai estimasi yang keliru, dan jauh lebih sulit dilacak dari sana.