ปัญหา 1 — VRAM 4 GB ไม่พอ#

โมเดลที่อยากใช้ Qwen 3.5 9B ขนาดไฟล์ 6.6 GB → VRAM 4GB ใส่ไม่ได้ ต้อง offload ไป RAM (เอาโมเดลครึ่งนึงไปไว้ใน RAM ของเครื่อง แล้ว swap ไปมา)

ผลคือ ความเร็วร่วงจาก 25 token/วินาที เหลือ 2.4 token/วินาที (ช้าลง 10 เท่า)

Token = หน่วยที่ AI อ่าน/เขียน ภาษาอังกฤษประมาณ 0.75 คำต่อ token ภาษาไทยกินเยอะกว่า ~1-2 token/คำ

ปัญหา 2 — ลองโมเดลเล็กลง = แม่นยำพัง#

ลองสลับมา Qwen 3.5 4B (ขนาด 2.7 GB ใส่ VRAM ได้สบาย เร็วด้วย) แต่…

• โจทย์ Present Value (มูลค่าปัจจุบันของเงินในอนาคต — ถ้าจะได้เงิน 100,000 บาทในอีก 5 ปี ที่ดอกเบี้ย 3% ตอนนี้เงินก้อนนั้นมีมูลค่ากี่บาท?) → AI ตอบ 86,378.16 เฉลย 86,383.76 — เพี้ยน 5.60 บาท → ดูน้อยใช่มั้ย? แต่โจทย์ multiple choice ที่ตัวเลือกใกล้ๆ กัน 5 บาทก็พอผิดข้อได้

• โจทย์ NPV (Net Present Value — ลงทุนตอนต้น แล้วทยอยได้ cash flow คืนเป็นปีๆ สรุปคุ้มลงทุนมั้ย?) → AI คำนวณ cash flow รวมได้ 97,633 → สรุป “ไม่คุ้ม ไม่ลงทุน” → เฉลยจริงๆ ต้องคำนวณได้ 147,633 → สรุป “คุ้ม ลงทุน” → = ตอบกลับด้านกันเลย ถ้าเชื่อ AI ตามนี้ = พลาดดีลทำกำไร 50,000 บาท 😱

• โจทย์ WACC (Weighted Average Cost of Capital — ต้นทุนเฉลี่ยของเงินทุนบริษัท คิดเป็น % ใช้ตัดสินใจว่าโครงการคุ้มลงทุนมั้ย) → AI ตอบ 19.20% เฉลย 9.12% → คลาดเคลื่อน 10 เท่า จุดทศนิยมหายไปดื้อๆ → ระดับนี้ตัดสินใจกลับด้านได้เลย เห็น 19% ใครจะกล้าลงทุน เห็น 9% ใครจะไม่ลงทุน

โมเดลเล็กไป = สมองไม่พอจะทำเลขได้ถูก แค่บวกลบไม่ใช่ปัญหา แต่พอเป็นโจทย์ multi-step มันหลุดได้ทุกจุด

ปัญหา 3 — Token Loop วน#

อยู่ๆ AI ก็พิมพ์วนซ้ำๆ:

1
"ทังทังเป็นผู้ขายทังทังเป็นผู้ซื้อทังทังเป็นผู้ขายทังทัง..."

วน 100+ รอบจน timeout

นี่คืออาการ token degeneration โมเดลเข้า loop ของ probability ที่หา exit ไม่เจอ ลอง parameter แก้ทุกค่า (repeat penalty, repeat_last_n) ก็ fix ไม่ได้

ปัญหา 4 — ภาษาจีนหลุดเข้ามา 555+#

อันนี้ขำมาก ถามคำถามกฎหมายไทย AI ตอบมาว่า:

1
"การกระทำดังกล่าวเป็นการ 误导 ผู้ลงทุน..."

误导 = “หลอกลวง” ในภาษาจีน โผล่มาในคำตอบไทยเฉยเลย!

อีกข้อมี "买卖双方" (จีน = “ผู้ซื้อผู้ขาย”) โผล่ 3 ครั้งในคำตอบเดียว

เพราะ Qwen เป็นโมเดลจาก Alibaba ที่ train ด้วยข้อมูลจีน-อังกฤษ-ไทย รวมกัน โมเดล 4B ตัวเล็ก ไม่แข็งพอที่จะ constrain ตัวเองให้อยู่ภาษาเดียว

ปัญหา 5 — แต่งกฎหมายปลอม (อันตรายมาก)#

Qwen 4B กล้าตอบหน้าตาเฉย:

“ตามมาตรา 113 และมาตรา 114 ผู้กระทำผิดมีโทษปรับ 500,000 บาท จำคุก 2 ปี…”

ดูเหมือนจริงนะครับ แต่ไม่มีอยู่ในกฎหมายจริง มาตราที่อ้างไม่มี โทษที่อ้างไม่มี ทุกอย่างแต่งหมด

นี่คืออาการ AI Hallucination มันแต่งเรื่องอย่างมั่นใจ ใครเชื่อตามไปสอบ หรือไปคุยลูกค้า = ตายทันที

ปัญหา 6 — Tokenizer ของไทยพัง#

ดูคำตอบที่ออกมา เห็นอะไรแปลกๆ มั้ย?

1
"ท่ี"     ที่ถูกควรเป็น  "ที่"
2
"ค่านนั้"   ที่ถูกควรเป็น  "ค่านี้"
3
"ว่อ"      ที่ถูกควรเป็น  "ว่า"
4
"ดวย"     ที่ถูกควรเป็น  "ด้วย"
5
"เพิ่ย"    ที่ถูกควรเป็น  "เพิ่ม"

นี่ไม่ใช่พิมพ์ผิด นี่คือ fundamental limitation ของ tokenizer

Tokenizer = เครื่องที่หั่นข้อความเป็นชิ้นๆ ที่ AI อ่านได้ ภาษาอังกฤษหั่นง่าย (เห็น space ก็หั่น) แต่ภาษาไทยไม่มี space ระหว่างคำ + วรรณยุกต์/สระอยู่บน-ล่าง-ซ้าย-ขวา ทำให้ tokenizer ที่ออกแบบมาสำหรับภาษาอังกฤษ มองตัวอักษรไทยพังเป็นชิ้นๆ ผิดที่ผิดทาง

แก้ที่ prompt level ไม่ได้ มันคือปัญหาที่ระดับ training ของโมเดล

ปัญหา 7 — Thinking mode ช้าจน timeout#

โมเดลรุ่นใหม่ๆ มี “thinking mode” คือก่อนตอบ AI จะเขียน chain-of-thought ออกมาก่อน (คล้ายเรา “คิดดังๆ”) ทำให้คำตอบดีขึ้น แต่ใช้ token เยอะกว่าปกติ 3-5 เท่า

Qwen 9B + thinking + เครื่องช้า = 2.4 token/sec × thinking ยาว → timeout ที่ 9.67 นาที (HTTP limit อยู่ที่ 580 วินาที)

หลังหลายรอบของการ tune Modelfile (config โมเดล) ก็ยอมรับชะตา เครื่องนี้ไปไม่รอด ต้องเปลี่ยน

Partition + BitLocker (ป้องกันโน้ตบุ๊คหายแล้วโดนแฮกข้อมูล)#

1
EFI System    260 MB
2
Windows (C:)  237.95 GB ← BitLocker เข้ารหัส
3
Drive D       237.95 GB ← BitLocker เข้ารหัส (LLM อยู่ที่นี่)
4
Recovery      782 MB
5
Hibernation   ON (type=full, 13.6 GB)

BitLocker = ระบบเข้ารหัสฮาร์ดดิสก์ของ Windows — ใครเอาไดรฟ์ไปต่อเครื่องอื่นจะอ่านไม่ออกเลยถ้าไม่มี recovery key

Folder structure#

1
D:\LLM\
2
├── ollama\         ← Ollama models
3
├── cache\          ← HF, pip, uv caches
4
├── rag-benchmark\  ← Python project
5
└── backup\

Environment variables (User scope, ไม่ต้องใช้ admin)#

1
OLLAMA_MODELS = D:\LLM\ollama\models
2
HF_HOME       = D:\LLM\cache\hf
3
PIP_CACHE_DIR = D:\LLM\cache\pip
4
UV_CACHE_DIR  = D:\LLM\cache\uv

ทำให้โมเดลทั้งหมด + cache อยู่บน D: drive ไม่ปนกับ C: ที่บีบบ่อย

Stack ที่เลือกใช้ (ขออธิบายแต่ละตัว)#

1. Ollama — LLM inference server

ลองนึกภาพ โมเดล AI เป็นไฟล์ดิบขนาดหลาย GB ที่อยู่บน disk Ollama = โปรแกรมที่โหลดไฟล์เข้า VRAM แล้วเปิด HTTP API ให้เราเรียกใช้ผ่าน localhost:11434 เหมือนเรามี ChatGPT ของตัวเองวิ่งในเครื่อง แค่ต้องเรียก endpoint เอง

ที่เลือกเพราะ:

• รันบน Windows ได้แบบ native ไม่ต้องผ่าน Docker หรือ WSL (Linux subsystem)
• Auto manage VRAM โหลด/ปลดโมเดลให้เอง
• Command line ง่าย: ollama run gemma4:e4b จบเลย

2. Python 3.14 + uv package manager

uv = package manager ของ Python สมัยใหม่ (เขียนด้วย Rust) เร็วกว่า pip 10-100 เท่า ลง dependency ที่ pip ใช้ 30 วินาที uv จบใน 2 วินาที

ใช้ Python เพราะ ecosystem ML/AI สมบูรณ์สุด

3. ChromaDB — Vector database

อันนี้สำคัญ ขอเล่ายาวหน่อย

ลองนึกภาพ เรามีเอกสาร 1,000 หน้า เวลาผู้ใช้ถาม “DNS คืออะไร” เราต้องไปค้นหน้าที่เกี่ยวข้องในเอกสาร 1,000 หน้านั้น ส่งให้ AI อ่านก่อนตอบ

แบบ Ctrl+F ทั่วไป (keyword match) มันโง่ ถ้าเอกสารเขียนว่า “Domain Name System” ผู้ใช้ถาม “DNS” จะหาไม่เจอ

Vector database ใช้วิธี แปลงทั้งคำถามและทั้งเอกสารเป็น embedding = ตัวเลข 1,024 มิติ ที่บรรยาย “ความหมาย” ของข้อความ

1
"DNS คืออะไร"             → [0.21, -0.34, 0.88, ...]  (1,024 ตัวเลข)
2
"Domain Name System"      → [0.20, -0.35, 0.87, ...]  (ใกล้เคียงกัน!)
3
"สูตรไก่ทอด"             → [-0.91, 0.44, 0.12, ...]   (ห่างไกล)

แล้วหาเอกสารที่ embedding “ใกล้กัน” ที่สุด = เอกสารที่ความหมายตรงสุด ไม่ใช่ตัวอักษรตรงสุด

ChromaDB = Vector DB ที่รันแบบ embedded แปลว่าไม่ต้องตั้ง server แยก แค่ install Python library แล้วใช้เลย เหมาะสำหรับงาน local

4. bge-m3 — Embedding model

โมเดลที่ทำหน้าที่แปลงข้อความเป็นตัวเลข 1,024 มิติด้านบน ที่เลือกตัวนี้เพราะ รองรับภาษาไทยดีที่สุดใน open-source ปัจจุบัน

ทุกตัวประกอบกันยังไง#

ภาพรวมทั้ง stack เวลาพิมพ์คำถาม 1 ข้อ มันเดินทางผ่านอะไรบ้างกว่าจะได้คำตอบกลับ:

flowchart TB
    Q["💬 คำถาม"] --> ASK["ask.py<br/>(orchestrator)"]
    ASK --> BGE["bge-m3<br/>Embedding"]
    ASK --> BM["BM25<br/>Keyword tokenize"]

    BGE --> CHROMA[("ChromaDB<br/>745 chunks")]
    BM --> BMIDX[("BM25 index<br/>in-memory")]

    CHROMA --> SEM["Top 30<br/>semantic"]
    BMIDX --> KW["Top 30<br/>keyword"]

    SEM --> RRF["⚡ RRF Fusion<br/>vote คะแนน"]
    KW --> RRF

    RRF --> TOP["Top 10 chunks"]
    TOP --> OLLAMA["Ollama server<br/>localhost:11434"]
    OLLAMA --> GEMMA["🧠 Gemma 4 E4B"]
    GEMMA --> ANS["✅ คำตอบ + sources"]

    style Q fill:#4f46e5,color:#fff,stroke:#4338ca,stroke-width:2px
    style ASK fill:#7c3aed,color:#fff,stroke:#6d28d9,stroke-width:2px
    style BGE fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:2px
    style BM fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:2px
    style CHROMA fill:#0e7490,color:#fff,stroke:#155e75,stroke-width:2px
    style BMIDX fill:#0e7490,color:#fff,stroke:#155e75,stroke-width:2px
    style SEM fill:#06b6d4,color:#fff,stroke:#0891b2,stroke-width:2px
    style KW fill:#06b6d4,color:#fff,stroke:#0891b2,stroke-width:2px
    style RRF fill:#db2777,color:#fff,stroke:#be185d,stroke-width:2px
    style TOP fill:#ec4899,color:#fff,stroke:#db2777,stroke-width:2px
    style OLLAMA fill:#059669,color:#fff,stroke:#047857,stroke-width:2px
    style GEMMA fill:#10b981,color:#fff,stroke:#059669,stroke-width:2px
    style ANS fill:#16a34a,color:#fff,stroke:#15803d,stroke-width:3px

ทุกชิ้นรันบนเครื่องเรา ไม่มีอะไรออก internet เลย

Knowledge Base — เนื้อหาที่ต้องอ่าน#

1
benchmarks/sample/data/knowledge/
2
├── Module-A.md     (~95K tokens)
3
├── Module-B.md     (~130K tokens)
4
└── Module-C.md     (~140K tokens)
5
                Total = ~365K tokens

Question Bank — Sample ที่หามาทดสอบ#

1
QuestionsSample.xlsx → questions.jsonl
2
- ~1,080 ข้อ (drop 2 ที่มีรูป → ใช้จริง 1,078)
3
- 3 หัวข้อ × 3 ระดับความยาก (ง่าย / ปานกลาง / ยาก)
4
- Format: { id, topic, difficulty, question, choices: {A,B,C,D}, correct }

Chunking — หั่นเอกสารใหญ่เป็นชิ้นเล็ก#

Chunking = หั่นเอกสารยาวๆ เป็นชิ้น ขนาดที่ AI กินได้ทีเดียว ทำไมต้องหั่น? เพราะ LLM มี context window จำกัด (Gemma 4 E4B = 8,192 tokens) ถ้าเอกสารยาวกว่านั้น = ส่งทั้งก้อนเข้าไม่ได้

วิธีที่ใช้: Hybrid Semantic Chunking หั่นตาม heading H2/H3 ก่อน (แบ่งตามหัวข้อ) ถ้าชิ้นไหนยังใหญ่เกิน 1,024 tokens ค่อยแตกเพิ่ม

ทำไมหั่นตาม heading? เพราะคนเขียนเอกสารแบ่งหัวข้อตาม “เรื่องเดียวกัน” อยู่แล้ว หั่นตามนี้ = ชิ้นที่ออกมาเป็น “หน่วยความหมายเดียว” ไม่ตัดกลางประโยค

1
benchmarks/sample/data/knowledge/*.md
2
        ↓ (chunk_data.py)
3
chunks.json  ← 745 ชิ้น
4
        ↓ (ingest.py)
5
chroma_db/sample/  ← ChromaDB เก็บ vector + เนื้อหา

Prompt template ที่ใช้จริง#

1
You are an expert answering a multiple-choice question.
2

3
Use the context below to inform your answer.
4
- Plain text only (no LaTeX, no markdown)
5
- Read the question carefully; watch for MOST, BEST, FIRST, LEAST, NOT
6
- Eliminate clearly wrong choices before picking the best one
7

8
End with exactly two lines:
9
REASONING: <one or two sentences explaining why>
10
ANSWER: <single letter: A, B, C, or D>
11

12
=== CONTEXT ===
13
{context_block}
14

15
=== QUESTION ===
16
{question_text}
17

18
{choices_block}

ที่บอก “End with exactly two lines” เพื่อให้ parser ของเราดึงคำตอบออกมาง่าย (regex หา ANSWER: X ตรงท้าย)

Regex (Regular Expression) = สูตรหา pattern ของข้อความ เช่น “หาตัวอักษร A-D ที่อยู่หลังคำว่า ANSWER:” เขียนสั้นๆ เป็นสูตรเดียว ใช้กันแพร่หลายในการ parse text

ทางที่ลอง 1: Reranker — เพิ่มเชฟตัวที่สอง#

ทฤษฎีคือ แทนที่จะดึง top 5 ส่งให้ LLM เลย ให้ดึง top 30 มาก่อน แล้วเอาตัว Reranker มาคัดให้เหลือ 10 ที่ “ตรงโจทย์ที่สุด”

Reranker = โมเดลตัวที่สอง ออกแบบมาเพื่อ “อ่านคู่” ระหว่างคำถามกับ chunk เปรียบเทียบความตรงโจทย์ (คะแนน 0-1) เป็น cross-encoder คำตอบแม่นกว่า embedding ธรรมดา (bi-encoder)

เหมือนเชฟตัวแรกตักของจาก buffet มา 30 อย่าง เชฟตัวที่ 2 มาคัดให้เหลือ 10 อย่างที่เข้ากับคำถามจริงๆ

ผลที่ได้:

• accuracy ดีขึ้น +1-2%
• speed ลดลง 15 เท่า (จาก 0.6 วินาที/ข้อ เป็น 44 วินาที/ข้อ)

เริ่ม panic โทษว่า VRAM contention (4GB Gemma + 2GB reranker = ใกล้ 8GB cap)

ทดสอบแยกๆ:

1
Reranker เปล่าๆ → 0.6 วินาที ✅
2
Ollama loaded + Reranker → 44 วินาที ❌

ก็เลยท้าทายตัวเอง “VRAM ตัวเลขนิ่ง แต่ทำไมช้า แน่ใจว่า CUDA ที่โหลดไม่ได้กวนกัน?”

หา root cause จริงๆ ก็เจอ:

CUDA context switching ระหว่าง Ollama process กับ Python torch process ทุกครั้งที่ swap = flush cache, reload kernels VRAM ดูนิ่งเพราะมัน lazy-allocate แต่ context switch overhead = killer

CUDA = แพลตฟอร์มของ NVIDIA ที่ใช้ GPU มาคำนวณเรื่องที่ไม่ใช่กราฟิก (AI, simulation, etc.) Context switching = การสลับงานระหว่าง 2 process ที่ใช้ resource เดียวกัน เหมือนเชฟ 2 คนใช้เตาเดียวกัน ต้องแย่งกันใช้ ผลัดกันรอ

Decision: ตัด reranker ทิ้งครับ +1-2% accuracy ไม่คุ้มกับ 15x slowdown

แทนที่ด้วย…

ทางที่ลอง 2: Hybrid RRF — ตัวเปลี่ยนเกม#

อันนี้อยากเล่ายาวหน่อยเพราะมันคือ hero ของโปรเจกต์

ปัญหาที่เจอ บางคำถามที่ retrieval miss คือคำถามที่ มีคำเฉพาะทางเป็น keyword เช่น “DNS”, “API”, “JSON” embedding model มันจับ “ความหมาย” ได้ดี แต่จับ keyword ตรงเป๊ะ ไม่เก่ง

ฝั่งกลับกัน search แบบ keyword (BM25) ก็แย่เรื่อง paraphrase

BM25 = สูตรหาคำสำคัญในเอกสารแบบ “TF-IDF เวอร์ชันใหม่กว่า” เป็นตัวที่ Google ก่อนยุค semantic search ใช้ ฉลาดกว่า Ctrl+F ที่ rank ด้วยความถี่ + ความหายาก

Reciprocal Rank Fusion (RRF) — Cormack et al. 2009 — รวมผลจาก 2 retriever ที่ใช้คนละวิธี

1
# Retrieve top-30 จาก semantic (bge-m3)
2
sem_results = chromadb.query(query_embedding, k=30)
3

4
# Retrieve top-30 จาก BM25 (rank_bm25 library, in-memory)
5
bm25_results = bm25.get_top_n(query_tokens, k=30)
6

7
# RRF fusion
8
def rrf_score(rank, k=60):
9
    return 1.0 / (k + rank)
10

11
combined = {}
12
for rank, doc in enumerate(sem_results):
13
    combined[doc.id] = combined.get(doc.id, 0) + rrf_score(rank)
14
for rank, doc in enumerate(bm25_results):
15
    combined[doc.id] = combined.get(doc.id, 0) + rrf_score(rank)
16

17
# Sort และเอา top-k
18
top_k = sorted(combined.items(), key=lambda x: -x[1])[:10]

อธิบายแบบไม่ใช่โค้ด:

flowchart TB
    Q["💬 คำถามเข้ามา"] --> S["🧭 Semantic search<br/>bge-m3 → top 30"]
    Q --> B["🔑 BM25 keyword search<br/>top 30"]
    S --> F["⚡ RRF Fusion<br/>vote คะแนน"]
    B --> F
    F --> T["📤 Top 10 chunks<br/>ส่งให้ LLM"]

    style Q fill:#4f46e5,color:#fff,stroke:#4338ca,stroke-width:2px
    style S fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:2px
    style B fill:#0891b2,color:#fff,stroke:#0e7490,stroke-width:2px
    style F fill:#db2777,color:#fff,stroke:#be185d,stroke-width:2px
    style T fill:#16a34a,color:#fff,stroke:#15803d,stroke-width:3px

= เอาผลของ 2 หมอมา vote กัน — chunk ที่ทั้ง 2 หมอเลือก = น่าจะเข้าจุดสุด

ทำไมมัน work:

• Semantic catches paraphrase (“Transport Layer Security” = “TLS”)
• BM25 catches keyword exact match (เจอตัว “TLS” ในเอกสารตรงๆ)
• คำถามมีทั้ง 2 type → รวมกันชนะแยก

Speed? BM25 เป็น in-memory algorithm ไม่ต้องใช้ GPU เลย ~50ms/query ไม่มี CUDA contention

ทางที่ลอง 3: top_k decision#

ทดสอบ k=5, 10, 15 บน 9 ข้อที่ retrieval miss:

1
k=5  → ฟื้น 3/9
2
k=10 → ฟื้น 4/9   (Pareto better — fix ทุก k=5 fix + เพิ่ม Q0009)
3
k=15 → ฟื้น 1/9   (เริ่ม noise)

ตอนแรกเขียนสรุปไปว่า “k=10 ดีกว่า +1 = marginal, prefer simpler k=5”

แล้วตัวเองมาเถียงตัวเอง “อ้าว k=10 มัน strict superset ของ k=5 fixes + เร็วกว่าด้วย (13.3s vs 15.5s)”

จริงด้วย Occam’s Razor บอกว่า “เลือกอันง่ายเมื่อสมมุติฐานเสมอกัน” ตรงนี้ k=10 คือ Pareto-superior (ดีกว่าทุกด้าน) ไม่ใช่ marginal

Pareto-superior = ดีกว่าใน metric หนึ่งโดยไม่แย่ลงใน metric อื่น Occam’s Razor ใช้ตอนทุกอย่างเสมอกันเท่านั้น

Decision: top_k=10

Stack หลัง Phase 6#

1
config = {
2
    "model": "gemma4:e4b",
3
    "retrieval": "hybrid_rrf",
4
    "top_k_final": 10,
5
    "sem_candidates": 30,    # bge-m3 top 30
6
    "bm25_candidates": 30,   # BM25 top 30
7
    "temperature": 0.0,
8
    "num_predict": 2500,
9
    "num_ctx": 8192,
10
    "think": False,
11
}

temperature=0.0 = บังคับให้ AI ตอบแบบ deterministic (ส่วนใหญ่) ค่าสูงๆ AI จะ “creative” มากขึ้น แต่ก็มั่วได้ การสอบ = ต้องการตอบเหมือนเดิมทุกครั้ง

Pre-flight check#

ก่อนรัน 4 ชั่วโมง:

1
# ปิด sleep ที่อาจ kill benchmark กลางทาง
2
powercfg /change standby-timeout-ac 0
3

4
# เช็คเสียบสายชาร์จ
5
Get-CimInstance Win32_Battery | Select-Object BatteryStatus
6
# 1 = Discharging (ยังไม่เสียบ!), 2 = AC (OK)

ตอนแรกอ่าน BatteryStatus=1 ผิดว่าโอเค จริงๆ คือ Discharging แล้ว ต้องเสียบสาย → 2 (AC) ทุกครั้ง

รันยาว 4 ชั่วโมง#

1
cd /d/LLM/rag-benchmark
2
uv run python scripts/run_full_1078_benchmark.py

1
Loaded 1078 questions from sample_full.jsonl
2
Configuration: gemma4:e4b + hybrid_rrf + top_k=10
3
Setting up retrievers...
4
  [+] ChromaDB: 745 chunks
5
  [+] BM25 index: 745 chunks
6
Checkpoint every 50 questions
7

8
Benchmarking: 1/1078 [00:24<7:13:12, 24.31s/it]
9
Benchmarking: 2/1078 [00:38<5:30:35, 18.57s/it]
10
...

ตอนเฝ้า benchmark — เห็นอะไรแปลกๆ#

ระหว่างที่รัน Task Manager โชว์ Intel UHD GPU 100% panic นิดหน่อย คิดว่ามันใช้ GPU ผิดตัวหรือเปล่า

หลังเช็ค Performance Counters:

1
PID 19524 claude  engine=3d  util=71.9%  (Electron UI)
2
PID 4068  dwm     engine=3d  util= 8.6%  (Windows desktop)

อ้าว นั่นคือ Claude Code UI render chart real-time ใช้ Intel iGPU ไม่ใช่ NVIDIA RTX 4060 (ที่ทำงาน benchmark) แยกกันคนละการ์ด หายห่วง

ผลรวม 3 ชั่วโมง 56 นาที#

1
Q1078/1078 [3:56:12]
2
Final accuracy: 67.62% (729/1078)
3
Parse failures: 15 (1.39%)
4
Latency: p50=8.5s, p95=19.3s, mean=10.5s
5
Throughput: 26.6 tokens/sec

Latency p50/p95 = เวลาที่ใช้ตอบคำถาม วัดที่ percentile p50=8.5s แปลว่า 50% ของคำถามตอบเสร็จภายใน 8.5 วินาที ส่วน p95=19.3s แปลว่า 95% ตอบเสร็จภายใน 19.3 วินาที (= ส่วนหางที่ช้า)

แยกตามความยาก:

1
ง่าย       87.0%  (167/192)  ✅
2
ปานกลาง    71.3%  (495/694)  ✅
3
ยาก        34.9%  ( 67/192)  ⚠️ ← ตัวพ่อ ขนาดผมยังตอบไม่ถูกหลายข้อ

แยกตามหัวข้อ:

1
Module-A   69.6%  (249/358)  ← strongest
2
Module-B   67.4%  (292/433)
3
Module-C   65.5%  (188/287)

vs Phase 5 baseline 74%: ต่ำกว่า 6 points

แต่… Phase 5 เทสบน 320 ข้อที่กลุ่ม “ยาก” น้อย ตัดกลุ่ม “ยาก” ออกจาก 1,078 = 74.7% (ดีกว่า Phase 5 ด้วยซ้ำ)

= sample bias, ไม่ใช่ regression ระบบไม่ได้แย่ลง แค่เจอข้อยากมากขึ้นในรอบนี้

Stage 1: Tier 1 + 2 retry (เพิ่ม token budget)#

1
# Tier 1: num_predict 2500 → 4000
2
# Tier 2: num_predict 4000 → 6000 (สำหรับที่ Tier 1 ยัง fail)

ผลลัพธ์:

• Tier 1: ฟื้น 7/15
• Tier 2: ฟื้น 0/8 (เพิ่ม token ก็ไม่ช่วย ปัญหาคนละชั้น)

Stage 2: Direct prompt (ไอเดียที่ลอง)#

“งั้นส่ง prompt ตรงๆ ไม่ผ่าน RAG ลองดู ถ้า model จำได้เอง ไม่ต้อง context”

1
prompt = f"""Question: {q['question']}
2
A: {opts['A']}
3
B: {opts['B']}
4
C: {opts['C']}
5
D: {opts['D']}
6

7
Answer with ONLY the letter (A, B, C, or D):"""

รันครั้งแรก LLM ตอบว่างเปล่า!?

เจอ bug 1: Field ชื่อ choices ไม่ใช่ options

1
opts = q.get('options', {})   # ← None ตลอด, prompt ส่ง A: B: C: D: ว่าง
2
opts = q.get('choices', {})   # ← OK

เจอ bug 2: Gemma 4 E4B think: true เป็น default ตั้ง num_predict=50 (ตอบสั้นๆ พอ) แต่ model ใช้ 50 tokens ไป คิดใน <think> block หมด ไม่เหลือ token ตอบจริง

1
# เพิ่ม think: False เข้าไปใน body
2
body = json.dumps({
3
    "model": "gemma4:e4b",
4
    "prompt": prompt,
5
    "stream": False,
6
    "think": False,  # ← ต้องใส่
7
    ...
8
})

รันใหม่ทั้ง 8 ข้อที่เหลือ:

1
[1/8] Q0110  | ปานกลาง | correct=D | pred=A | WRONG
2
[2/8] Q0114  | ยาก     | correct=B | pred=B | CORRECT
3
[3/8] Q0161  | ปานกลาง | correct=A | pred=A | CORRECT
4
[4/8] Q0176  | ปานกลาง | correct=C | pred=C | CORRECT
5
[5/8] Q0197  | ปานกลาง | correct=B | pred=A | WRONG
6
[6/8] Q0051  | ยาก     | correct=B | pred=B | CORRECT
7
[7/8] Q0192  | ง่าย    | correct=B | pred=B | CORRECT
8
[8/8] Q0204  | ปานกลาง | correct=A | pred=B | WRONG
9

10
Parsed:  8/8  ← parse fail = 0 🎉
11
Correct: 5/8  ← ฟื้น 5 ข้อ

Final Score#

1
Stage              Acc      Correct  Parse_fail
2
Raw benchmark      67.6%   729      15
3
+ Tier 1+2 retry   67.8%   731      8
4
+ Direct prompt    68.3%   736      0   ← 🏆