Kategori: ezformatter

Panggilan API Anda baru saja gagal dengan JSONDecodeError: Expecting property name enclosed in double quotes. Waktu terus berjalan. Data berasal dari LLM, dan di suatu tempat dalam respons 2.000 token itu, satu koma ekstra menghancurkan seluruh pipeline Anda.

Per Mei 2026, cara tercepat untuk memperbaiki file JSON yang rusak adalah menggunakan library otomatis seperti json_repair (Python) atau jsonrepair (npm). Alat-alat ini dirancang khusus untuk memperbaiki error sintaks hasil LLM secara instan. Untuk perbaikan manual, penyebab yang paling sering adalah koma ekstra, kutip tunggal, atau key tanpa kutip — tiga pelanggaran paling umum terhadap standar RFC 8259.

Perbaikan Tercepat: json_repair untuk Output LLM

Parser standar seperti json.loads() di Python bersifat ketat sesuai desainnya. Satu karakter yang salah posisi memicu JSONDecodeError dan semuanya berhenti. Ini adalah masalah harian di tahun 2026 karena LLM rutin membungkus JSON dalam teks percakapan, memotong respons di tengah kalimat, atau menyisipkan komentar yang melanggar spesifikasi.

Library json_repair adalah solusi utamanya. Menurut GitHub, proyek ini memiliki lebih dari 4.700 bintang per tahun 2026. Cara kerjanya adalah dengan “menebak” maksud dari string tersebut — menutup kurung yang hilang, menambahkan tanda kutip, dan membuang teks tambahan di sekitar blok JSON.

Python: Sebelum dan Sesudah

Instal: pip install json-repair

Input yang rusak:

import json_repair

bad_json = '{"user": "Alice", "status": tru'
decoded_object = json_repair.loads(bad_json)

Apa yang terjadi di balik layar: json_repair melihat bahwa tru kemungkinan adalah true, menambahkan kurung tutup yang hilang, dan mengembalikan dictionary Python yang valid. Tanpa intervensi manual sama sekali.

Mode Salvage: Saat Datanya Benar-benar Berantakan

Untuk kasus yang lebih sulit, json_repair (v0.59.5+) menyertakan Mode Salvage. Seperti yang dicatat dalam dokumentasi proyek, mode ini dibuat khusus untuk respons AI yang terpotong atau log yang rusak. Mode ini dapat memaksa array menjadi objek atau membuang item yang terlalu rusak untuk diselamatkan, memastikan output sesuai dengan skema Anda.

import json_repair

# Salvage mode for severely truncated data
result = json_repair.loads(
    '{"items": [{"id": 1, "name": "Widget"}, {"id": 2, "na',
    salvage_mode=True
)
# Result: {'items': [{'id': 1, 'name': 'Widget'}, {'id': 2}]}
# Dropped the incomplete 'na' but saved everything else

Alternatif npm

Untuk proyek Node.js, CLI jsonrepair menangani tugas yang sama:

# Fix a file in place
npx jsonrepair broken.json > fixed.json

# Fix a string in a script
const { jsonrepair } = require('jsonrepair');
const fixed = jsonrepair('{"name": "test",}');

Debugging Manual: Mencari Apa yang Melanggar Spesifikasi

Ketika otomatisasi tidak berhasil, Anda perlu menemukan dengan tepat di mana file tersebut melanggar RFC 8259. JSON jauh lebih tidak toleran dibandingkan YAML atau JavaScript. Seperti yang dijelaskan oleh Tim Diagnostik JSONParser, “Parser gagal pada karakter pertama yang tidak dapat dipahaminya, yang sering kali merupakan gejala hilir dari masalah beberapa baris sebelumnya.”

Tiga Pembunuh JSON

Pembunuh 1: Koma Ekstra

Menurut DEV Community, koma ekstra adalah penyebab utama kegagalan parsing. Koma ini tidak masalah di JavaScript, tetapi ilegal setelah item terakhir dalam array atau objek JSON.

// BROKEN - trailing comma after "active"
{
  "name": "Alice",
  "status": "active",
}

// FIXED - no comma before closing brace
{
  "name": "Alice",
  "status": "active"
}

Pembunuh 2: Kutip Tunggal

JSON mengharuskan tanda kutip ganda (") untuk key maupun nilai string. Banyak developer Python dan JavaScript secara tidak sengaja menggunakan kutip tunggal ('). Seperti yang dicatat TidyCode, ini adalah perbaikan yang wajib dilakukan.

// BROKEN - single quotes
{'name': 'Alice'}

// FIXED - double quotes
{"name": "Alice"}

Pembunuh 3: Key Tanpa Kutip

Di JavaScript Anda bisa menulis { name: "Alice" }. Di JSON, setiap key memerlukan tanda kutip ganda.

// BROKEN - unquoted key
{name: "Alice"}

// FIXED - quoted key
{"name": "Alice"}

Error “Unexpected Token”

Ketika validator menandai “Unexpected Token,” itu berarti parser menemukan NaN, Infinity, atau undefined — konstanta JavaScript yang tidak didukung JSON. JSON hanya mengizinkan null, true, false, dan angka.

// BROKEN - NaN is not valid JSON
{"score": NaN, "result": Infinity}

// FIXED - replace with null or valid values
{"score": null, "result": null}

Parsing Ketat vs. Parsing Perbaikan: Kapan Menggunakan yang Mana

Pendekatan yang tepat bergantung pada asal data Anda. File konfigurasi yang disunting manusia sebaiknya menggunakan parsing ketat untuk memaksa penulis memperbaiki kesalahan. Data yang dihasilkan mesin dari LLM atau log API memerlukan parsing berbasis perbaikan.

Fitur	Ketat (json.loads)	Perbaikan (json_repair)
Koma Ekstra	Memunculkan JSONDecodeError	Otomatis dihapus
Kutip Tunggal	Gagal	Dikonversi menjadi kutip ganda
Data Terpotong	Gagal	Menutup kurung/kutip yang terbuka
Komentar	Gagal	Otomatis dibuang
Kasus Penggunaan Terbaik	File konfigurasi hasil suntingan manusia	Output LLM, log API

Perbaikan Terbimbing Skema dengan Pydantic

Anda dapat membimbing proses perbaikan menggunakan Pydantic v2 atau JSON Schema. Dengan memberikan skema pada json_repair, alat ini tidak hanya memperbaiki sintaks — alat ini juga dapat mengoreksi tipe (mengubah string "1" menjadi angka 1) dan mengisi field wajib yang hilang dengan nilai default.

from pydantic import BaseModel
import json_repair

class User(BaseModel):
    id: int
    name: str
    active: bool = True

# Broken JSON with wrong types
raw = '{"id": "42", "name": "Alice"}'
repaired = json_repair.loads(raw)

# Validate against schema
user = User(**repaired)
# user.id is now int(42), user.active defaults to True

Seperti yang dicatat Stefano Baccianella dalam kutipan proyeknya tahun 2025, pendekatan ini dioptimalkan untuk JSON yang “sebagian besar benar tetapi secara teknis tidak valid” yang cenderung dihasilkan oleh model bahasa.

Menangani File Multi-Gigabyte Tanpa Crash

Memperbaiki cuplikan 10KB itu mudah. Memperbaiki file 2GB memerlukan strategi yang tidak akan memakan seluruh RAM Anda. Memuat seluruh file ke dalam memori menyebabkan error Out-of-Memory (OOM).

Strategi 1: Streaming dengan ijson

Untuk dataset raksasa, gunakan ijson untuk memproses data sebagian demi sebagian. Seperti yang disebutkan Scrapfly, ijson memproses data secara bertahap. Padukan dengan skrip pembersih yang memperbaiki masalah baris demi baris sebelum parsing.

import ijson

# Stream through a large JSON file
with open('huge_broken.json', 'r') as f:
    for item in ijson.items(f, 'records.item'):
        # Process each item individually
        process(item)

Strategi 2: Pipe CLI untuk Efisiensi Maksimal

Pendekatan paling hemat memori untuk file besar adalah menggunakan CLI jsonrepair dan meneruskan output langsung ke file baru:

# Streams repair, never loads full file into memory
jsonrepair large_broken.json > fixed.json

Ini jauh lebih hemat memori dibandingkan memuat file ke Python atau browser.

Kesimpulan

Memperbaiki JSON yang rusak bukan lagi pekerjaan manual berkat library yang sadar AI seperti json_repair. Anda tetap perlu memahami dasar-dasar RFC 8259 — tidak ada koma ekstra, tidak ada kutip tunggal, tidak ada key tanpa kutip — tetapi otomatisasi adalah satu-satunya pendekatan praktis untuk data dalam skala besar di tahun 2026.

Alur kerjanya sederhana: coba library perbaikan terlebih dahulu. Jika gagal, gunakan validator untuk menemukan error sintaks yang tepat. Hal ini menjaga aplikasi Anda tetap berjalan bahkan ketika data yang masuk kurang dari sempurna.

FAQ

Apakah JSON secara resmi mendukung komentar atau kutip tunggal?

Tidak. Standar RFC 8259 secara ketat melarang komentar. Kutip tunggal juga tidak valid — hanya tanda kutip ganda yang diizinkan untuk key dan string. Namun, alat seperti json_repair dapat membuang komentar dan mengonversi tanda kutip secara otomatis agar file dapat diurai oleh library standar.

Bagaimana cara menangani file JSON yang rusak dan sangat besar tanpa crash?

Gunakan parser streaming seperti ijson untuk memproses data dalam potongan-potongan. Hindari memuat seluruh string yang rusak ke dalam satu variabel. Untuk hasil tercepat, gunakan alat perbaikan CLI yang meneruskan output langsung ke file baru di disk tanpa menyimpan semuanya di memori.

Apa perbedaan antara JSON yang rusak (malformed) dan JSON yang tidak valid (invalid)?

JSON yang rusak melanggar aturan sintaks — kurung hilang, key tanpa kutip, koma ekstra — sehingga tidak mungkin diurai. JSON yang tidak valid mengikuti semua aturan sintaks tetapi gagal cocok dengan JSON Schema tertentu (misalnya, sebuah field berupa string padahal skema mengharapkan bilangan bulat). Memperbaiki JSON yang rusak adalah perbaikan struktural; memperbaiki JSON yang tidak valid berkaitan dengan integritas data.

Bisakah saya menggunakan json_repair bersama validasi Pydantic?

Bisa. Jalankan json_repair.loads() terlebih dahulu untuk memperbaiki error sintaks, lalu teruskan dictionary yang telah diperbaiki ke model Pydantic Anda untuk validasi tipe dan penegakan skema. Pendekatan dua langkah ini menangani masalah struktural maupun semantik.

Bagaimana dengan JSON dengan komentar gaya JavaScript?

JSON standar tidak mendukung komentar, tetapi json_repair dapat membuang komentar // dan /* */ secara otomatis. Jika Anda memerlukan komentar dalam file konfigurasi, pertimbangkan untuk menggunakan format JSONC (JSON dengan Komentar) dan parser yang kompatibel seperti json5 untuk Python.

Pernah merasa frustrasi saat output AI Anda sama sekali berbeda dari yang diminta? JSON-nya rusak, nadanya salah, dan separuh instruksi Anda diabaikan. Masalahnya bukan pada model — melainkan pada cara Anda memformat prompt.

Untuk menguasai cara membuat prompt AI dengan formatter, terapkan kerangka RTCCO (Role, Task, Context, Constraints, Output) menggunakan pemisah terstruktur seperti XML atau JSON. Pendekatan ini memperlakukan prompt sebagai aset perangkat lunak modular, yang dapat mengurangi halusinasi model hingga 60% dan memangkas waktu pemrosesan manual sebesar 75% per Mei 2026.

Mengapa Prompt Paragraf Anda Selalu Gagal

Pada 2026, pekerjaan AI profesional telah bergeser dari “mengobrol” menuju Prompt-as-Code (PaC). Masalah dengan prompt paragraf — blok teks panjang yang tidak terstruktur — adalah model kesulitan memisahkan instruksi Anda yang sebenarnya dari data latar belakang atau persyaratan output yang bercampur di dalamnya.

Data dari PromptOT menunjukkan bahwa beralih ke rekayasa terstruktur dapat memangkas kesalahan sebesar 60% dan mempercepat pemrosesan manual sebesar 75%. Alex Ostrovskyy menggambarkan prompt yang di-hardcode sebagai “padanan modern dari angka ajaib (magic numbers) dalam kode sumber” — sistem rapuh yang nyaris mustahil diperbarui tanpa merusak sesuatu.

Sebelum vs. Sesudah: Perbedaan Pemformatan

Sebelum (tidak terstruktur):

You are a helpful coding assistant. Please write a Python function that validates
email addresses. Make sure it handles edge cases like plus signs and subdomains.
The output should be in JSON format with a valid boolean and the cleaned email.
Also make sure you add proper error handling and don't forget logging.

Sesudah (RTCCO + pemisah XML):

<system_instructions>
  <role>Senior Python engineer specializing in input validation</role>
  <primary_objective>Write a production-grade email validator</primary_objective>
</system_instructions>

<context>
  Must handle: plus addressing ([email protected]), subdomains,
  internationalized domains. Target: Python 3.11+.
</context>

<task_requirements>
  <rules>
    - Use only stdlib (no regex shortcuts)
    - Return structured JSON
    - Include type hints
  </rules>
  <steps>
    1. Parse the input string
    2. Validate format per RFC 5322
    3. Return JSON with "valid" boolean and "cleaned_email"
  </steps>
</task_requirements>

<output_format>
  {"valid": bool, "cleaned_email": str, "error": str | null}
</output_format>

Tujuan yang sama, hasil yang jauh berbeda. Versi yang diformat memberikan model ruang nol untuk ambiguitas.

Kerangka RTCCO: Kerangka Prompt Anda

Industri telah menyepakati RTCCO sebagai arsitektur prompt standar. Setiap prompt dipecah menjadi lima bagian:

Elemen	Tujuan	Contoh
R ole (Peran)	Siapa AI-nya?	“Insinyur backend senior”
T ask (Tugas)	Tindakan spesifik apa?	“Tulis middleware pembatas laju”
C ontext (Konteks)	Data latar belakang apa?	Hasil RAG, cuplikan basis kode
C onstraints (Batasan)	Aturannya apa?	“Tanpa dependensi eksternal”
O utput (Keluaran)	Seperti apa bentuknya?	“Python 3.11 valid dengan type hints”

Template Kerangka XML yang Bisa Anda Salin Sekarang

Berikut adalah template siap produksi. Salin, sesuaikan, kirimkan.

<system_instructions>
  <role> [Expert Persona] </role>
  <primary_objective> [Main Goal] </primary_objective>
</system_instructions>

<context>
  [Background Data or RAG Retrieval]
</context>

<task_requirements>
  <rules> [Non-negotiable Constraints] </rules>
  <steps> [Specific Workflow] </steps>
</task_requirements>

<output_format>
  [JSON/XML/Markdown Specification]
</output_format>

<recency_recap>
  [Reminder of Critical Constraints]
</recency_recap>

Mengapa Recency Recap Penting

LLM memiliki bias “Primacy and Recency” yang sudah dikenal — mereka mengingat awal dan akhir prompt lebih baik daripada bagian tengah. Pengujian yang dikutip oleh PromptOT menunjukkan bahwa memindahkan aturan penting dari tengah ke blok Recency Recap di bagian bawah meningkatkan akurasi dari 78% menjadi 96% dalam penggunaan produksi. Letakkan Role di atas, dan aturan terpenting di bawah.

Pemisah sebagai Pagar Keamanan

Pemisah bukan hanya tentang organisasi — ini adalah mekanisme keamanan. Membungkus input pengguna dalam tag seperti <user_input> memberi tahu model: “Ini adalah data yang harus diproses, bukan instruksi baru yang harus diikuti.” Ini adalah pertahanan utama Anda terhadap serangan injeksi prompt di mana pengguna mencoba mengesampingkan instruksi sistem Anda.

Jebakan umum: Jika Anda menyuntikkan data pengguna langsung ke prompt tanpa pemisah, pengguna dapat menulis “Abaikan semua instruksi sebelumnya dan…” dan model akan menurut. Selalu bungkus data eksternal dalam blok bertag.

Arsitektur Modular: Berhenti Menulis Mega-Prompt

Alih-alih satu prompt 2.000 token yang rapuh, pecah sistem Anda menjadi modul-modul independen. Hal ini mencegah tabrakan instruksi — di mana mengubah nada prompt secara tak sengaja merusak format output JSON-nya.

Prinsip utamanya adalah Context Engineering: pisahkan instruksi statis dari data dinamis. Dalam sistem RAG produksi, prompt Anda adalah template di mana blok <context> diisi dengan data baru pada saat kueri. Seperti dijelaskan Jono Farrington dari OptizenApp, pendekatan modular ini membuat deployment AI skala besar jauh lebih konsisten.

Prompt Chaining: Menghubungkan Modul

Untuk alur kerja yang kompleks, gunakan Prompt Chaining — di mana output satu modul menjadi input untuk modul berikutnya:

[Planner Module] --> outline --> [Executor Module] --> draft --> [Reviewer Module] --> final

Pendekatan bertahap ini meningkatkan kualitas output sekitar 35% karena model hanya fokus pada satu sub-tugas pada satu waktu.

Contoh chaining yang bisa langsung digunakan:

planner_prompt = """
<system_instructions>
  <role>Technical architect</role>
  <task>Create a step-by-step plan for: {user_request}</task>
</system_instructions>
<output_format>JSON array of steps</output_format>
"""

executor_prompt = """
<system_instructions>
  <role>Senior developer</role>
  <task>Implement step: {step_from_planner}</task>
</system_instructions>
<context>{previous_outputs}</context>
<output_format>Code block with inline comments</output_format>
"""

Menambahkan Chain-of-Thought untuk Masalah Sulit

Saat tugas Anda melibatkan logika kompleks, tambahkan blok <thought_process>. Ini memaksa model untuk menalar langkah demi langkah sebelum memberikan jawaban, yang secara signifikan mengurangi kesalahan dalam matematika, pemrograman, dan penalaran multi-langkah.

<task_requirements>
  <rules>Reason inside <thought> tags before answering</rules>
</task_requirements>

<output_format>
  <thought> [Your step-by-step reasoning here] </thought>
  <answer> [Final JSON output here] </answer>
</output_format>

Menurut Zencoder, teknik seperti Tree-of-Thoughts (ToT) memperluas ini lebih jauh dengan meminta model mengevaluasi beberapa jalur solusi secara bersamaan dan memilih yang terbaik. Ini sangat berharga untuk keputusan arsitektural di mana tidak ada satu jawaban yang benar.

Peringatan Biaya Token

Penalaran terstruktur menggunakan lebih banyak token. Blok <thought_process> yang khas menambahkan 200-500 token per permintaan. Pada skala besar, ini berarti biaya API yang lebih tinggi. Imbalannya adalah akurasi: Anda membayar lebih per permintaan tetapi memerlukan lebih sedikit percobaan ulang dan koreksi manual.

Kesiapan Produksi: Versioning, Pengujian, dan CI/CD

Langkah terakhir adalah memperlakukan prompt seperti perangkat lunak. Gunakan Semantic Versioning (v1.0.0) agar tim Anda dapat melacak perubahan dan melakukan rollback secara instan saat versi prompt baru menurunkan kualitas.

PromptOT melaporkan bahwa perusahaan yang mengelola 50+ prompt dapat menghemat hingga $400.000 per tahun dengan memusatkan manajemen dan mengurangi waktu yang dihabiskan insinyur untuk menyesuaikan secara manual.

Menyiapkan Pipeline CI/CD Prompt

# .github/workflows/prompt-tests.yml
name: Prompt Quality Gate
on: [push]
jobs:
  test-prompts:
    runs-on: ubuntu-latest
    steps:
      - name: Run Golden Dataset Tests
        run: |
          # Test against 50-200 curated cases
          python scripts/eval_prompts.py \
            --dataset golden_dataset.json \
            --judge-model gpt-4 \
            --min-score 0.85

      - name: Regression Check
        run: |
          # Compare new version vs. production
          python scripts/compare_versions.py \
            --staging v2.1.0 \
            --production v2.0.3 \
            --threshold 0.05

Prompt hanya lulus dari Staging ke Production setelah melewati gerbang kualitas yang dinilai oleh “LLM-as-a-judge.”

Kesimpulan

Rekayasa prompt terstruktur dengan formatter bukan lagi opsional — ini adalah standar dasar bagi siapa pun yang membangun alat AI andal. Kerangka RTCCO, pemisah XML, dan arsitektur modular adalah tumpukan teknologi Anda untuk mengubah output LLM yang tidak dapat diprediksi menjadi hasil produksi yang konsisten dan siap produksi.

Mulailah dengan prompt yang paling sering Anda gunakan dan refaktor mereka ke dalam kerangka RTCCO menggunakan template XML di atas. Pindahkan ke kontrol versi, siapkan evaluasi dasar, dan Anda akan memiliki infrastruktur prompt yang dapat berkembang skala.

FAQ

Bagaimana cara mengubah prompt paragraf saya yang ada ke format blok RTCCO?

Pertama, identifikasi Task inti dan pisahkan dari Context. Bungkus instruksi dalam tag <rules> dan berikan 3-5 contoh dalam tag <examples>. Anda bahkan bisa menggunakan LLM untuk membantu — beri prompt “parse ulang teks tidak terstruktur ini ke dalam kerangka RTCCO menggunakan pemisah XML” dan ia akan melakukan pekerjaan berat untuk Anda.

Haruskah saya menggunakan pemisah XML, JSON, atau Markdown?

XML adalah standar emas saat ini untuk memisahkan instruksi dari konten panjang pada model seperti Claude dan GPT-5 karena hierarkinya yang ketat. JSON lebih baik ketika Anda memerlukan input/output terprogram untuk integrasi API. Markdown cocok untuk prompt sederhana yang mudah dibaca manusia, tetapi kurang memiliki definisi batas ketat yang diperlukan untuk prompt produksi kompleks dan berlapis.

Bagaimana cara menerapkan pengujian CI/CD otomatis untuk prompt?

Siapkan suite pengujian dengan “Golden Dataset” (50-200 kasus uji pilihan) dan “LLM-as-a-judge” untuk menilai output berdasarkan rubrik. Integrasikan pengujian ini ke dalam pipeline GitHub Actions atau Jenkins Anda sehingga setiap perubahan prompt divalidasi untuk akurasi dan nada sebelum deployment.

Apa kesalahan paling umum saat beralih ke prompt terstruktur?

Membebani blok <context>. Pengembang sering menumpahkan seluruh basis kode atau dokumen ke konteks, yang mengencerkan perhatian model. Jagalah agar konteks tetap fokus hanya pada apa yang langsung relevan dengan tugas. Jika Anda perlu merujuk dokumen besar, gunakan retrieval RAG untuk menarik hanya bagian yang relevan.