LLM Apps in Production (RAG + Vector DB + Caching) · บทเรียน

เลือกโมเดลที่เหมาะกับงาน

เลือกโมเดลที่เหมาะกับงาน เป็นบทเรียน LLM Apps in Production (RAG + Vector DB + Caching) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน LLM Apps in Production (RAG + Vector DB + Caching) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส LLM Apps in Production (RAG + Vector DB + Caching) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

Why Model Choice Drives Cost

In a RAG pipeline the LLM call is usually the single biggest cost and latency driver. The same prompt sent to a flagship model can cost 20-50x more than a small model.

Optimizing model selection is often the highest-leverage change you can make.

Token price differs per model
Latency scales with model size
Not every query needs the biggest brain

Model Tiers

Group your available models into tiers by capability and price:

Small / cheap — classification, extraction, simple Q&A
Mid — most RAG answers grounded in retrieved context
Large / flagship — multi-step reasoning, ambiguous queries

Default to the smallest tier that meets your quality bar.

A Simple Router

A router inspects the request and picks a model. Start with rule-based routing before adding ML.

def pick_model(query, context_len):
    if len(query) < 80 and context_len < 2000:
        return 'small-model'
    if 'explain' in query or 'compare' in query:
        return 'large-model'
    return 'mid-model'

print(pick_model('What is the price?', 500))

Model Cascades

A cascade tries a cheap model first, then escalates only if the answer is low confidence. Most queries resolve cheaply; only the hard ones reach the expensive model.

Run small model
Score confidence / check guardrails
Escalate only on failure

Cascade in Code

A minimal cascade with a confidence check.

def answer(query):
    cheap = call('small-model', query)
    if cheap['confidence'] >= 0.8:
        return cheap['text']
    return call('large-model', query)['text']

def call(model, query):
    return {'text': 'stub', 'confidence': 0.9}

print(answer('hello'))

Confidence Signals

How do you know the cheap answer is good enough? Useful signals:

Self-reported confidence from the model
Whether the answer cites retrieved context
Output length / refusal patterns
A small judge model scoring the answer

Matching Context Size to Model

Large context windows are expensive. A model that accepts 200k tokens charges you for every token you send. Trim retrieved chunks aggressively and reserve big windows for queries that truly need them.

Right-sizing context is part of right-sizing the model.

Measuring Quality per Tier

Before downgrading a model, measure quality on a fixed eval set. Track accuracy per tier so you know the real trade-off.

scores = {'small': 0.81, 'mid': 0.90, 'large': 0.93}
bar = 0.88
cheapest_ok = next(m for m, s in scores.items() if s >= bar)
print('Use:', cheapest_ok)

Cost vs Quality Curve

Plotting cost against quality usually shows diminishing returns: jumping to the flagship model buys a few points of accuracy at multiples of the cost.

Pick the point where quality crosses your acceptance bar at the lowest cost.

Fallbacks for Reliability

Routing also helps reliability. If your primary model is rate-limited or down, route to an alternative provider of similar tier so users still get answers.

Primary -> secondary provider
Same tier, comparable quality
Log which path served the request

Putting It Together

A production router combines: tier rules, a cascade for hard queries, context trimming, and provider fallbacks. Continuously evaluate so routing stays calibrated as models change.

Quick Check

Test your understanding of model cascades.

Recap

You learned to cut RAG cost and latency by choosing the right model: tier your models, default to the smallest that meets your bar, use cascades to escalate only hard queries, right-size context, and keep provider fallbacks for reliability. Always validate routing against an eval set.

คำถามที่พบบ่อย

บทเรียน “เลือกโมเดลที่เหมาะกับงาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “เลือกโมเดลที่เหมาะกับงาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส LLM Apps in Production (RAG + Vector DB + Caching) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส LLM Apps in Production (RAG + Vector DB + Caching) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “เลือกโมเดลที่เหมาะกับงาน”

เรียนรู้การลดค่าใช้จ่ายและเวลาแฝงของ RAG ด้วยการส่งคำขอแต่ละรายการไปยังโมเดลที่ถูกที่สุดซึ่งทำงานนั้นได้ดี โดยใช้ระดับโมเดล การส่งต่อเป็นลำดับ และด่านตรวจคุณภาพ คุณปฏิบัติ LLM Apps in Production (RAG + Vector DB + Caching) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน LLM Apps in Production (RAG + Vector DB + Caching) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน LLM Apps in Production (RAG + Vector DB + Caching) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “เลือกโมเดลที่เหมาะกับงาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน LLM Apps in Production (RAG + Vector DB + Caching) นี้ได้ไหม

ได้ บทเรียน LLM Apps in Production (RAG + Vector DB + Caching) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

วิศวกรรมพรอมต์เพื่อประสิทธิภาพ
การประมวลผลเป็นชุดและการดำเนินการแบบไม่พร้อมกัน
การติดตามต้นทุนและเวลาแฝง
เลือกโมเดลที่เหมาะกับงาน

← กลับไปที่ LLM Apps in Production (RAG + Vector DB + Caching)