เลือกโมเดลให้เหมาะกับงาน

6.1 เริ่มจากข้อจำกัด ไม่ใช่จาก leaderboard

คำถามที่ต้องตอบตามลำดับนี้ ก่อนจะไปดูว่าโมเดลไหนคะแนนสูง

#	คำถาม	สิ่งที่คำตอบตัดออก
1	ข้อมูลออกนอกองค์กรได้ไหม	ถ้าไม่ได้ ตัดตัวเลือก API ทิ้งทั้งหมด
2	ต้องตอบเร็วแค่ไหน	ต้องได้ใน 1 วินาที หรือรอ 30 วินาทีก็ได้
3	มีคนใช้พร้อมกันกี่คน	กำหนดว่าต้องใช้ตัวรันแบบไหนและ VRAM เท่าไร
4	ฮาร์ดแวร์ที่มีคืออะไร	กำหนดขนาดโมเดลสูงสุดที่เป็นไปได้
5	งบต่อเดือนเท่าไร	เทียบต้นทุน API กับต้นทุนรันเอง
6	ภาษาไทยสำคัญแค่ไหน	ตัดโมเดลที่อ่อนภาษาไทยออก แม้คะแนนอังกฤษจะสูง
7	งานคืออะไรกันแน่	เพิ่งมาถึงข้อนี้ค่อยเลือกประเภทและขนาด

ข้อ 1–6 มักตัดตัวเลือกไปเกิน 90% ก่อนที่จะได้ดูคะแนนด้วยซ้ำ

6.2 ตารางงาน → โมเดลที่ควรใช้

งาน	ประเภทที่ต้องใช้	ขนาดที่พอ	หมายเหตุ
จำแนกข้อความเป็นหมวด	LLM เล็ก หรือ classifier	0.5–3B	งานนี้ไม่ต้องใช้โมเดลใหญ่เลย โมเดลเล็กที่ fine-tune แล้วมักแม่นกว่าและถูกกว่ามาก
สกัดข้อมูลเป็น JSON	LLM + structured output	3–8B	ใช้ตัวรันที่บังคับ schema ได้ จะแม่นขึ้นมากโดยไม่ต้องใช้โมเดลใหญ่
สรุปและเขียนใหม่	LLM	8–14B	ถ้าต้องการภาษาไทยที่ลื่นจริง ให้เผื่อขนาดขึ้นไปหรือเลือกตัวที่ฝึกภาษาไทยมาโดยเฉพาะ
ตอบคำถามจากเอกสาร	Embedding + Reranker + LLM	8–14B	คุณภาพขึ้นกับการค้นมากกว่าขนาดของ LLM ลงทุนที่ retrieval ก่อน
เขียนโค้ด	LLM สาย Coder	14–32B ขึ้นไป	งานนี้ขนาดมีผลชัดเจน โมเดลเล็กจะเขียนโค้ดที่ดูถูกแต่รันไม่ผ่าน
คณิต / ตรรกะซับซ้อน	Reasoning model	14B ขึ้นไป	โมเดล reasoning ขนาดกลาง มักชนะโมเดลธรรมดาที่ใหญ่กว่าในงานประเภทนี้
อ่านเอกสารสแกน / ใบเสร็จ	VLM	2–8B	VLM เล็กที่ฝึกงาน OCR มาโดยเฉพาะ มักดีกว่า VLM ทั่วไปที่ใหญ่กว่า
ถอดเสียง	ASR	ไม่เกี่ยวกับ B	เลือกจากความแม่นในภาษาที่ใช้ ไม่ใช่จากจำนวนพารามิเตอร์
ค้นหาเชิงความหมาย	Embedding	0.3–1B	เลือกตัวที่รองรับหลายภาษาและมิติเวกเตอร์ที่ฐานข้อมูลของคุณรับได้
ทำนายตัวเลขจากตาราง	ไม่ใช่ LLM	—	ใช้ XGBoost หรือ LightGBM แม่นกว่า เร็วกว่า อธิบายได้ และรันบน CPU

6.3 กฎเดียวที่ใช้ได้เสมอ

เลือกโมเดลที่เล็กที่สุดที่ผ่านชุดทดสอบของคุณ

ไม่ใช่โมเดลที่ดีที่สุดในตาราง leaderboard เพราะโมเดลเล็กกว่าหมายถึงตอบเร็วกว่า ถูกกว่า รันหลายตัวพร้อมกันได้ และเหลือ VRAM ไว้ทำอย่างอื่น

วิธีปฏิบัติคือ เริ่มจากตัวที่เล็กเกินไปแน่ ๆ แล้วไต่ขึ้นทีละขั้นจนผ่านเกณฑ์ แล้วหยุด อย่าเริ่มจากตัวใหญ่แล้วค่อยลด เพราะคุณจะไม่มีวันได้ลดจริง

6.4 สร้างชุดทดสอบของตัวเอง — ขั้นตอนที่คนข้ามบ่อยที่สุด

คะแนนบน leaderboard สาธารณะบอกได้แค่ว่าโมเดลเก่งงานทั่วไปแค่ไหน มันไม่บอกว่าโมเดลจะเก่ง งานของคุณ แค่ไหน และมีปัญหาการปนเปื้อนของชุดทดสอบที่ทำให้คะแนนสูงเกินจริงอยู่เสมอ ทางแก้คือชุดทดสอบเล็ก ๆ ที่คุณทำเอง

{"id":"ocr-01","input":"[ภาพใบเสร็จ]","expect":{"vendor":"ร้านค้า ก","total":1250.00},"why":"เคสปกติ"}
{"id":"ocr-02","input":"[ภาพเอียง 15 องศา]","expect":{"total":890.50},"why":"ภาพถ่ายมือ"}
{"id":"ocr-03","input":"[ใบเสร็จมีลายน้ำ]","expect":{"total":2100.00},"why":"เคสที่เคยพลาด"}
{"id":"sum-01","input":"บทความ 2000 คำ...","expect_contains":["ประเด็นหลัก A","ตัวเลข 45%"],"why":"ต้องไม่ตกตัวเลข"}
{"id":"neg-01","input":"คำถามนอกขอบเขต","expect_behavior":"ปฏิเสธ","why":"ต้องไม่มั่ว"}

หลักการเลือกตัวอย่าง:

• 60% เคสปกติที่เจอบ่อยที่สุด
• 30% เคสยากที่เคยพลาดจริง — มีค่าที่สุด เก็บทุกครั้งที่เจอ
• 10% เคสที่โมเดลควรปฏิเสธหรือบอกว่าไม่รู้

เทียบหลายตัวด้วยเกณฑ์เดียวกัน:

import json, time
from openai import OpenAI

MODELS = [
    ("qwen3:4b",  "http://localhost:11434/v1"),
    ("qwen3:8b",  "http://localhost:11434/v1"),
    ("qwen3:14b", "http://localhost:11434/v1"),
]

cases = [json.loads(l) for l in open("evalset.jsonl", encoding="utf-8")]

for name, base in MODELS:
    client = OpenAI(base_url=base, api_key="local")
    ok, latencies = 0, []
    for c in cases:
        t0 = time.perf_counter()
        r = client.chat.completions.create(
            model=name,
            messages=[{"role": "user", "content": c["input"]}],
            temperature=0, max_tokens=512)
        latencies.append(time.perf_counter() - t0)
        out = r.choices[0].message.content
        # เกณฑ์ตรวจต้องเป็นแบบอัตโนมัติ อย่าใช้สายตา
        if all(k in out for k in c.get("expect_contains", [])):
            ok += 1
    latencies.sort()
    print(f"{name:14s} ผ่าน {ok}/{len(cases)} "
          f"p50={latencies[len(latencies)//2]:.2f}s "
          f"p95={latencies[int(len(latencies)*.95)-1]:.2f}s")

ตัดสินใจจากตารางนี้ ไม่ใช่จากความรู้สึกหลังลองคุยไม่กี่ประโยค

6.5 ข้อควรรู้เฉพาะภาษาไทย

ประเด็น	ผลกระทบและวิธีรับมือ
Tokenizer ไม่มีประสิทธิภาพ	ข้อความไทยกิน token มากกว่าอังกฤษหลายเท่าที่ความหมายเท่ากัน ทำให้ค่า API แพงขึ้น context เต็มเร็วขึ้น และช้าลง ทดสอบด้วยข้อความจริงเพื่อดูอัตราส่วนของโมเดลที่เลือก
การตัดคำ	ภาษาไทยไม่มีช่องว่างระหว่างคำ โมเดลที่ฝึกภาษาไทยน้อยจะตัดคำผิดและทำให้ความหมายเพี้ยน
คะแนนอังกฤษไม่ได้แปลว่าไทยดี	โมเดลที่คะแนนอังกฤษสูงมากอาจตอบไทยได้แข็งทื่อหรือปนภาษา ต้องทดสอบด้วยข้อความไทยจริงเสมอ
โมเดลที่ปรับมาสำหรับไทย	มีทั้งตัวที่พัฒนาในไทยและตัวที่เน้นภูมิภาคเอเชียตะวันออกเฉียงใต้ มักชนะโมเดลสากลขนาดเดียวกันในงานภาษาไทย คุ้มค่าที่จะทดสอบเทียบเสมอ
เอกสารราชการและธุรกิจไทย	รูปแบบเฉพาะ เช่น เลขไทย พ.ศ. ที่อยู่แบบไทย มักต้อง fine-tune หรือใช้กฎช่วย ไม่ควรหวังให้โมเดลสากลทำได้เอง

6.6 รันเองหรือใช้ API

ประเด็น	รันเอง (open-weight)	API
ข้อมูล	ไม่ออกจากเครื่อง	ออกไปยังผู้ให้บริการ ต้องมีข้อตกลงรองรับ
ต้นทุน	จ่ายก้อนใหญ่ครั้งเดียว บวกค่าไฟ	จ่ายตามใช้ เริ่มต้นเกือบศูนย์
คุณภาพสูงสุด	ต่ำกว่าโมเดลปิดตัวท็อป	เข้าถึงโมเดลที่เก่งที่สุดได้ทันที
ความเสถียร	โมเดลไม่เปลี่ยนจนกว่าคุณจะเปลี่ยนเอง	ผู้ให้บริการอัปเดตได้ พฤติกรรมอาจเปลี่ยน
ปรับแต่ง	fine-tune ได้เต็มที่	จำกัดตามที่ผู้ให้บริการเปิดให้
เวลาที่ต้องดูแล	สูง — ไดรเวอร์ อัปเดต ปัญหาเฉพาะหน้า	เกือบศูนย์

แนวทางที่ได้ผลจริงสำหรับทีมเล็ก

เริ่มด้วย API เพื่อพิสูจน์ว่าไอเดียใช้ได้และเรียนรู้ว่างานต้องการอะไรจริง เมื่อรู้แล้วว่าปริมาณเท่าไรและคุณภาพระดับไหนก็พอ ค่อยย้ายส่วนที่ปริมาณสูงและงานง่ายมารันเอง ส่วนงานยากที่ปริมาณน้อยให้ใช้ API ต่อไป ระบบส่วนใหญ่ที่ทำงานได้ดีเป็นแบบผสม ไม่ใช่เลือกข้างใดข้างหนึ่ง

6.7 ใบอนุญาต — ตรวจก่อนใช้เชิงพาณิชย์

ประเภทใบอนุญาต	ความหมายในทางปฏิบัติ
Apache 2.0 / MIT	ใช้เชิงพาณิชย์ได้เต็มที่ ดัดแปลงได้ ปลอดภัยที่สุดสำหรับธุรกิจ
ใบอนุญาตเฉพาะของผู้พัฒนา	มักใช้เชิงพาณิชย์ได้ แต่มีเงื่อนไข เช่น เพดานจำนวนผู้ใช้ ข้อกำหนดการแสดงที่มา หรือข้อห้ามการใช้งานบางประเภท ต้องอ่านจริง
Non-commercial / Research only	ห้ามใช้หารายได้ รวมถึงการใช้ภายในบริษัทที่ทำเงินทางอ้อม ระวังโมเดลสร้างภาพที่มักเป็นแบบนี้
Gated ต้องขออนุมัติ	ต้องยอมรับเงื่อนไขบนเว็บก่อนโหลด และเงื่อนไขนั้นผูกพันคุณจริง

สิ่งที่คนลืมตรวจบ่อยคือ ใบอนุญาตของ โมเดลที่ถูกดัดแปลง ไม่ว่าจะ fine-tune, merge หรือ quantize โดยบุคคลที่สาม จะสืบทอดข้อจำกัดจากโมเดลต้นทางเสมอ ผู้อัปโหลดจะเขียนว่า Apache 2.0 ก็ได้ แต่ถ้าฐานเป็นโมเดลที่มีข้อจำกัด ข้อจำกัดนั้นยังอยู่ ให้ไล่ดูถึงต้นทางก่อนใช้ในงานที่มีรายได้

สรุปบทนี้

ข้อจำกัดตัดตัวเลือกได้เกิน 90% ก่อนจะถึงเรื่องคะแนน เลือกโมเดลที่เล็กที่สุดที่ผ่านชุดทดสอบของคุณเอง ไม่ใช่ตัวที่ชนะ leaderboard และตรวจใบอนุญาตย้อนถึงโมเดลต้นทางก่อนเอาไปหารายได้

บทถัดไปว่าด้วยแหล่งโหลดโมเดล และวิธีอ่าน repo ก่อนกดโหลด