TECH 30/SEP/2026

Otomatis Isi Knowledge Graph: Ekstraksi Entity dan Triple dari Teks Bebas Pakai LLM

Knowledge graph itu emas buat mesin, tapi ngisinya manual bikin kantong jebol dan kepala pusing. Nih cara pakai LLM lokal biar kerjaan itu jalan sendiri.

Gue tuh sering kebayang satu skenario: lo punya tumpukan artikel, laporan, atau catatan panjang, dan di dalamnya berserakan fakta berharga. Cuma ada satu masalah, komputer nggak ngerti fakta itu sampai lo ubah jadi bentuk yang dia mengerti. Di situ knowledge graph masuk jadi pahlawan. Bayangin lo bisa nyuruh mesin buat baca teks mentah terus langsung ngubahnya jadi kumpulan fakta yang saling nyambung tanpa lo ngetik satu-satu. Kedengeran kayak sihir? Nggak juga. Ini soal nyuruh LLM ngelakuin bagian yang paling ngebosenin, sementara lo fokus ke bagian yang butuh otak.

Ilustrasi bagaimana sebuah model bahasa mengekstrak entitas dan relasi dari teks tak terstruktur menjadi knowledge graph

Ilustrasi alur ekstraksi entity dan triple dari teks bebas jadi knowledge graph (Kredit: Machine Learning Mastery / Iván Palomares Carrascosa)

Kenapa Knowledge Graph Itu Mahal dan Ribet

Knowledge graph itu cara rapi buat nyimpen pengetahuan, di mana tiap fakta disimpan sebagai relasi antara dua hal. "Alan Turing lahir di London", "Turing kuliah di King's College", dan seterusnya. Masalahnya, ngebangun dan ngerawat graph kayak gini secara manual itu mahal dan makan waktu gila-gilaan. Lo harus baca satu-satu, nentuin mana yang termasuk entity, mana yang termasuk relasi, lalu nulisinnya dengan format yang konsisten. Kalau datanya cuma sepuluh paragraf, masih sanggup. Tapi kalau udah ratusan dokumen? Lupakan.

Nah, di sinilah ide utamanya muncul. Daripada lo maksa manusia ngelakuin pekerjaan robot, kenapa nggak LLM aja yang disuruh baca dan ngekstrak? Artikel yang gue jadikan rujukan, tulisan Iván Palomares Carrascosa yang terbit 29 September 2026 di Machine Learning Mastery, nunjukin caranya dengan pendekatan yang lumayan ringkas: pakai model bahasa lokal buat ngubah teks mentah jadi structured knowledge, terus di-isiin ke sebuah graph. Menurut gue ini masuk akal banget, karena LLM memang jagoannya urusan nangkep makna dari teks bebas.

Idenya: Biarin LLM yang Baca, Bukan Manusia

Poin intinya sederhana. Kita nggak butuh LLM buat "berpikir" macam-macam. Kita cuma butuh dia ngelakuin satu tugas spesifik, yaitu ngekstrak fakta atomik dari sebuah teks dan nyusunnya dalam format yang kita tentuin sendiri. Yang menarik, percobaan di artikel itu nggak pakai API cloud mahal. Dia pakai Ollama buat ngejalanin model lokal, tepatnya llama3.2, lumayan ringan buat laptop atau punyamu yang agak serius.

Gue suka pendekatan ini karena beberapa alasan. Pertama, privasi relatif aman karena teksnya nggak perlu dikirim ke server orang lain. Kedua, biaya bisa ditekan karena lo nggak bayar per token ke vendor besar. Ketiga, buat eksperimen, jalur ini cepat dan gampang diulang.

Cara Kerjanya: SPOC, Prompt, dan JSON

Sekarang masuk ke bagian dagingnya. Supaya hasilnya konsisten, kita harus nentuin dulu bentuk outputnya. Di sini dipakai konsep quad SPOC, yaitu Subject, Predicate, Object, dan Context. Empat kolom ini memaksa tiap fakta punya struktur yang sama, jadi nggak berantakan.

Konkretnya begini. Lo kasih teks mentah ke LLM, terus lo minta dia balikin JSON yang isinya array fakta, di mana tiap fakta punya kunci subject, predicate, dan object. Predicate itu relasi, kayak "was born" atau "graduated from". Object itu targetnya, entitas lain atau nilai. Konteks ditambahin belakangan sama kode kita, gunanya buat nandain fakta ini datang dari dokumen mana. Kalau lo punya banyak sumber, kolom context ini bakal nyelametin hidup lo waktu ngecek asal-usul sebuah klaim.

Dua trik kecil yang bikin pendekatan ini lebih tahan banting. Pertama, minta LLM ngeluarin JSON secara eksplisit dan paksa modelnya ngikutin mode JSON. Kedua, setel temperature ke 0.0 biar jawabannya se-stabil mungkin. Plus, kode-nya tetap ngecek kasus di mana model bandel dan milih nama kunci yang beda sendiri, jadi hasil validasi tetap masuk jalur yang benar.

Contoh Praktis

Lo nggak perlu ninggalin rumah buat nyobain ini. Cukup rakit prompt dan kirim ke server lokal. Perhatikan bahwa prompt-nya nggak panjang-panjang amat, yang penting instruksinya jelas.

import json, requests

def extract_spoc_quads(text, context_label, model="llama3.2"):
    prompt = f"""You are an expert data extraction algorithm.
Extract atomic facts from the text.
Output a valid JSON object with a single key "facts", whose value is an array
of objects with keys: subject, predicate, object.

Text to process:
{text}"""

payload = {"model": model, "prompt": prompt,
               "format": "json", "stream": False, "temperature": 0.0}

r = requests.post("http://localhost:11434/api/generate", json=payload)
    facts = json.loads(r.json()["response"]).get("facts", [])

quads = []
    for f in facts:
        f = {str(k).lower().strip(): str(v).strip() for k, v in f.items()}
        if all(k in f for k in ("subject", "predicate", "object")):
            quad = dict(f)
            quad["context"] = context_label
            quads.append(quad)
    return quads

Singkatnya, kode di atas cuma nanyain ke model lokal: "baca teks ini, kasih gue daftar fakta dalam bentuk JSON". Habis itu hasilnya dibersihin, kuncinya diseragamin jadi huruf kecil semua, lalu ditambahin label konteks. Hasilnya kumpulan quad yang siap dimasukin ke penyimpanan graph. Di contoh artikel itu, dari dua paragraf tentang Alan Turing, pipeline ini berhasil narik sekitar sebelas fakta, kayak "Alan Mathison Turing | was born | in London" dan "Alan Mathison Turing | graduated from | King's College, Cambridge".

Jebakan yang Harus Lo Waspadai

Sekarang bagian yang nggak kalah penting. Nggak semua yang keluar dari LLM itu suci. Ini beberapa hal yang gue catet dan yang juga disinggung di sumbernya.

Pertama, halusinasi. Model bisa nambahin fakta yang sebenernya nggak ada di teks, atau salah nempelin relasi. Jadi tetap ada tahap validasi, termasuk bersihin entri yang nggak lengkap. Kedua, konsistensi skema. Walaupun lo udah minta format JSON, kadang model tetep ngasih nama kunci yang beda. Makanya normalisasi kunci dan fallback wajib ada. Ketiga, soal jumlah. Penulisnya sendiri nulis persis, "Note that the exact number may vary slightly due to the non-deterministic behavior of the LLM." Artinya jumlah fakta dari teks yang sama bisa beda tipis tiap kali dijalanin, walau temperature udah 0.0. Keempat, biaya dan sumber daya. Ngelakuin ekstraksi untuk banyak dokumen tetap butuh waktu komputasi, apalagi kalau modelnya gede. Dan kelima, evaluasi. Gimana lo tau hasilnya bener? Lo butuh sampel manual buat ngecek ketepatan, dan mesti nentuin ambang seberapa mesin bisa dipercaya.

Satu hal lagi yang gue anggep krusial: jangan taruh dua entity yang mirip tapi beda penulisan sebagai dua simpul berbeda. Ujung-ujungnya graph lo jadi berantakan karena duplikat. Deduplikasi dan penyeragaman nama itu wajib, bukan opsional.

Opini Gue

Kalau lo tanya gue, pendekatan ini bukan pengganti pakar. Ini lebih kayak asisten yang ngelakuin kerjaan kasar dulu. Lo tetep butuh manusia buat nentuin skema, ngecek kualitas, dan ngerapiin simpul. Tapi menghemat waktu dari "nol" jadi "delapan puluh persen jadi" itu pencapaian besar, dan di situlah LLM bersinar.

Yang bikin gue optimis, arsitektur ini nyambung ke pola yang lebih besar seperti Graph-RAG. Tujuan akhirnya jelas, yaitu memanfaatin graph buat ngurangin risiko halusinasi LLM. Jadi alurnya bagus: LLM dipakai buat ngebangun graph yang rapi, lalu graph itu dipakai bikin LLM lebih jujur lagi. Lingkaran yang sehat. Selama lo sadar batasnya dan nggak nelen mentah-mentah semua output, otomatisasi ekstraksi ini pantes masuk toolkit lo.

Sumber

Iván Palomares Carrascosa, "Automating Knowledge Graph Population: Extracting Entities and Triples from Unstructured Text with an LLM", Machine Learning Mastery: <https://machinelearningmastery.com/automating-knowledge-graph-population-extracting-entities-and-triples-from-unstructured-text-with-an-llm/> (diakses 30 September 2026)