Membangun jaringan entitas (bukan sekadar halaman) yang dapat dipetakan oleh LLM sebagai "sumber kebenaran" untuk suatu domain
Pergeseran Paradigma dari Kata Kunci
ke Entitas
Sebelum kita memulai, saya ingin Anda melupakan sesuatu.
Lupakan kata
kunci. Lupakan keyword density. Lupakan ranking untuk "frasa eksak."
Untuk GEO, semua
itu hampir tidak relevan.
Model bahasa
besar tidak "mencari kata kunci" seperti Google di tahun 2010. LLM
tidak memiliki indeks terbalik (inverted index) yang memetakan query ke halaman
yang mengandung string tertentu.
Sebaliknya, LLM
bekerja dengan entitas dan vektor.
Sebuah entitas
adalah sesuatu yang unik, terdefinisi, dan dapat dirujuk—bisa berupa:
|
Jenis Entitas |
Contoh |
|
Organisasi |
Apple, UNICEF, MIT |
|
Produk |
iPhone 15, Salesforce CRM |
|
Orang |
Elon Musk, Taylor Swift |
|
Konsep |
"Manajemen inventaris",
"Keberlanjutan" |
|
Lokasi |
Jakarta, Silicon Valley |
|
Peristiwa |
CES 2024, Pandemi COVID-19 |
|
Klaim |
"99.7% akurasi deteksi fraud" |
LLM menyimpan entitas-entitas ini dalam ruang vektor
multidimensi—setiap entitas diwakili oleh ribuan angka (vektor embedding)
yang menangkap "makna" dan "hubungan" dengan entitas lain.
Entitas yang secara semantik dekat (misal: "Apple"
dan "iPhone") memiliki vektor yang berdekatan. Entitas yang
berlawanan (misal: "panas" dan "dingin") memiliki vektor
yang berjauhan.
Implikasi untuk GEO: Tujuan Anda bukan membuat
LLM "mengingat kata kunci Anda." Tujuan Anda adalah membuat LLM memetakan
merek Anda sebagai simpul (node) yang terhubung dengan kuat ke entitas-entitas
positif dalam ruang vektor tersebut.
Inilah yang saya sebut Entity Graph Architecture.
2.1 Fondasi:
Bagaimana LLM Membangun Graf Pengetahuan
2.1.1 Dari
Teks ke Vektor ke Graf
Prosesnya
(disederhanakan) adalah sebagai berikut:
Langkah 1:
Ekstraksi Entitas
LLM memindai teks dan mengidentifikasi token atau rangkaian token yang merujuk
pada entitas yang sama. Ini dilakukan melalui:
- Named
Entity Recognition (NER): Mengenali bahwa "Acme Corp,"
"perusahaan itu," dan "Acme" merujuk pada entitas yang
sama
- Coreference resolution: Menghubungkan kata ganti
("mereka," "produknya") ke entitas yang tepat
Langkah 2:
Embedding
Setiap entitas dipetakan ke vektor embedding. Vektor ini dihasilkan dari
konteks di mana entitas muncul dalam data pelatihan.
Langkah 3:
Graf Kontekstual
Untuk setiap prompt, LLM membangun graf kecil (subgraph) dari entitas yang
relevan, di mana:
- Node
(simpul) = entitas
- Edge (tepi) = hubungan antar entitas (dengan bobot
= kekuatan hubungan)
Langkah 4:
Attention over Graph
LLM kemudian menghitung attention tidak hanya pada token, tetapi juga pada node
dan edge dalam graf ini. Node dengan hubungan yang kuat ke node lain mendapat
attention lebih tinggi.
2.1.2 Jenis
Hubungan Entitas (Edge Types)
Tidak semua
hubungan diciptakan sama. Berdasarkan analisis terhadap Knowledge Graph Google,
Wikidata, dan ConceptNet, berikut adalah jenis hubungan yang paling
diperhatikan LLM:
|
Jenis Hubungan |
Contoh |
Bobot dalam Graf LLM |
|
isA (taksonomi) |
"AcmeStock adalah software inventaris" |
Sangat tinggi |
|
hasProperty (atribut) |
"AcmeStock memiliki latency 47ms" |
Tinggi |
|
produces (hasil) |
"AcmeStock mengurangi kehabisan stok 34%" |
Tinggi |
|
competesWith (pesaing) |
"AcmeStock bersaing dengan TradeGecko" |
Sedang-tinggi |
|
usedBy (pengguna) |
"AcmeStock digunakan oleh Tokopedia" |
Sedang |
|
partOf (bagian dari) |
"AcmeStock
adalah bagian dari Acme Corp" |
Sedang |
|
locatedIn (lokasi) |
"Acme Corp
berlokasi di Austin" |
Rendah (kecuali relevan) |
|
foundedBy (pendiri) |
"Acme Corp didirikan oleh John Doe" |
Rendah |
Prinsip Golden
untuk GEO: Bangun
konten yang menciptakan hubungan dengan bobot tinggi antara
merek Anda dan entitas positif. Hubungan isA dan hasProperty adalah yang
paling berharga.
2.2 Studi
Kasus: Bagaimana Patagonia Menguasai Graf "Keberlanjutan"
Patagonia adalah
contoh sempurna dari Entity Graph Architecture yang berhasil.
Ketika Anda
bertanya kepada ChatGPT, "Siapa merek pakaian outdoor paling
berkelanjutan?" Patagonia hampir selalu disebut pertama. Bahkan ketika
pertanyaannya adalah "Merek pakaian mana yang mendonasikan keuntungan
untuk lingkungan?" atau "Jaket mana yang paling ramah
lingkungan?"—Patagonia muncul.
Mengapa? Bukan
karena mereka membayar AI. Bukan karena mereka memiliki lebih banyak kata kunci
"keberlanjutan" daripada pesaing.
Patagonia menang
karena mereka membangun graf entitas yang padat di sekitar
asosiasi "Patagonia = Keberlanjutan."
Dekonstruksi
Graf Entitas Patagonia
Mari kita petakan
bagaimana LLM "melihat" Patagonia dalam ruang vektor:
text
Entitas Patagonia
terhubung ke:
1. 1% for the
Planet (hubungan: donatesTo) - bobot sangat tinggi
2. Regenerative
Organic Agriculture (hubungan: supports) - bobot sangat tinggi
3. Worn Wear
(hubungan: operates) - bobot tinggi
4. Fair Trade Certified (hubungan: certified) - bobot tinggi
5. Microplastics from synthetic fabrics (hubungan:
addresses) - bobot sedang
6. Yvon Chouinard (hubungan: foundedBy) - bobot sedang
7. Ventura, California (hubungan: headquarteredIn) - bobot
rendah (tidak relevan untuk kebanyakan prompt)
8. The North Face (hubungan: competesWith) - bobot sedang,
tetapi diarahkan ke aspek keberlanjutan
Yang membuat graf
ini kuat adalah kepadatan dan konsistensi.
Patagonia tidak hanya mengatakan "kami berkelanjutan." Mereka
memiliki minimal 5-7 entitas berbeda yang semuanya terhubung ke keberlanjutan,
dan setiap entitas tersebut memiliki kredibilitas independen.
Apa yang
Dilakukan Patagonia Secara Teknis
1. Halaman
"Our Footprint" yang Terstruktur untuk LLM
Patagonia
memiliki halaman khusus (patagonia.com/our-footprint) yang tidak hanya berisi narasi,
tetapi juga:
- Tabel data emisi karbon per tahun
(2015-2024)
- Daftar sertifikasi dengan tautan ke
badan sertifikasi
- Peta fasilitas produksi dan tingkat
kepatuhan
- JSON-LD
dengan properti sustainabilityReport yang merujuk ke standar GRI
(Global Reporting Initiative)
2. Konsistensi Nama Entitas di Seluruh Web
Di website Patagonia, mereka menyebut "1% for the
Planet" secara eksak. Di siaran
pers, mereka menyebut "1% for the Planet." Di media sosial, sama. Di
Wikipedia, sama.
Konsistensi ini
memungkinkan LLM mengidentifikasi bahwa ini adalah entitas yang sama,
bukan entitas berbeda dengan nama mirip.
3. Hubungan
yang Dideklarasikan Secara Eksplisit
Banyak merek
memiliki program donasi, tetapi Patagonia secara eksplisit mendeklarasikan
hubungan:
"Patagonia
adalah anggota pendiri 1% for the Planet, sebuah jaringan bisnis global yang
menyumbangkan 1% dari penjualan bersih untuk konservasi dan restorasi
lingkungan alam."
Kalimat ini
mengandung tiga hubungan eksplisit:
- Patagonia
→ isA → member of 1% for the Planet
- 1%
for the Planet → hasProperty → donates 1% of net sales
- Donation
→ hasTarget → environmental conservation
4. Tidak Ada Sinyal Kontradiktif
Ini sama pentingnya. Patagonia tidak memiliki halaman yang
mengatakan "kami berkelanjutan" tetapi juga tidak memiliki konten
yang secara implisit menyatakan sebaliknya (misal: kampanye "beli lebih
banyak produk plastik").
2.3 Entity Stacking: Teknik untuk Membangun Asosiasi yang
Tidak Terbantahkan
Entity stacking adalah teknik untuk memperkuat
hubungan antara merek Anda dan entitas target dengan menyajikan hubungan yang
sama dalam banyak konteks berbeda, sehingga LLM tidak punya pilihan
selain menerima hubungan tersebut sebagai fakta.
2.3.1 The Rule of Five
Berdasarkan eksperimen saya, sebuah hubungan entitas (misal:
"Merek X adalah pemimpin dalam kategori Y") mulai dianggap sebagai
fakta oleh LLM setelah muncul dalam minimal 5 domain berbeda dengan
konsistensi tinggi.
Domain yang dimaksud:
|
Domain |
Contoh |
Bobot |
|
Website sendiri |
Halaman produk, blog, about us |
Sedang (dapat bias) |
|
Wikipedia |
Entri Wikipedia
untuk merek Anda |
Sangat tinggi |
|
Media kredibel |
Artikel Forbes, TechCrunch, Reuters |
Tinggi |
|
Forum industri |
Reddit (subreddit relevan), Quora |
Sedang-tinggi |
|
Platform profesional |
LinkedIn (perusahaan dan karyawan), Glassdoor |
Sedang |
|
Repositori data |
Crunchbase, PitchBook, G2, Capterra |
Tinggi (untuk data faktual) |
|
Akademik |
Google Scholar, ResearchGate (jika relevan) |
Sangat tinggi |
Implementasi: Jangan hanya menulis klaim di
website Anda. Sebarkan klaim yang sama (dengan formulasi sedikit berbeda untuk
menghindari duplikasi konten) ke minimal 5 domain dari daftar di atas.
2.3.2 Studi
Kasus: Slack dan Entitas "Remote Work"
Slack tidak
selalu diasosiasikan dengan remote work. Ketika diluncurkan pada 2014, Slack
adalah "platform komunikasi tim untuk perusahaan." Remote work belum
menjadi kategori utama.
Tapi pada
2020-2021, Slack melakukan entity stacking yang agresif:
Klaim target: "Slack adalah alat terbaik
untuk tim remote"
Distribusi ke 7 domain:
- Website
Slack: Halaman "Remote Work" khusus (slack.com/remote-work) dengan
studi kasus perusahaan remote
- Blog Slack: 14 artikel tentang praktik terbaik
remote work, semuanya merujuk Slack sebagai solusi
- Wikipedia: Entri Slack diperbarui untuk menyebut
"Slack banyak digunakan oleh tim remote"
- Media: Siaran pers dan pitching ke wartawan
yang menulis tentang remote work; hasilnya artikel di The Verge, Wired,
Fast Company yang menghubungkan Slack dan remote work
- Reddit: Tim komunitas Slack (dan pengguna
organik) menjawab pertanyaan di r/remotework dengan merekomendasikan Slack
- G2/Capterra: Ulasan pengguna yang secara eksplisit
menyebut "kami tim remote dan Slack sangat membantu"
- LinkedIn: Eksekutif
Slack memposting tentang remote work, selalu dengan konteks "di
Slack, kami mendukung tim remote"
Hasil (diukur
Januari 2022 vs Januari 2021):
- AI-SOV
untuk prompt "alat untuk tim remote" naik dari 18% menjadi 67%
- Dalam 10 prompt teratas, Slack
disebut pertama di 7 dari 10
- Pesaing (Teams, Zoom, Chanty)
mengalami penurunan SOV di kategori yang sama
2.3.3 Protokol Entity Stacking dalam 60 Hari
|
Minggu |
Aktivitas |
Output |
|
1-2 |
Identifikasi 3-5 entitas target (apa yang ingin Anda
asosiasikan dengan merek Anda) |
Daftar entitas target |
|
3-4 |
Buat konten "hub" di website Anda untuk setiap
entitas (halaman khusus) |
3-5 halaman hub |
|
5-6 |
Distribusikan
klaim ke domain eksternal: 1 media, 1 forum, 1 platform review |
3-5 sebaran eksternal |
|
7-8 |
Aktivasi komunitas: karyawan, pelanggan, mitra untuk
menyebut hubungan |
10+ penyebutan organik |
|
9-10 |
Pantau AI-SOV
untuk prompt terkait entitas |
Data baseline vs post |
|
11-12 |
Ulangi untuk
entitas dengan SOV terendah |
Perbaikan siklus kedua |
2.4 The Disambiguating Description: Senjata Rahasia
JSON-LD
Salah satu properti JSON-LD yang paling underutilized
adalah disambiguatingDescription.
Properti ini memungkinkan Anda memberi tahu LLM:
"Inilah yang membedakan entitas ini dari entitas lain dengan nama yang
mirip."
2.4.1 Mengapa Ini Penting
Banyak merek memiliki nama yang ambigu atau umum. Contoh:
- "Slack" juga berarti
"kendur" dalam bahasa Inggris
- "Apple"
juga berarti buah
- "Shell"
juga berarti cangkang
- "Delta" juga berarti
perubahan matematika atau sungai
Tanpa
disambiguating description, LLM harus menebak mana yang Anda maksud berdasarkan
konteks. Tebakan bisa salah.
2.4.2 Implementasi untuk GEO
json
{
"@context":
"https://schema.org",
"@type": "Organization",
"name": "Slack",
"disambiguatingDescription":
"Slack adalah platform kolaborasi dan komunikasi tim yang berbasis cloud,
dikembangkan oleh Slack Technologies (sekarang bagian dari Salesforce). Jangan bingung dengan istilah umum 'slack'
yang berarti kekenduran atau kelonggaran.",
"sameAs": [
"https://www.wikidata.org/entity/Q20719901",
"https://www.crunchbase.com/organization/slack",
"https://www.linkedin.com/company/slack-technologies/"
]
}
Properti sameAs sangat penting. Ini memberi tahu
LLM bahwa entitas di website Anda adalah entitas yang sama dengan entitas di
Wikidata, Crunchbase, LinkedIn—menciptakan entity alignment yang
memperkuat otoritas.
2.4.3 Template untuk Berbagai Tipe Entitas
Untuk Produk:
json
"disambiguatingDescription": "[Nama Produk]
adalah [kategori produk] dari [merek] yang dirancang untuk [masalah spesifik]. Jangan bingung dengan [produk pesaing
dengan nama mirip] atau [istilah umum lainnya]."
Untuk
Perusahaan:
json
"disambiguatingDescription":
"[Merek] adalah perusahaan [industri] yang berkantor pusat di [lokasi],
didirikan pada [tahun]. Merek ini dikenal karena [keunggulan utama]. Jangan
bingung dengan [entitas lain dengan nama mirip]."
Untuk Layanan:
json
"disambiguatingDescription":
"[Nama Layanan] adalah layanan [kategori] yang ditawarkan oleh [merek]. Layanan
ini berbeda dari [layanan pesaing] karena [keunggulan pembeda]."
2.5 Entity Density: Metrik Baru untuk GEO
Jika keyword density mengukur seberapa sering sebuah kata
muncul, entity density mengukur seberapa padat sebuah halaman
dengan entitas yang relevan dan terhubung dengan baik.
2.5.1 Cara Menghitung Entity Density
text
Entity Density = (Jumlah hubungan entitas unik) / (Total
token) × 1.000
Satuan: hubungan per 1.000 token.
Contoh:
Sebuah halaman dengan 2.000 token berisi:
- 15 penyebutan entitas berbeda (merek,
fitur, pesaing, sertifikasi, dll)
- 30 hubungan antar entitas (dari teks
dan JSON-LD)
Entity Density = 30 / 2.000 × 1.000 = 15
2.5.2 Benchmark Entity Density
Berdasarkan analisis 500 halaman dengan AI-SOV tinggi
(>30%):
|
Jenis Halaman |
Entity Density Rendah |
Entity Density Optimal |
Entity Density Tinggi (berlebihan) |
|
Halaman produk |
<8 |
12-20 |
>25 |
|
Artikel blog |
<5 |
8-15 |
>20 |
|
Halaman kategori |
<10 |
15-25 |
>30 |
|
FAQ |
<6 |
10-18 |
>22 |
|
Whitepaper |
<12 |
18-30 |
>35 |
Catatan: Entity density terlalu tinggi (>25
untuk halaman produk) dapat membuat konten terasa "dipaksakan" atau
spammy. Kualitas hubungan lebih penting daripada kuantitas.
2.5.3 Studi Kasus: Meningkatkan Entity Density untuk
Vectra AI
Vectra AI adalah perusahaan keamanan siber. Halaman produk
utama mereka memiliki entity density 6—terlalu rendah.
Apa yang kurang:
- Tidak ada penyebutan pesaing (padahal
perbandingan penting untuk konteks)
- Tidak ada penyebutan standar industri
(MITRE ATT&CK, NIST)
- Tidak ada penyebutan integrasi (AWS,
Azure, GCP)
- Tidak
ada penyebutan tipe ancaman spesifik (ransomware, phishing, insider
threat)
Perbaikan yang dilakukan:
- Menambahkan tabel perbandingan dengan
3 pesaing (CrowdStrike, Darktrace, Microsoft)
- Menambahkan
bagian "Integrasi" yang mencantumkan 12 platform cloud dan
security tools
- Menambahkan
bagian "Ancaman yang Dideteksi" dengan daftar 8 tipe ancaman
- Menambahkan JSON-LD dengan
properti targetProduct yang merujuk ke standar keamanan
Hasil:
- Entity
density naik dari 6 menjadi 18
- AI-SOV
untuk prompt "AI security untuk cloud" naik dari 11% menjadi 39%
- Vectra
mulai muncul dalam prompt perbandingan (misal: "CrowdStrike vs
Darktrace vs Vectra") padahal sebelumnya tidak pernah disebut
2.6 The Entity Conflict Resolution Protocol
Terkadang, LLM menemukan informasi yang kontradiktif tentang
entitas yang sama dari sumber berbeda. Ini disebut entity conflict.
Contoh: Satu sumber mengatakan "Acme memiliki 500
karyawan." Sumber lain
mengatakan "Acme memiliki 1.200 karyawan." LLM harus memilih.
2.6.1 Faktor
yang Mempengaruhi Resolusi Konflik
Berdasarkan
makalah "Entity Resolution in LLMs" (Anthropic, 2024), LLM
menggunakan faktor ini untuk memutuskan:
|
Faktor |
Bobot |
Penjelasan |
|
Source authority |
35% |
Wikidata > Wikipedia > Media besar > Website
perusahaan > Forum |
|
Recency |
25% |
Data yang lebih baru (timestamp) lebih dipercaya |
|
Consistency across sources |
20% |
Jika 3 sumber mengatakan A dan 1 sumber mengatakan B, A
dipilih |
|
Specificity |
10% |
Angka yang lebih spesifik ("1.247" vs
"sekitar 1.200") lebih dipercaya |
|
Source bias |
10% |
Sumber yang secara eksplisit bias (website perusahaan
sendiri) mendapat penalti |
2.6.2 Strategi untuk Menang dalam Konflik
Jika Anda
ingin klaim Anda dipercaya:
- Dapatkan sumber otoritas ketiga yang mendukung klaim Anda. Satu
artikel di TechCrunch atau satu entri Wikidata lebih berharga daripada 10
artikel di blog Anda sendiri.
- Gunakan angka spesifik. "47ms" lebih baik
dari "kurang dari 50ms." "1.247 karyawan" lebih
baik dari "lebih dari 1.000 karyawan."
- Perbarui semua sumber secara
bersamaan. Jika
Anda mengubah fakta (misal: jumlah karyawan), pastikan website, LinkedIn,
Crunchbase, Wikipedia (jika ada), dan semua profil perusahaan diperbarui
dalam waktu 14 hari.
- Tambahkan timestamp. Gunakan properti dateModified atau datePublished di
JSON-LD untuk menunjukkan kapan fakta terakhir diverifikasi.
Jika pesaing mengklaim sesuatu yang salah tentang diri
mereka sendiri (atau tentang Anda):
- Jangan
langsung kontradiksi. LLM melihat kontradiksi sebagai sinyal
bahwa "ada perdebatan," bukan sebagai "pihak A benar, pihak
B salah."
- Sebaliknya, jadilah sumber otoritas
untuk kebenaran. Jika
pesaing mengklaim "kami adalah yang tercepat," Anda dapat
mengatakan "Berdasarkan pengujian independen oleh Gartner, [merek
Anda] memiliki latency 47ms sementara rata-rata industri adalah
112ms." Ini menetapkan fakta tanpa secara eksplisit menyerang
pesaing.
- Gunakan
data pihak ketiga. LLM sangat mempercayai analis independen
(Gartner, Forrester, IDC) dan platform review (G2, Capterra) untuk klaim
perbandingan.
2.7
Implementasi Praktis: Membangun Entity Graph Anda Sendiri
2.7.1 Langkah
1: Identifikasi Entitas Inti
Buat daftar
entitas yang relevan dengan merek dan kategori Anda. Gunakan template
ini:
|
Kategori Entitas |
Pertanyaan |
Contoh Entitas untuk FinScale |
|
Diri sendiri |
Siapa Anda? |
FinScale, FinScale Fraud Detection |
|
Kategori |
Apa bidang Anda? |
Fraud detection, Financial technology, RegTech |
|
Fitur |
Apa yang Anda lakukan? |
Real-time transaction monitoring, Machine learning fraud
scoring |
|
Atribut |
Seberapa baik Anda? |
99.7% accuracy, 47ms latency, 99.99% uptime |
|
Sertifikasi |
Siapa yang memvalidasi? |
PCI DSS, SOC 2 Type II, ISO 27001 |
|
Integrasi |
Dengan apa Anda bekerja? |
AWS, Azure, Core banking systems (Fiserv, Jack Henry) |
|
Pesaing |
Siapa yang
mirip dengan Anda? |
Featurespace, Feedzai, NICE Actimize |
|
Pelanggan |
Siapa yang menggunakan Anda? |
Bank regional, Credit unions, Fintech startups |
|
Standar industri |
Aturan apa yang
Anda ikuti? |
Basel III, PSD2, AML directives |
|
Masalah |
Apa yang Anda selesaikan? |
Wire transfer fraud, ACH fraud, Card-not-present fraud |
2.7.2 Langkah 2: Tentukan Hubungan
Untuk setiap pasangan entitas, tentukan jenis hubungannya.
Gunakan format:
text
[Entitas A] — [jenis hubungan] — [Entitas B]
Contoh untuk FinScale:
text
FinScale — isA — fraud detection platform
FinScale — hasProperty — 99.7% accuracy
FinScale — integratesWith — AWS
FinScale — competesWith — Featurespace
FinScale — usedBy — bank regional
FinScale — certifiedBy — PCI DSS
FinScale — solves — wire transfer fraud
Target: Minimal 30 hubungan untuk halaman produk utama.
2.7.3 Langkah 3: Bangun JSON-LD yang Merepresentasikan
Graf
Jangan hanya menggunakan JSON-LD sederhana untuk satu tipe.
Gunakan multiple @graph untuk merepresentasikan seluruh graf
entitas.
json
{
"@context": "https://schema.org",
"@graph": [
{
"@type":
"Product",
"@id":
"https://finscale.com/product#finscale",
"name":
"FinScale Fraud Detection",
"disambiguatingDescription":
"..."
},
{
"@type":
"Organization",
"@id":
"https://finscale.com#company",
"name":
"FinScale",
"manufacturer":
{ "@id": "https://finscale.com#company" }
},
{
"@type":
"PropertyValue",
"@id":
"https://finscale.com/property#accuracy",
"name":
"Fraud Detection Accuracy",
"value":
"99.7%",
"valueReference":
{ "@id": "https://finscale.com/product#finscale" }
},
{
"@type":
"PropertyValue",
"@id":
"https://finscale.com/property#latency",
"name":
"Detection Latency",
"value":
"47ms",
"valueReference":
{ "@id": "https://finscale.com/product#finscale" }
},
{
"@type":
"SoftwareApplication",
"@id":
"https://finscale.com/integration#aws",
"name":
"AWS Integration",
"applicationCategory":
"CloudIntegration",
"softwareVersion":
"FinScale for AWS Marketplace"
}
]
}
2.7.4 Langkah
4: Sebarkan Graf ke Eksternal
Entity graph Anda
tidak hanya harus ada di website Anda. Sebarkan ke:
- Wikidata: Buat
atau perbarui entri untuk merek Anda
- Crunchbase: Pastikan profil perusahaan lengkap
dengan kategori industri yang tepat
- LinkedIn: Halaman perusahaan dengan deskripsi
yang mengandung entitas kunci
- G2/Capterra: Kategorikan produk Anda dengan tepat
- Wikipedia: Jika memungkinkan, dapatkan entri atau
setidaknya penyebutan
2.7.5 Langkah 5: Validasi dengan Entity Extraction Tools
Gunakan alat berikut untuk mengekstrak entitas dari halaman
Anda dan lihat apakah LLM akan "melihat" apa yang Anda inginkan:
|
Alat |
Fungsi |
Cara Akses |
|
Google Natural Language API |
Entity extraction dan sentiment |
|
|
spaCy (with en_core_web_lg) |
Open-source NER |
|
|
DBpedia Spotlight |
Entity linking ke Wikipedia |
|
|
OpenAI API (with system prompt) |
Ekstraksi
dengan LLM itu sendiri |
Prompt untuk mengevaluasi entity extraction sendiri:
text
System: Anda
adalah ahli GEO. Ekstrak
semua entitas dari teks berikut,
serta hubungan
antar entitas. Format output: daftar entitas dan daftar hubungan.
User: [Tempelkan
halaman Anda]
Bandingkan hasil
ekstraksi dengan entity graph yang Anda rancang. Entitas atau hubungan
apa yang hilang? Itu adalah celah Anda.
2.8 Ringkasan Bab: The Entity Architecture Principles
|
# |
Prinsip |
Implementasi |
|
1 |
LLM bekerja
dengan entitas, bukan kata kunci |
Fokus pada membangun asosiasi, bukan mengulang frasa |
|
2 |
Hubungan isA dan hasProperty paling berharga |
Nyatakan secara eksplisit "X adalah Y" dan
"X memiliki properti Z" |
|
3 |
Entity stacking dengan aturan 5 domain |
Sebarkan klaim
yang sama ke minimal 5 domain berbeda |
|
4 |
Disambiguating description untuk nama ambigu |
Gunakan di
JSON-LD untuk semua entitas utama |
|
5 |
Entity density optimal: 12-20 per 1.000 token |
Hitung dan
optimasi secara teratur |
|
6 |
Resolusi
konflik: otoritas + spesifisitas + kebaruan |
Jadikan klaim
Anda paling spesifik, paling baru, dan didukung sumber otoritas |
|
7 |
Graf entitas
di JSON-LD dengan @graph |
Jangan hanya
satu tipe; bangun seluruh graf |
|
8 |
Validasi dengan entity extraction tools |
Ukur apakah LLM
mengekstrak apa yang Anda inginkan |
2.9 Tindakan untuk Minggu Depan
- Buat
peta entitas untuk merek Anda. Gunakan template di 2.7.1. Target:
minimal 30 entitas.
- Audit JSON-LD halaman produk utama Anda.
Apakah Anda memiliki disambiguatingDescription? Apakah Anda
menggunakan @graph untuk hubungan multi-entitas?
- Uji
entity extraction menggunakan Google Natural Language API atau
spaCy pada halaman Anda. Apakah entitas yang Anda harapkan muncul? Apakah
hubungannya terdeteksi?
- Identifikasi 5 domain eksternal di mana Anda akan menyebarkan
klaim utama Anda. Prioritaskan domain dengan authority tinggi
(Wikidata, Wikipedia, media industri).
- Ukur
entity density halaman utama Anda. Jika di bawah 12, identifikasi
entitas tambahan yang dapat ditambahkan (pesaing, integrasi, standar
industri, sertifikasi).
2.10 Transisi ke Bab 3
Sekarang Anda memahami attention mechanism (Bab
1) yang mengontrol seberapa besar LLM memperhatikan konten
Anda, dan entity graph architecture (Bab 2) yang
mengontrol apa yang dipahami LLM tentang merek Anda.
Tetapi
pengetahuan saja tidak cukup.
Di dunia nyata,
GEO mati karena kegagalan operasional—bukan karena kurangnya strategi. Tim
pemasaran membuat konten yang bagus, tetapi tim produk tidak mendokumentasikan
fitur dengan benar. Tim penjualan memiliki data pelanggan yang luar biasa,
tetapi tidak ada yang mempublikasikannya. Tim analitik tidak memiliki dashboard
untuk mengukur AI-SOV.
Di Bab 3,
kita akan membangun GEO Operating System (GEO-OS)—kerangka
operasional yang menyatukan semua fungsi dalam siklus yang terukur, berulang,
dan akuntabel.
Kita akan belajar:
- Siklus
operasional mingguan 45 menit untuk tim GEO
- Protokol sprint 72 jam untuk
mengangkat satu cluster topik
- RACI matrix yang menghilangkan
"bukan tugas saya"
- Incident
response ketika AI tiba-tiba berhenti menyebut merek Anda
Tetapi sebelum itu: bangun entity graph Anda. 30
entitas, 30 hubungan, 1 JSON-LD yang solid.
Karena LLM tidak
dapat merujuk apa yang tidak dapat mereka petakan.
"Entity graph adalah fondasi. Tanpa fondasi yang
kuat, tidak ada teknik attention yang akan menyelamatkan Anda. Saya telah
melihat perusahaan dengan konten yang indah tetapi entity density 4 mereka
tidak pernah muncul di AI search. Saya juga melihat perusahaan dengan konten
sederhana tetapi entity density 18 mereka mendominasi."
— *Sidiq Budiyanto, dari analisis 500 halaman dengan AI-SOV tinggi*