ข้ามไปยังเนื้อหาหลัก

Rule-Based + LLM Hybrid

แนวคิด: ใช้กฎภาษาศาสตร์แบบ deterministic สำหรับรูปแบบที่ทราบว่าถูกต้อง (การเติมปัจจัยทางสัณฐานวิทยา, การจัดรูปแบบตัวเลข, โครงสร้างวลีที่รู้จัก) และให้ LLM จัดการการแปลเชิงสร้างสรรค์สำหรับส่วนที่เหลือ กฎจะมีความสำคัญเหนือกว่า LLM ในส่วนที่กฎครอบคลุม ส่วน LLM จะเติมเต็มในส่วนที่ขาดหายไป

:::info นี่คือ cookbook ไม่ใช่การ implement ที่สมบูรณ์ คู่มือนี้อธิบายโครงสร้างสถาปัตยกรรมแบบ hybrid กฎเฉพาะเจาะจงขึ้นอยู่กับไวยากรณ์ของภาษาเป้าหมายและทรัพยากรภาษาศาสตร์ที่มีอยู่ทั้งสิ้น :::

เมื่อใดควรใช้แนวทางนี้​

  • คุณมีความเชี่ยวชาญด้านภาษาศาสตร์เชิงลึกในภาษาเป้าหมาย (หรือสามารถเข้าถึงนักภาษาศาสตร์ได้)
  • รูปแบบการแปลบางอย่างเป็นแบบ deterministic — คุณทราบผลลัพธ์ที่ถูกต้องอย่างแน่นอน
  • LLM ล้มเหลวอย่างสม่ำเสมอกับรูปแบบเฉพาะ (การจัดรูปแบบตัวเลข, คำแสดงความเคารพ, การเชื่อมคำ)
  • คุณต้องการรับประกันความถูกต้องสำหรับรูปแบบที่มีความสำคัญสูง ขณะที่ยังคงความคล่องแคล่วในส่วนที่เหลือ

วิธีการทำงาน​

Input ──→ [Rule Engine] ──→ [LLM] ──→ [Merge] ──→ Output
              │                │           │
              │ Known patterns │ Unknown    │ Rules override
              │ handled here   │ parts      │ LLM where both
              ▼                ▼            ▼ produced output
         Deterministic     Creative     Final translation
         fragments         translation
  1. กำหนดกฎ — รูปแบบ regex, การค้นหา FST, ตารางค้นหาสำหรับการแปลที่รู้จัก
  2. ประมวลผลล่วงหน้า — ระบุและแยกส่วนที่ตรงกับกฎออกจากต้นฉบับ
  3. LLM แปล — ข้อความที่เหลือ โดยใช้ผลลัพธ์จากกฎเป็นข้อจำกัด
  4. รวมผล — ประกอบการแปลกลับคืน โดยให้ความสำคัญกับผลลัพธ์จากกฎเมื่อมีอยู่
  5. ตรวจสอบ — การตรวจสอบด้วย FST/กฎบนผลลัพธ์ที่รวมแล้ว (ไม่บังคับ)

ตัวอย่าง: กฎสำหรับตัวเลขและวันที่​

import re

# Rule: Numbers stay as-is (don't let the LLM hallucinate number translations)
def rule_preserve_numbers(text):
    return re.sub(r'\b\d+\b', lambda m: f'__NUM_{m.group()}__', text)

# Rule: Known greetings have exact translations
GREETING_RULES = {
    "hello": "tânisi",
    "goodbye": "êkosi",
    "thank you": "kinanâskomitin",
}

# Rule: Date format conversion
def rule_date_format(text):
    # "January 15" → "kisê-pîsim 15" (deterministic month mapping)
    ...

การตัดสินใจออกแบบที่สำคัญ​

ลำดับความสำคัญของกฎ: เมื่อกฎและ LLM ต่างให้ผลลัพธ์สำหรับส่วนเดียวกัน อะไรควรมีความสำคัญกว่า? กฎควรมีความสำคัญกว่าสำหรับรูปแบบที่ต้องการความถูกต้องสูง ส่วน LLM ควรมีความสำคัญกว่าสำหรับรูปแบบที่ต้องการความคล่องแคล่วสูง

ระดับความละเอียด: กฎระดับคำ (การค้นหาพจนานุกรม) เทียบกับกฎระดับวลี (การแมปสำนวน) เทียบกับกฎเชิงโครงสร้าง (การเรียงลำดับประโยคใหม่) เริ่มต้นด้วยระดับคำ แล้วเพิ่มระดับวลีเมื่อคุณระบุรูปแบบได้

การดูแลรักษากฎ: กฎทุกข้อคือภาระในการดูแลรักษา ควรเลือกใช้กฎที่มีความเชื่อมั่นสูงจำนวนน้อย แทนที่จะใช้กฎโดยประมาณจำนวนมาก หากคุณไม่แน่ใจว่ากฎถูกต้อง ให้ปล่อยให้ LLM จัดการ

ข้อดีและข้อเสีย​

✅ รับประกันความถูกต้องในส่วนที่กฎครอบคลุม❌ ต้องการความเชี่ยวชาญด้านภาษาศาสตร์เชิงลึก
✅ โปร่งใส — กฎอ่านได้และตรวจสอบได้❌ รอยต่อระหว่างกฎและ LLM อาจให้ผลลัพธ์ที่ไม่เป็นธรรมชาติ
✅ กฎทำงานได้เร็ว (ไม่มีค่าใช้จ่าย API)❌ ภาระการดูแลรักษาเพิ่มขึ้นตามจำนวนกฎ
✅ ค่อยเป็นค่อยไป — เพิ่มกฎได้เมื่อเรียนรู้เพิ่มเติม❌ จัดการการผันคำที่ขอบเขตของกฎได้ยาก

ใช้ร่วมกับแนวทางอื่นได้ดี​

  • FST-Gated Pipeline — FST ในฐานะ rule engine ประเภทเฉพาะ
  • Dictionary-Augmented LLM — การค้นหาพจนานุกรมคือกฎอย่างง่าย
  • Coached LLM Prompting — การ coaching จัดการความต้องการแบบยืดหยุ่น ส่วนกฎจัดการข้อกำหนดที่เข้มงวด

ดูเพิ่มเติม​