LLM sebagai Juri: Panduan Lengkap dengan Contoh RAG Praktis

Membandingkan pendekatan LLM-sebagai-juri

Dalam praktiknya, tim biasanya memilih salah satu dari pendekatan berikut tergantung pada apa yang ingin mereka ukur:

1. Penilaian langsung membuat juri memberi nilai pada satu keluaran dalam skala numerik (1 sampai 5, 1 sampai 10, sesuai rubrik Anda). Anda mendapatkan angka dan, jika Anda memintanya, penjelasan tertulis tentang alasannya. Ini adalah titik awal yang paling umum, meski ada masalah kalibrasi yang akan saya bahas nanti.
2. Perbandingan berpasangan menempatkan dua respons kandidat berdampingan dan meminta juri memilih yang lebih baik. Ini sepenuhnya menghindari masalah kalibrasi numerik karena juri hanya perlu membuat keputusan relatif, bukan memberi angka absolut. Tim sering menggunakan ini saat membandingkan varian prompt atau versi model satu sama lain.
3. Evaluasi berbasis referensi memberikan keluaran model dan jawaban standar emas kepada juri, lalu menanyakan seberapa cocok keluarannya. Ini paling cocok untuk tanya jawab faktual dan keluaran terstruktur ketika Anda sudah memiliki ground truth berlabel untuk dibandingkan.
4. Klasifikasi biner mereduksi penilaian menjadi lulus atau gagal pada satu sifat spesifik. Apakah respons ini setia pada konteks? Apakah mengandung informasi identitas pribadi? Apakah bernada positif? Pemeriksaan biner ini lebih cepat dijalankan, lebih murah per evaluasi, dan cenderung menghasilkan hasil yang lebih konsisten daripada pendekatan numerik.

Gambar oleh Penulis. Empat pendekatan berbeda LLM sebagai juri. 

Untuk gambaran langsung tentang kelebihan, kasus penggunaan, dan batasannya, saya membandingkan keempat pendekatan dalam tabel berikut:

Untuk tinjauan yang lebih luas atas pendekatan evaluasi di luar pola juri, Penjelasan Tolok Ukur LLM membahas gambaran lengkapnya.

Bagaimana Cara Kerja Juri LLM?

Di balik layar, ini hanyalah panggilan API sederhana karena Anda hanya perlu mengemas konten yang ingin dievaluasi (keluaran model, kueri pengguna asli, dan konteks apa pun yang diambil dan digunakan saat generasi) dan membungkusnya dalam prompt yang memberi tahu model juri apa yang Anda pedulikan dan bagaimana Anda ingin hasilnya diformat. 

Juri memproses ini dan mengembalikan respons terstruktur, biasanya berupa skor disertai alasan tertulis yang menjelaskan mengapa ia memberikan skor tersebut. Kualitas evaluasi Anda hampir sepenuhnya bergantung pada seberapa baik Anda menulis rubriknya. Saya tidak bisa melebih-lebihkan hal ini. 

Prompt sederhana yang mengatakan "nilai respons ini dari 1 sampai 5" akan memberi Anda skor yang acak, karena juri tidak memiliki pemahaman bersama tentang apa arti 3 dibandingkan 4. Inilah sebabnya Anda perlu menjabarkan, secara konkret, seperti apa setiap level skor dan sertakan contoh jika memungkinkan.

Menerapkan LLM sebagai Juri

Sekarang ke bagian praktik langsung, kita akan membangun pipeline evaluasi lengkap dari nol: sebuah retrieval augmented generation (RAG) yang menjawab pertanyaan dari basis pengetahuan kecil, satu set kueri uji yang dirancang untuk memicu berbagai mode kegagalan, dan juri LLM yang memberi skor keluaran berdasarkan ketepatan terhadap konteks dan relevansi jawaban.

Menyiapkan lingkungan

Anda memerlukan Python 3.9+ dan kunci API OpenAI, yang bisa Anda dapatkan di konsol OpenAI. Instal dependensi berikut:

pip install openai chromadb langchain langchain-openai langchain-community deepeval

Atur kunci API Anda:

import os
os.environ["OPENAI_API_KEY"] = "your-key-here"

Kita menggunakan OpenAI untuk generator RAG dan juri LLM, meskipun modelnya berbeda (GPT-4o-mini untuk generasi, GPT-4o untuk penjurian). Untuk embedding, text-embedding-3-small sudah cukup untuk cakupan tutorial. Dalam sistem produksi, Anda perlu membandingkan beberapa model embedding pada data domain spesifik Anda sebelum memilih satu.

Jika Anda ingin memperdalam latar belakang RAG sebelum masuk ke kode evaluasi, kursus Retrieval Augmented Generation (RAG) dengan LangChain akan membahas dasar-dasarnya.

Menyiapkan data dan vector store

Kita memerlukan basis pengetahuan kecil untuk diambil oleh sistem RAG. Saya akan menggunakan serangkaian potongan teks tentang kebijakan pengembalian perusahaan fiksi. Kontennya sendiri bukan fokusnya, tetapi memiliki kumpulan dokumen yang terbatas memudahkan kita melihat kapan model melampaui konteks yang diberikan (yang merupakan mode kegagalan yang ingin kita tangkap dengan juri).

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
from langchain.schema import Document

# Sample knowledge base
documents = [
    Document(
        page_content="All customers are eligible for a full refund within 30 days of purchase. "
        "The item must be in its original packaging and unused condition. Refunds are "
        "processed to the original payment method within 5-7 business days.",
        metadata={"source": "return_policy.pdf", "section": "refund_eligibility"}
    ),
    Document(
        page_content="Exchanges can be requested within 45 days of purchase for items of "
        "equal or lesser value. Size exchanges on clothing are free of charge. "
        "For items of greater value, the customer pays the difference.",
        metadata={"source": "return_policy.pdf", "section": "exchanges"}
    ),
    Document(
        page_content="Electronics have a 15-day return window due to rapid depreciation. "
        "Opened software and digital downloads are non-refundable. Defective electronics "
        "can be returned within 90 days with proof of defect from an authorized service center.",
        metadata={"source": "return_policy.pdf", "section": "electronics"}
    ),
    Document(
        page_content="Shipping costs for returns are covered by the company for defective items. "
        "For non-defective returns, the customer is responsible for return shipping. "
        "Free return shipping labels are available for loyalty program members regardless of reason.",
        metadata={"source": "return_policy.pdf", "section": "shipping"}
    ),
    Document(
        page_content="Gift purchases can be returned with the gift receipt for store credit only. "
        "Without a gift receipt, returns are processed at the lowest sale price in the last 90 days. "
        "Gift cards and prepaid cards are non-refundable and cannot be exchanged.",
        metadata={"source": "return_policy.pdf", "section": "gifts"}
    ),
]

# Create vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(documents, embeddings, persist_directory="./chroma_db")

print(f"Indexed {len(documents)} documents")

Lima dokumen tentang kebijakan pengembalian, meskipun tidak banyak, namun cukup untuk menunjukkan masalah pengambilan yang kita pedulikan: konteks yang tidak lengkap, potongan yang tidak relevan ikut tertarik, dan peluang halusinasi yang muncul saat model merasa perlu memberikan jawaban lengkap meski konteksnya tidak sepenuhnya mendukung.

Membangun pipeline RAG dasar

Pipeline RAG mengambil potongan relevan dan menghasilkan jawaban. Tidak ada yang rumit di sini, hanya pola standar ambil-lalu-hasilkan.

from openai import OpenAI

client = OpenAI()

def rag_query(question: str, top_k: int = 2) -> dict:
    """Run a RAG query: retrieve context, generate answer."""
    
    # Retrieve
    results = vectorstore.similarity_search(question, k=top_k)
    context = "\n\n".join([doc.page_content for doc in results])
    
    # Generate
    system_prompt = """You are a helpful customer support assistant. Answer the 
    customer's question based ONLY on the provided context. If the context doesn't 
    contain enough information to answer fully, say so."""
    
    user_prompt = f"""
      Context: {context}

      Question: {question}

      Answer:
    """
    
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.3
    )
    
    answer = response.choices[0].message.content
    
    return {
        "question": question,
        "context": context,
        "answer": answer,
        "sources": [doc.metadata for doc in results]
    }

Saya memilih GPT-4o-mini sebagai generator karena murah dan cepat, dan kita ingin fokus pada evaluasinya. Suhu di 0,3, yang mengurangi keacakan tetapi tidak menghilangkannya. 

Dan prompt sistem secara eksplisit menginstruksikan model untuk hanya menggunakan konteks yang diberikan, yang merupakan praktik standar dalam sistem RAG, meskipun model masih sering keluar dari konteks lebih sering daripada yang Anda kira. Itulah yang ingin kita tandai dengan juri.

Mari kita uji:

result = rag_query("Can I return opened software?")
print(f"Question: {result['question']}")
print(f"Answer: {result['answer']}")
print(f"Sources: {result['sources']}")

Membuat dataset evaluasi

Anda memerlukan kasus uji yang menguji berbagai bagian pipeline. Di produksi, Anda akan mengumpulkannya dari kueri pengguna nyata. Untuk tutorial ini, saya membuat campuran yang dengan sengaja memasukkan jenis pertanyaan di mana sistem RAG cenderung tersandung.

eval_questions = [
    # Straightforward questions (should be easy)
    "What is the refund window for regular purchases?",
    "Are exchanges free for clothing size changes?",
    
    # Questions requiring synthesis across chunks
    "What are my options if I received a defective laptop 60 days ago?",
    
    # Edge cases likely to cause hallucination
    "Can I get a refund for a digital download I purchased yesterday?",
    "What happens if I return a gift without the gift receipt?",
    
    # Questions where context might be incomplete
    "Do you offer refunds for international orders?",
    "Can I return an item I bought on sale?",
    
    # Adversarial or tricky questions
    "If I'm a loyalty member, do I get free return shipping even for electronics?",
]

# Generate RAG responses for all questions
eval_results = []
for q in eval_questions:
    result = rag_query(q)
    eval_results.append(result)
    print(f"Q: {q}")
    print(f"A: {result['answer'][:150]}...")
    print()

Komposisinya penting. Beberapa pertanyaan memiliki jawaban yang bersih dan langsung dalam dokumen, sementara beberapa membutuhkan model untuk menggabungkan informasi di berbagai potongan yang diambil (pertanyaan tentang laptop cacat memerlukan kebijakan pengembalian umum 30 hari dan jangka waktu cacat elektronik 90 hari). 

Dan beberapa di antaranya, seperti pertanyaan pesanan internasional, menanyakan hal-hal yang memang tidak tercakup dalam basis pengetahuan. Pertanyaan-pertanyaan terakhir ini adalah tempat Anda akan paling sering melihat halusinasi, karena model terdorong untuk membantu dan mengisi celah dengan informasi yang terdengar masuk akal tetapi tidak memiliki landasan dalam konteks sebenarnya.

Untuk informasi lebih lanjut tentang membangun dan menguji sistem RAG, pilihan 30 Pertanyaan dan Jawaban Wawancara RAG Teratas kami dapat menjadi referensi yang berguna.

Menyiapkan juri LLM

Di sinilah menjadi menarik. Kita membangun dua juri terpisah: 

• Juri ketepatan terhadap konteks (faithfulness): Apakah jawaban tetap dalam batas konteks yang diambil?
• Juri relevansi: Apakah respons benar-benar menjawab apa yang ditanyakan?

def judge_faithfulness(question: str, context: str, answer: str) -> dict:
    """Judge whether the answer is faithful to the retrieved context."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's 
      answer is faithful to the provided context. 

      Faithfulness means every claim in the answer can be traced back to 
      information in the context. The answer should not contain information 
      that isn't supported by or inferable from the context.

      Score on a scale of 1 to 5:
      1 - The answer contains multiple claims not supported by the context
      2 - The answer contains at least one significant unsupported claim
      3 - The answer is mostly faithful but includes minor unsupported details
      4 - The answer is faithful with only trivial extrapolations
      5 - Every claim in the answer is directly supported by the context

      Context: {context}

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)


def judge_relevance(question: str, answer: str) -> dict:
    """Judge whether the answer is relevant to the question."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's answer 
      is relevant to the user's question.

      Relevance means the answer directly addresses what the user asked. 
      A relevant answer may acknowledge limitations in available information, 
      but it should not go off-topic or provide unrelated information.

      Score on a scale of 1 to 5:
      1 - The answer does not address the question at all
      2 - The answer partially addresses the question but misses the main point
      3 - The answer addresses the question but includes significant irrelevant content
      4 - The answer addresses the question well with minor tangents
      5 - The answer directly and completely addresses the question

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)

Beberapa pilihan desain yang perlu disorot. temperature disetel ke 0.0 untuk konsistensi maksimum antar-run. Kita menggunakan response_format={"type": "json_object"} agar keluarannya selalu bisa diurai.

Rubrik menggambarkan setiap level skor secara konkret alih-alih menggunakan label samar seperti "baik" atau "buruk." Tanpa tingkat spesifisitas itu, saya mendapati juri cenderung memberi semua nilai 3 atau 4, yang tidak memberi informasi berguna.

Perhatikan bahwa GPT-4o yang melakukan penjurian meski GPT-4o-mini yang melakukan generasi. Membuat juri lebih mumpuni daripada generator adalah pola umum karena juri perlu kepatuhan instruksi yang kuat untuk menerapkan rubrik secara konsisten. 

Jika Anda menggunakan model yang sama untuk kedua peran, Anda juga memperkenalkan bias preferensi diri yang terdokumentasi di mana model menilai keluarannya sendiri lebih baik.

Menjalankan loop evaluasi

Saatnya menjalankan semuanya dan mengumpulkan hasilnya.

import json

evaluation_report = []

for result in eval_results:
    # Run both judges
    faithfulness = judge_faithfulness(
        result["question"], result["context"], result["answer"]
    )
    relevance = judge_relevance(
        result["question"], result["answer"]
    )
    
    evaluation_report.append({
        "question": result["question"],
        "answer": result["answer"][:200],
        "faithfulness_score": faithfulness["score"],
        "faithfulness_reason": faithfulness["reason"],
        "relevance_score": relevance["score"],
        "relevance_reason": relevance["reason"],
    })
    
    print(f"Q: {result['question']}")
    print(f"  Faithfulness: {faithfulness['score']}/5 | Relevance: {relevance['score']}/5")
    print(f"  Faith reason: {faithfulness['reason'][:100]}...")
    print()

# Summary statistics
faith_scores = [r["faithfulness_score"] for r in evaluation_report]
rel_scores = [r["relevance_score"] for r in evaluation_report]
print(f"Average faithfulness: {sum(faith_scores)/len(faith_scores):.2f}")
print(f"Average relevance: {sum(rel_scores)/len(rel_scores):.2f}")
print(f"Questions with faithfulness < 3: {sum(1 for s in faith_scores if s < 3)}")

Setiap pertanyaan memicu dua panggilan API ke GPT-4o, satu per juri. Untuk delapan pertanyaan uji kita, total ada enam belas panggilan evaluasi, yang masih terkelola. Di produksi dengan ribuan kueri harian, Anda perlu membuat batch, menjalankannya secara asinkron, dan kemungkinan hanya mengevaluasi sampel alih-alih setiap respons.

Menganalisis hasil dan melakukan iterasi

Skor numerik memberi gambaran umum, tetapi alasannyalah yang memberi tahu apa yang sebenarnya harus diperbaiki.

# Find problematic responses
print("=== LOW FAITHFULNESS (score < 4) ===")
for r in evaluation_report:
    if r["faithfulness_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['faithfulness_score']}")
        print(f"Reason: {r['faithfulness_reason']}")
        print(f"Answer preview: {r['answer'][:150]}...")

print("\n=== LOW RELEVANCE (score < 4) ===")
for r in evaluation_report:
    if r["relevance_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['relevance_score']}")
        print(f"Reason: {r['relevance_reason']}")

Pertanyaan pesanan internasional dan barang diskon hampir pasti mendapat skor rendah pada ketepatan terhadap konteks, karena basis pengetahuan tidak membahas topik tersebut, dan model kemungkinan berimprovisasi.

Pertanyaan laptop cacat juga menarik karena memerlukan sintesis informasi dari kebijakan pengembalian umum (30 hari) dengan klausul cacat elektronik (90 hari untuk barang cacat dengan bukti), dan bergantung pada potongan mana yang diambil, model mungkin memiliki gambaran yang lengkap atau tidak.

Apa yang Anda lakukan dengan hasil bergantung pada temuan Anda. Ketepatan rendah pada kategori pertanyaan tertentu biasanya mengarah pada dua hal: baik pengambil menarik potongan yang salah (masalah retrieval), atau generator melampaui konteks yang diberikan (masalah generasi). 

Melihat konteks yang diambil berdampingan dengan jawaban memberi tahu Anda mana yang sedang dihadapi. Skor relevansi rendah, di sisi lain, biasanya berarti prompt sistem perlu disetel, atau konteks yang diambil begitu tidak relevan sehingga model tidak punya bahan berguna.

Untuk sisi operasional menjalankan evaluasi sebagai bagian dari pipeline pengelapan, kursus Konsep LLMOps membahas infrastruktur dan pola alur kerja.

Menggunakan DeepEval untuk evaluasi terstruktur

Menulis fungsi juri kustom berfungsi, tetapi untuk penggunaan produksi, Anda mungkin menginginkan kerangka kerja yang menangani boilerplate. DeepEval adalah salah satu opsi yang lebih matang, dan hadir dengan implementasi metrik yang teruji baik yang mencakup kriteria evaluasi paling umum.

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric

# Configure metrics
faithfulness_metric = FaithfulnessMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

relevance_metric = AnswerRelevancyMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

# Create test cases from our RAG results
test_cases = []
for result in eval_results:
    test_case = LLMTestCase(
        input=result["question"],
        actual_output=result["answer"],
        retrieval_context=[result["context"]]
    )
    test_cases.append(test_case)

# Run evaluation
evaluate(
    test_cases=test_cases,
    metrics=[faithfulness_metric, relevance_metric]
)

Yang Anda dapatkan dari DeepEval—yang melelahkan jika dibangun sendiri: 

• Logika retry saat juri mengembalikan JSON yang salah format (yang terjadi lebih sering dari yang Anda kira)
• Cache hasil sehingga menjalankan evaluasi ulang tidak menggandakan tagihan API Anda
• Integrasi Pytest yang memungkinkan Anda menghubungkan evaluasi LLM langsung ke pipeline CI/CD. 

Setiap metrik juga menghasilkan penjelasan diri, yang berarti setiap skor disertai uraian tertulis tentang alasan juri yang bisa Anda periksa saat ada yang janggal.

Untuk tinjauan lebih mendalam tentang kapabilitas penuh DeepEval, lihat Evaluasi LLM Secara Efektif Menggunakan DeepEval.

Praktik Terbaik LLM sebagai Juri

Membuat juri LLM mengembalikan angka itu mudah. Membuat angka-angka itu benar-benar bermakna bagi tim Anda memerlukan perhatian lebih dari yang biasanya diperkirakan orang.

Kerangka evaluasi dan metrik

Selain DeepEval, saat ini ada beberapa kerangka untuk dipilih, dan lanskapnya terus berkembang. Berikut perbandingan praktis berdasarkan di mana masing-masing paling cocok:

Untuk sistem RAG, empat metrik berikut biasanya sudah mencakup sebagian besar kebutuhan praktis.

1. Ketepatan terhadap konteks (faithfulness) memberi tahu apakah jawaban yang dihasilkan tetap berpijak pada konteks yang diambil. Jika skornya 0,6, artinya kira-kira 40% klaim dalam jawaban tidak mendapat dukungan dari dokumen yang disediakan. Ini adalah detektor halusinasi utama, dan menurut pengalaman saya, ini metrik terpenting untuk dilacak secara berkelanjutan.
2. Relevansi jawaban menangkap apakah respons benar-benar menjawab apa yang diminta, yang merupakan isu berbeda sama sekali. Respons bisa sangat setia pada konteks (setiap klaim terverifikasi) namun tetap meleset dari inti pertanyaan.
3. Presisi konteks melihat sisi pengambilan: apakah dokumen relevan diperingkatkan di dekat bagian atas hasil? Jika dokumen yang berisi jawaban berada di posisi 5 dari 5, pengambilan Anda secara teknis berfungsi, tetapi peringkatnya buruk, dan itu memengaruhi kualitas generasi karena model lebih memperhatikan apa yang muncul pertama dalam jendela konteks.
4. Recall konteks melihat dari arah lain dan memeriksa seberapa banyak informasi yang dibutuhkan untuk menjawab pertanyaan benar-benar diambil. Recall rendah adalah masalah infrastruktur pengambilan, dan tidak ada rekayasa prompt di sisi generasi yang dapat menutupi konteks yang memang tidak ada.

Anda ingin menjalankannya bersama-sama karena kombinasi skor tinggi dan rendah yang berbeda mengarah ke akar masalah yang berbeda.

• Ketepatan tinggi dengan relevansi rendah berarti model mencerminkan konteks secara akurat, tetapi konteksnya sendiri tidak relevan dengan pertanyaan. 
• Ketepatan rendah dengan relevansi tinggi berarti model memahami pertanyaan tetapi melampaui konteks yang diberikan untuk menjawabnya. 

Setiap kombinasi memberi tahu Anda di mana harus mencari perbaikannya.

Untuk latihan langsung dengan pelacakan evaluasi di MLflow, Evaluating LLMs with MLflow membahas integrasinya.

Praktik terbaik penerapan produksi

Penerapan produksi memerlukan pemikiran lebih daripada menjalankan evaluasi dalam notebook, dan masalah praktis dalam skala besar cenderung jatuh ke lima kategori yang pantas dibahas sebelum Anda berkomitmen pada pendekatan ini.

1. Rencanakan menghadapi bias yang diketahui. Juri LLM secara konsisten memberi nilai lebih tinggi pada respons yang lebih panjang (bias verbositas) dan cenderung sedikit memihak respons yang muncul pertama dalam perbandingan berpasangan (bias posisi). Mitigasi standar untuk bias posisi adalah menjalankan setiap perbandingan berpasangan dalam dua urutan dan hanya menghitung hasil ketika juri konsisten pada keduanya. Untuk verbositas, Anda dapat menambahkan bahasa eksplisit pada rubrik bahwa keringkasan dapat diterima atau bahkan diutamakan, meski ini lebih mengurangi efeknya daripada menghilangkannya sepenuhnya.
2. Kalibrasikan terhadap penilaian manusia sebelum mempercayai skor. Kumpulkan 50 hingga 100 contoh yang sudah dinilai peninjau manusia pada domain spesifik Anda, jalankan melalui juri, dan periksa tingkat kesepakatan, dengan apa pun di bawah 75% menandakan rubrik perlu diperjelas kriterianya. Ingat untuk mengulang langkah kalibrasi ini secara berkala karena baik model juri maupun aplikasi Anda berevolusi dari waktu ke waktu, artinya tingkat kesepakatan yang tampak solid enam bulan lalu mungkin sudah bergeser seiring perubahan prompt, data, atau versi model Anda.
3. Periksa konsistensi terpisah dari akurasi. Jalankan input yang sama melalui juri dua kali dan bandingkan keluarannya, karena jika sebuah respons mendapat 3 pada satu run dan 5 pada run berikutnya, rubrik Anda terlalu longgar, dan juri menafsirkannya berbeda tiap kali. Dalam kasus itu, evaluasi lulus/gagal biner cenderung menghasilkan hasil yang lebih andal lintas-run daripada skala 5 poin, jadi pertimbangkan untuk mengubah skor numerik menjadi biner untuk pemantauan produksi sambil mempertahankan skala granular untuk analisis offline di mana inkonsistensi sesekali tidak terlalu merugikan.
4. Kelola biaya dalam skala besar. Prompt evaluasi jauh lebih panjang daripada prompt generasi biasa karena perlu mencakup pertanyaan asli, konteks yang diambil penuh, jawaban yang dihasilkan, dan rubrik lengkap dengan kriteria penilaian. Untuk sistem volume tinggi, pola hemat biaya yang umum adalah menjalankan evaluasi LLM mendetail pada sampel acak 10% kueri sambil menerapkan pemeriksaan otomatis yang lebih sederhana (panjang, kepatuhan format, keberadaan kata kunci) pada 90% lalu lintas sisanya.
5. Libatkan manusia dalam loop. Bahkan setelah juri bekerja dengan baik di produksi, siapkan proses tinjauan rutin di mana seseorang dari tim memeriksa sampel acak evaluasi juri setiap minggu. Perhatikan secara khusus respons yang diberi nilai sempurna (5/5) karena justru pada kasus-kasus itulah isu yang terlewat akan menciptakan keyakinan yang salah pada jawaban yang keliru.

Untuk pembahasan lebih lanjut tentang operasionalisasi alur kerja LLM end-to-end, jalur Associate AI Engineer for Data Scientists membahas gambaran penerapan penuh.

Kesimpulan

LLM-sebagai-juri mengisi kebutuhan praktis yang tidak dapat ditangani oleh metrik otomatis tradisional maupun tinjauan manusia dalam skala besar secara mandiri. Metrik otomatis melewatkan hal-hal yang benar-benar penting bagi aplikasi LLM; sebaliknya, evaluasi manusia menangkap yang penting tetapi tidak sanggup mengikuti volume sistem produksi. 

Juri LLM di tengah-tengah memberi Anda cara untuk terus memantau kualitas keluaran dengan nuansa yang tidak bisa disediakan metrik sederhana.

Kita membangun pipeline lengkap dalam tutorial ini: sistem RAG dengan basis pengetahuan kecil, kueri uji yang dirancang untuk memicu berbagai mode kegagalan, juri evaluasi kustom untuk ketepatan dan relevansi, serta pendekatan berbasis kerangka menggunakan DeepEval yang lebih dekat dengan apa yang akan Anda jalankan di produksi.

Jika ada satu hal yang perlu diingat dari semuanya, rubrik adalah segalanya. Karena itu, investasikan waktu untuk menulis kriteria evaluasi yang spesifik dan konkret dengan contoh jelas untuk setiap level skor. Rubrik yang dirancang baik dengan model biasa-biasa saja akan mengungguli rubrik samar dengan model paling mumpuni setiap saat.

Jika Anda ingin terus membangun dari sini:

• Membangun Sistem RAG dengan LangChain dan FastAPI membawa pipeline RAG dari notebook ke layanan produksi.
• Developing LLM Applications with LangChain membahas alur kerja pengembangan aplikasi yang lebih luas, termasuk chains, agents, dan memori.
• Introduction to LLMs in Python layak ditinjau kembali jika Anda ingin memantapkan fondasi sebelum melangkah lebih jauh.
• 12 Proyek LLM untuk Semua Tingkat memberi Anda lebih banyak ide proyek untuk latihan.
• Apa itu Retrieval Augmented Generation (RAG)? membahas landasan konseptual RAG lebih dalam.