ถามเป็นภาษาลาว แต่ได้คำตอบกลับมาเป็นภาษาอังกฤษ — นี่คือกำแพงแรกที่เราชนเข้าอย่างจัง เมื่อครั้งที่บริษัทของเราสร้าง AI chatbot สำหรับลาวเป็นครั้งแรก สำหรับ LLM ชั้นนำของโลก ภาษาลาวถือเป็น "ภาษาที่แทบไม่รู้จัก" และการใช้แนวทางเดียวกับภาษาอังกฤษนั้นไม่อาจนำไปสู่ระดับที่ใช้งานได้จริง บทความนี้จะอธิบายแบบ step-by-step ตั้งแต่เกณฑ์การคัดเลือก LLM ภาษาลาว ขั้นตอนการสร้าง ไปจนถึงการทำ automation สำหรับการประเมินคุณภาพ โดยอิงจากสถาปัตยกรรม RAG (Retrieval-Augmented Generation) + LLM ที่บริษัทของเรานำมาใช้จริงในโปรเจกต์สำหรับลาว นี่คือคู่มือเชิงปฏิบัติสำหรับผู้ที่ต้องการสร้าง chatbot ที่ "ใช้งานได้จริง" ในภาษาลาว

ถ้าเป็น chatbot ภาษาอังกฤษ แค่เรียก API แล้วเขียน prompt ก็ใช้งานได้ แต่กับภาษาลาวนั้น แนวทางเดียวกันนี้ใช้ไม่ได้ผล สาเหตุมาจากคุณลักษณะเฉพาะของภาษานั้นเอง และความลำเอียงในข้อมูลที่ใช้ฝึก LLM

ประสิทธิภาพหลายภาษาของ LLM นั้นแปรผันตามปริมาณข้อความที่มีอยู่ใน training corpus เป็นหลัก เมื่อพิจารณาสัดส่วนข้อมูลใน Common Crawl พบว่าภาษาอังกฤษครองสัดส่วนราว 46% ในขณะที่ภาษาลาวมีไม่ถึง 0.01% ความเหลื่อมล้ำกว่า 4,000 เท่านี้สะท้อนออกมาเป็นความแตกต่างด้านคุณภาพการตอบสนองอย่างชัดเจน

เมื่อครั้งที่บริษัทของเราเปิดตัวโครงการ AI แรกในลาว เราได้ทดลองให้ LLM อเนกประสงค์สรุปคู่มือการปฏิบัติงานเป็นภาษาลาว ปรากฏว่าเกิดข้อผิดพลาดในการแปลงคำนามเฉพาะและโครงสร้างไวยากรณ์พังทลายบ่อยครั้ง ยกตัวอย่างเช่น「ທະນາຄານແຫ່ງ ສປປ ລາວ」(ธนาคารแห่งชาติลาว) ถูกย่อเหลือเพียง "ธนาคารของลาว" จนไม่สามารถระบุได้ว่าหมายถึงธนาคารใด prompt ที่ใช้งานได้ดีในภาษาอังกฤษกลับไม่ทำงานในภาษาลาว——นี่คือความเป็นจริงของภาษา low-resource

ภาษาลาวมีลักษณะเฉพาะคือไม่มีช่องว่างระหว่างคำ และไม่มีเครื่องหมายสิ้นสุดประโยคที่ชัดเจน ในภาษาอังกฤษ "I love cats" ใช้เพียง 3 token แต่ "ຂ້ອຍຮັກແມວ" ในภาษาลาวอาจถูกแบ่งออกเป็นมากกว่า 10 token โดย tokenizer แบบ BPE (Byte Pair Encoding)

ผลกระทบต่อการใช้งานจริงมี 2 ประการ ได้แก่

• การบีบอัด context window: แม้จะมีปริมาณข้อมูลเท่ากัน แต่ภาษาลาวใช้ token มากกว่าภาษาอังกฤษ 2–3 เท่า ยิ่งบทสนทนายาวขึ้น บริบทในอดีตก็จะถูกดันออกไป ส่งผลให้คุณภาพการตอบสนองลดลง
• ความยากในการแบ่งข้อความ: การแบ่งเอกสาร (chunking) สำหรับ RAG มักเกิด "การแบ่งผิดพลาด" ที่ตัดกลางคำหรือกลางประโยคด้วยความถี่สูง sentence splitter ที่ออกแบบมาสำหรับภาษาอังกฤษแทบไม่สามารถใช้งานได้กับภาษาลาว

หลายคนอาจคิดว่า หาก LLM มีประสิทธิภาพต่ำในภาษาลาว ก็แค่ "แปลคำถามเป็นภาษาอังกฤษก่อน → ค้นหาและประมวลผลเป็นภาษาอังกฤษ → แปลผลลัพธ์กลับเป็นภาษาลาว" — บริษัทของเราเองก็เคยทดลองวิธีนี้ในช่วงแรก

ผลลัพธ์ที่ได้นั้นย่ำแย่มาก

• ความแม่นยำในการแปลจากภาษาลาวเป็นภาษาอังกฤษต่ำตั้งแต่ต้น: คำว่า「ສິນເຊື່ອ」(สินเชื่อ) ถูกแปลตัดทอนเป็นแค่ "credit" ทำให้บริบทด้านการเงินหายไป นอกจากนี้ คำศัพท์ทางกฎหมายและการบริหารของลาวจำนวนมากไม่สามารถแปลตรงตัวเป็นภาษาอังกฤษได้
• การแปลสองชั้นเพิ่ม latency ถึง 2〜3 วินาที: เมื่อ chatbot ใช้เวลาตอบสนองเกิน 5 วินาที อัตราการละทิ้งของผู้ใช้จะพุ่งสูงขึ้นอย่างรวดเร็ว
• คำนามเฉพาะพังทลายในกระบวนการแปล: ชื่อสถานที่ในลาว (เช่น ชื่อหมู่บ้านในแขวงหลวงพระบาง) และชื่อหน่วยงานต่าง ๆ เกิดการบิดเบือนระหว่างการแปลไปกลับจนไม่สามารถกู้คืนได้

จากประสบการณ์นี้ บริษัทของเราจึงเปลี่ยนแนวทางมาใช้วิธีประมวลผลข้อความภาษาลาวในรูปแบบภาษาลาวโดยตรง นั่นคือการเสริมความรู้ด้วย RAG (Retrieval-Augmented Generation)

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

บริษัทของเราได้ประเมินประสิทธิภาพ LLM ภาษาลาวใน 4 แกนหลักดังต่อไปนี้

1. ความเป็นธรรมชาติของการสนทนาในชีวิตประจำวัน: การถามตอบพื้นฐานมีความถูกต้องทางไวยากรณ์และเป็นธรรมชาติหรือไม่
2. ความแม่นยำของคำศัพท์เฉพาะทาง: สามารถจัดการคำศัพท์ภาษาลาวในสาขาการเงิน การบริหาร และ IT ได้อย่างถูกต้องหรือไม่
3. การปฏิบัติตามคำสั่ง: สามารถปฏิบัติตามข้อจำกัด เช่น "ตอบเป็นภาษาลาว" หรือ "ตอบโดยอ้างอิงเฉพาะข้อมูลที่ให้มาเท่านั้น" ได้หรือไม่
4. ประสิทธิภาพด้านต้นทุน: ภาษาลาวมีการขยายตัวของ token ทำให้มีต้นทุนสูงกว่าภาษาอังกฤษ 2〜3 เท่า โดยพิจารณาต้นทุนที่แท้จริงโดยคำนึงถึงปัจจัยดังกล่าว

สำหรับการตรวจสอบ ได้จัดเตรียม FAQ งานภาษาลาว (50 ข้อ) และให้แต่ละโมเดลตอบภายใต้เงื่อนไขเดียวกัน

ผลการทดสอบโมเดลหลักในปี 2025 มีดังนี้

※ ราคาอาจเปลี่ยนแปลงตามช่วงเวลา ภาษาลาวมี Token Expansion ทำให้ต้นทุนจริงสูงกว่าภาษาอังกฤษ 2–3 เท่า

สิ่งที่โมเดลทุกตัวมีเหมือนกันคือ ภาษาลาวเพียงอย่างเดียวไม่สามารถตอบคำถามในโดเมนเฉพาะทางได้อย่างแม่นยำ ไม่ว่าจะเลือกใช้โมเดลใด การเสริมความรู้ด้วย RAG ถือเป็นสิ่งจำเป็นเสมอ

ในโครงสร้างพื้นฐาน chatbot ของเรา เราใช้ Claude Sonnet ผ่าน AWS Bedrock โดยมีปัจจัยชี้ขาด 3 ประการดังนี้

1. ความเสถียรในการปฏิบัติตามคำสั่ง ใน RAG นั้น ผลลัพธ์จากการค้นหาจะถูกฉีดเข้าไปใน system prompt หากตอนนั้น LLM ไม่ปฏิบัติตามคำสั่ง "ให้ตอบโดยอิงจากเฉพาะ context ที่ให้มาเท่านั้น" ก็จะเกิด hallucination (การตอบสนองที่ไม่ตรงกับความเป็นจริง) ขึ้น Claude มีความสามารถในการปฏิบัติตามข้อจำกัดนี้สูงที่สุด และมีการเบี่ยงเบนน้อยแม้ใน context ภาษาลาว

2. การผสานรวมกับ AWS ecosystem การใช้ Bedrock ทำให้สามารถควบคุมการเข้าถึงด้วย IAM, ติดตาม log ด้วย CloudWatch และเชื่อมต่อแบบ private จากภายใน VPC ได้ ลูกค้าของเราส่วนใหญ่เป็นสถาบันการเงิน ดังนั้นข้อกำหนดที่ขาดไม่ได้คือข้อมูลต้องไม่ออกนอก region

3. ความยืดหยุ่นในการสลับ multi-model Bedrock สามารถเรียกใช้ทั้ง Mistral, Llama และ Amazon Nova นอกเหนือจาก Claude ผ่าน API เดียวกัน หากในอนาคตมี model ที่เชี่ยวชาญภาษาลาวมากขึ้นเกิดขึ้น ก็สามารถสลับได้โดยไม่ต้องแก้ไข code

ดังที่ได้ยืนยันในบทก่อนหน้า LLM ทุกตัวไม่มีความรู้เฉพาะทางในภาษาลาวโดยลำพัง การผสมผสาน RAG เข้ามาจะช่วยเสริมข้อจำกัดพื้นฐานนี้

RAG (Retrieval-Augmented Generation) คือวิธีการที่ดึงเอกสารที่เกี่ยวข้องกับคำถามของผู้ใช้มาด้วยการค้นหาแบบ vector search แล้วนำเนื้อหานั้นใส่เข้าไปใน prompt ของ LLM เพื่อสร้างคำตอบ

ความแตกต่างระหว่าง LLM แบบเดี่ยวกับ RAG จะเห็นได้ชัดเจนเป็นพิเศษในภาษาลาว

คำถามที่ LLM แบบเดี่ยวยังพอตอบได้ในภาษาอังกฤษ กลับตอบไม่ได้เลยในภาษาลาว นั่นจึงเป็นเหตุผลที่ RAG มีประสิทธิภาพสูงสุดในภาษาลาว

ไปป์ไลน์ที่บริษัทเราใช้งานมีโครงสร้างดังต่อไปนี้

คำถามของผู้ใช้ (ภาษาลาว)
  ↓
[Embedding] แปลงข้อความให้เป็นเวกเตอร์
  ↓
[Vector Search] ดึงข้อมูล chunk ที่คล้ายกัน 50 รายการด้วย Supabase pgvector
  ↓
[Reranking] กรองด้วยคะแนนความคล้ายคลึง → คัดเลือกเหลือ 5 รายการแรก
  ↓
[LLM] ส่ง context + คำถามไปยัง AWS Bedrock Claude
  ↓
[Streaming] ส่งการตอบกลับแบบทีละขั้นตอนผ่าน SSE
  ↓
[Auto Scoring] วัดคะแนนคุณภาพอัตโนมัติด้วย Mastra Evaluations

จุดสำคัญคือการใช้โมเดลที่แตกต่างกันสำหรับ Embedding และ LLM กล่าวคือ ใช้โมเดลที่รองรับหลายภาษาและมีต้นทุนต่ำสำหรับ Embedding และใช้ Claude ที่มีความสามารถในการปฏิบัติตามคำสั่งสูงสำหรับการสร้างการตอบกลับ การผสมผสานนี้มีความโดดเด่นในด้านความสมดุลระหว่างต้นทุนและคุณภาพ

การ Embedding (การแปลงข้อความเป็นเวกเตอร์) คือองค์ประกอบที่สำคัญที่สุดที่กำหนดความแม่นยำในการค้นหาของ RAG

หากใช้โมเดล Embedding ที่รองรับหลายภาษา ก็สามารถแปลงข้อความภาษาลาวให้เป็นเวกเตอร์ได้ โมเดลที่รองรับมากกว่า 100 ภาษาจะครอบคลุมภาษาลาวด้วยเช่นกัน

อย่างไรก็ตาม ยังมีข้อจำกัดอยู่ เนื่องจากภาษาลาวมีข้อมูลสำหรับการเทรนน้อย ระยะห่างของเวกเตอร์สำหรับคำพ้องความหมายและการถอดความจึงไม่แม่นยำเท่าภาษาอังกฤษ โดยเฉพาะอย่างยิ่ง อาจเกิดกรณีที่ «ສິນເຊື່ອ» (สินเชื่อ) และ «ເງິນກູ້» (เงินกู้) ไม่ถูกจัดวางให้อยู่ใกล้กันในฐานะแนวคิดเดียวกัน ปัญหานี้ได้รับการบรรเทาด้วยการออกแบบ pipeline ที่ขยายขอบเขตการค้นหาเริ่มต้นให้กว้าง (50 รายการ) แล้วจึงคัดกรองด้วยการ Reranking (เหลือ 5 รายการ)

ต่อจากนี้จะอธิบายขั้นตอนการสร้างอย่างละเอียด โดยใช้ tech stack ที่เป็น TypeScript + Next.js + Supabase + Mastra เป็นพื้นฐาน แต่แนวคิดด้านสถาปัตยกรรมสามารถนำไปประยุกต์ใช้กับ stack อื่นๆ ได้เช่นกัน

เตรียม Knowledge ที่ Chatbot จะใช้อ้างอิง (คู่มือการทำงาน, FAQ, เอกสารข้อกำหนด ฯลฯ) และแบ่งออกเป็นหน่วยที่สามารถค้นหาได้

การแบ่งข้อความภาษาลาวคือความท้าทายที่ยากที่สุด เนื่องจากคำไม่ได้คั่นด้วยช่องว่าง และแทบไม่มีการใช้เครื่องหมายสิ้นสุดประโยค (เทียบเท่ากับ「。」) ทำให้ sentence splitter ที่ออกแบบมาสำหรับภาษาอังกฤษไม่สามารถทำงานได้ บริษัทของเราใช้กลยุทธ์การแบ่งของ Mastra RAG โดยแยกประเภทการใช้งานดังนี้

การตั้งค่าที่แนะนำ: สำหรับเอกสารภาษาลาว ให้ใช้ recursive เป็นพื้นฐาน (chunk size 512 Token, overlap 50 Token) เหตุผลที่ใส่ค่า overlap ไว้ก็เพื่อให้แม้ตำแหน่งที่แบ่งจะตกอยู่กลางบริบทของภาษาลาว เนื้อหาก็ยังได้รับการเสริมจาก chunk ก่อนหน้าและถัดไป

แปลงข้อความที่แบ่งเป็น chunk ให้เป็นเวกเตอร์ และจัดเก็บในสถานะที่ค้นหาได้ ในบริษัทของเราใช้ส่วนขยาย pgvector ของ Supabase

เหตุผลที่เลือก Supabase pgvector มี 3 ประการ

• Tenant Isolation: ด้วย RLS (Row Level Security) ของ PostgreSQL สามารถแยก knowledge ของแต่ละ client ออกจากกันได้
• ไม่มีค่าใช้จ่ายเพิ่มเติม: เพียงเพิ่มส่วนขยายเข้าไปใน Supabase project ที่มีอยู่ ไม่จำเป็นต้องใช้บริการภายนอกอย่าง Pinecone หรืออื่น ๆ
• การผสานรวมกับ SQL: สามารถรวมการค้นหาเวกเตอร์กับ filter ทั่วไป (language code, category ฯลฯ) ไว้ใน 1 query ได้

จุดสำคัญของการออกแบบตารางคือการรวม language code ไว้ใน metadata หากต้องการค้นหาเฉพาะ knowledge ภาษาลาว ให้ filter ด้วย language = 'lo' และหากต้องการค้นหาข้ามทุกภาษาก็เพียงถอด filter ออก——การสลับระหว่างสองโหมดนี้ทำได้ด้วยเพียง 1 บรรทัดใน WHERE clause ของ SQL

การค้นหาแบบ Vector Search นั้น การ "คืนผลลัพธ์ตามลำดับความคล้ายคลึง" เพียงอย่างเดียวยังไม่เพียงพอต่อความแม่นยำ เนื่องจากความแม่นยำของ Embedding ในภาษาลาวนั้นไม่สูงเท่าภาษาอังกฤษ จึงทำให้ Chunk ที่มีความเกี่ยวข้องต่ำแทรกเข้ามาอยู่ในอันดับต้น ๆ ได้ง่าย

Pipeline ของเราทำการกรองข้อมูลแบบ 2 ขั้นตอน

1. การค้นหาเบื้องต้น: ดึงข้อมูล 50 อันดับแรกอย่างกว้าง ๆ ด้วย pgvector
2. Similarity Filter + Reranking: กำจัด Noise ด้วยคะแนน Cosine Similarity จากนั้นส่ง 5 อันดับแรกที่เรียงลำดับใหม่ตามความเกี่ยวข้องไปยัง LLM

เหตุใดจึงต้องดึงถึง 50 อันดับ? เนื่องจากใน Embedding ภาษาลาว Chunk ที่ควรจะอยู่อันดับ 1 อาจจมอยู่ที่อันดับ 20 ได้ สาเหตุมาจากปัญหาคำพ้องความหมาย เช่น เมื่อค้นหาด้วย「ສິນເຊື່ອ」แล้ว Chunk ที่มี「ເງິນກູ້」กลับไม่ขึ้นมาในอันดับต้น ๆ การดึงข้อมูลอย่างกว้าง ๆ แล้วจัดเรียงลำดับใหม่ด้วย Reranking จึงช่วยลดการตกหล่นของผลการค้นหาได้ดีกว่า

ส่งผลลัพธ์การค้นหาไปยัง LLM เพื่อสร้างการตอบกลับเป็นภาษาลาว โดยคำนึงถึงประสบการณ์ของผู้ใช้ จึงนำ SSE (Server-Sent Events) มาใช้สำหรับการส่งข้อมูลแบบ Streaming

การ Streaming ช่วยลด TTFT (เวลาที่ใช้จนกว่าจะแสดง Token แรก) ให้เหลือประมาณ 0.8 วินาที เมื่อ Input Token เพิ่มขึ้นจากการ Inject Context ของ RAG วิธีที่รอให้สร้างข้อความทั้งหมดก่อนจะใช้เวลา 5–10 วินาที แต่หากใช้ Streaming ตัวอักษรแรกจะเริ่มแสดงผลภายใน 1 วินาที

การออกแบบ System Prompt เฉพาะสำหรับภาษาลาว:

สำหรับ Chatbot ภาษาลาว จำเป็นต้องระบุคำสั่งต่อไปนี้ใน System Prompt อย่างชัดเจน

• การกำหนดภาษาของการตอบกลับ: "หากผู้ใช้ถามเป็นภาษาลาว ให้ตอบเป็นภาษาลาวเสมอ แม้ผลลัพธ์การค้นหาจะเป็นภาษาอังกฤษหรือภาษาญี่ปุ่น ให้แปลคำตอบเป็นภาษาลาวก่อนแสดงผล" — หากไม่มีคำสั่งนี้ LLM อาจตอบเป็นภาษาอังกฤษเมื่ออ้างอิง Knowledge ที่เป็นภาษาอังกฤษ
• ข้อจำกัดด้าน Context: "ให้ตอบโดยอิงจากข้อมูลอ้างอิงที่ให้มาเท่านั้น หากไม่มีข้อมูล ให้แจ้งให้ผู้ใช้ทราบ" — เนื่องจากอัตรา Hallucination ในภาษาลาวสูงกว่าภาษาอังกฤษ การระบุข้อจำกัดอย่างชัดเจนจึงเป็นสิ่งจำเป็น
• การแสดงแหล่งอ้างอิง: ให้คำสั่งแก่ LLM ให้ส่งคืนแหล่งที่มาของ Chunk ที่ใช้ในการตอบกลับ การที่ผู้ใช้สามารถตรวจสอบหลักฐานได้จะช่วยรับประกันความน่าเชื่อถือ แม้จะเป็นภาษาที่มีทรัพยากรน้อย (Low-Resource Language)

แชทบอทที่แค่ "ทำงานได้" นั้นยังไม่เพียงพอ คุณภาพของการตอบสนองมีการเปลี่ยนแปลงอยู่ตลอดเวลาจากการเพิ่ม knowledge และการอัปเดต LLM

ในบริษัทของเรา ใช้ Mastra Evaluations เพื่อวัดผล 3 ตัวชี้วัดต่อไปนี้แบบอัตโนมัติแบบ real-time

สำหรับการประเมิน จะใช้ LLM ที่แยกต่างหากจาก model หลักที่ใช้สร้างการตอบสนอง เพื่อหลีกเลี่ยง bias จากการให้คะแนนตัวเอง ซึ่งเป็นการที่ "ประเมินคำตอบที่ตัวเองสร้างขึ้นด้วยตัวเอง"

ขอแบ่งปันรูปแบบความล้มเหลวที่บริษัทของเราเคยประสบในโครงการสำหรับลาว ทั้งหมดนี้เป็นสิ่งที่สามารถหลีกเลี่ยงได้ หากรู้ล่วงหน้าก่อน

สิ่งที่เกิดขึ้น: เมื่อนำคู่มือการทำงานภาษาลาวมาแบ่งส่วนด้วยกลยุทธ์ sentence พบว่าผลลัพธ์ออกมาสุดโต่งสองแบบ คือเอกสารทั้งหมดกลายเป็น chunk เดียว หรือไม่ก็ถูกแบ่งออกเป็นหน่วยย่อยระดับ byte สาเหตุนั้นเรียบง่ายมาก คือภาษาลาวแทบไม่มีการใช้เครื่องหมายจบประโยคที่เทียบเท่ากับ「。」เนื่องจาก sentence splitter ทำงานโดยใช้เครื่องหมายจบประโยคเป็นตัวแบ่ง จึงไม่สามารถหาจุดแบ่งใดๆ ในข้อความภาษาลาวได้เลย

วิธีแก้ไข: เปลี่ยนไปใช้กลยุทธ์ recursive แทน โดยใช้การขึ้นบรรทัดใหม่และการแบ่งย่อหน้าเป็นพื้นฐานในการทำ chunking พร้อมตั้งค่า chunk size ที่ 512 token และ overlap ที่ 50 token เนื่องจากเอกสารภาษาลาวมักมีการขึ้นบรรทัดใหม่ในแต่ละย่อหน้า วิธีนี้จึงสามารถแบ่งส่วนได้อย่างมีประสิทธิภาพในทางปฏิบัติ

สิ่งที่เกิดขึ้น: เนื่องจาก knowledge base มีเอกสารทั้งภาษาอังกฤษและภาษาญี่ปุ่นรวมอยู่ด้วย จึงเกิดกรณีที่ chunk ภาษาอังกฤษถูก hit จากคำถามภาษาลาว และ LLM ตอบกลับเป็นภาษาอังกฤษโดยตรงบ่อยครั้ง สาเหตุมาจากการที่ system prompt ไม่มีคำสั่งระบุภาษาในการตอบสนอง

ปัญหานี้เกิดขึ้นอย่างหนาแน่นในช่วงเปลี่ยนผ่านที่กำลังแปลง knowledge ภายในองค์กรซึ่งเคยมีแต่ภาษาอังกฤษมาจนถึง 2 ปีก่อนให้เป็นหลายภาษา ในส่วนที่ยังไม่มี knowledge ภาษาลาวครบถ้วน เนื่องจากมีเพียง chunk ภาษาอังกฤษเท่านั้นที่ถูก hit LLM จึงถูกดึงให้ตอบเป็นภาษาอังกฤษ

วิธีแก้ไข: ดำเนินมาตรการ 2 อย่างพร้อมกัน ได้แก่ (1) เพิ่มข้อความใน system prompt อย่างชัดเจนว่า "ต้องตอบด้วยภาษาเดียวกับภาษาของผู้ใช้เสมอ" และ (2) เพิ่ม language code ลงใน metadata ของ knowledge base และ implement filter ที่ให้ความสำคัญกับการค้นหา chunk ภาษาลาวก่อนเมื่อได้รับคำถามภาษาลาว

สิ่งที่เกิดขึ้น: เมื่อเก็บ context ของการสนทนาภาษาลาวแบบ multi-turn ไว้ 20 ข้อความ ส่งผลให้ input token เกิน 15,000 และคุณภาพของการตอบสนองลดลงอย่างเห็นได้ชัด ภาษาลาวใช้ token มากกว่าภาษาอังกฤษ 2〜3 เท่า การมี 20 ข้อความอาจไม่เป็นปัญหาสำหรับภาษาอังกฤษ แต่สำหรับภาษาลาวนั้นกินพื้นที่ส่วนใหญ่ของ context window ไปเกือบหมด

ทำให้ไม่มีพื้นที่เหลือพอสำหรับการ inject context จาก RAG (5 chunk ประมาณ 3,000〜5,000 token) ผลการค้นหาจึงถูกตัดทิ้ง และการตอบสนองที่ "ไม่ได้อ้างอิง knowledge" เพิ่มมากขึ้น

วิธีแก้ไข: เปลี่ยนการควบคุมการเก็บประวัติการสนทนาจากการนับจำนวนข้อความ ไปเป็นการกำหนดขีดจำกัดด้วยจำนวน token แทน ในกรณีของเราได้จำกัด context ของประวัติการสนทนาล่าสุดไว้ที่สูงสุด 8,000 token เพื่อให้มีพื้นที่เพียงพอสำหรับ RAG context สำหรับภาษาลาวแล้ว นี่เทียบเท่ากับประมาณ 8〜10 ข้อความในทางปฏิบัติ

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

บริษัทของเราใช้ฟีเจอร์ Live Evaluations ของ Mastra เพื่อให้คะแนน (scoring) การตอบสนองของแชทในสภาพแวดล้อม production แบบ real-time โดยการให้คะแนนจะทำงานแบบ asynchronous แยกจากการสร้างการตอบสนอง จึงไม่ส่งผลกระทบต่อความเร็วที่ผู้ใช้รับรู้

ตัวชี้วัดทั้ง 3 รายการที่วัดได้ (Answer Relevancy / Faithfulness / Retrieval Precision) จะถูกบันทึกลงในฐานข้อมูล และสามารถติดตามแนวโน้มในรูปแบบ time series ได้ การลดลงอย่างรวดเร็วของคะแนนถือเป็นสัญญาณที่บ่งชี้ถึงความบกพร่องของ knowledge หรือการเปลี่ยนแปลงพฤติกรรมของ model

การให้คะแนนคำขอทั้งหมดจะทำให้ค่าใช้จ่ายของ LLM สำหรับการประเมินพุ่งสูงขึ้น ในบริษัทของเรา เราจึงปรับอัตราการสุ่มตัวอย่างให้แตกต่างกันตามแต่ละสภาพแวดล้อม

แม้จะอยู่ที่ 10% ในสภาพแวดล้อม Production หากมี 1,000 คำขอต่อวัน ข้อมูลคะแนนก็จะสะสมได้ถึง 100 รายการต่อวัน หากตรวจสอบค่าเฉลี่ยเป็นรายสัปดาห์ ก็เพียงพอที่จะเข้าใจแนวโน้มด้านคุณภาพได้อย่างครบถ้วน

แนวทางการปรับปรุงจะแตกต่างกันไปตามแต่ละตัวชี้วัด

Retrieval Precision ต่ำ (< 0.6): การค้นหากำลังส่งคืน chunk ที่ไม่ตรงประเด็น ให้พิจารณาปรับขนาด chunk (ลดจาก 512 → 256 token), เพิ่ม knowledge ภาษาลาว และทบทวน metadata filter ในกรณีภาษาลาว การลดขนาด chunk มักช่วยให้ผลลัพธ์ดีขึ้น

Faithfulness ต่ำ (< 0.8): LLM กำลังเติมเต็มข้อมูลที่ไม่มีอยู่ในผลการค้นหา ให้แก้ไขโดยเพิ่มข้อจำกัดใน system prompt หรือลด temperature ลง (0.3 → 0.1) ควรระวังว่าภาษาลาวมีข้อมูล training data ของ LLM น้อยกว่าภาษาอังกฤษ จึงเกิด hallucination ได้ง่ายกว่า

Answer Relevancy ต่ำ (< 0.7): การตอบสนองไม่ตรงกับคำถามของผู้ใช้ ให้ตรวจสอบ Retrieval Precision ก่อน หากไม่พบปัญหาในฝั่งการค้นหา ให้ดำเนินการปรับปรุง prompt (ระบุรูปแบบคำตอบ, คำสั่งให้ถอดความคำถาม)

ในทางกลับกัน ยิ่งมี knowledge น้อย ยิ่งรู้สึกได้ถึงประสิทธิผลได้ชัดเจน เนื่องจาก LLM เพียงอย่างเดียวแทบไม่มีความรู้เฉพาะทางด้านภาษาลาว ดังนั้นเพียงแค่เพิ่ม knowledge จาก FAQ 50 รายการ ก็สามารถเปลี่ยนแปลงความแม่นยำของคำตอบได้อย่างมาก ผลของการ "เพิ่ม 50 รายการจากสถานะศูนย์" นั้นยิ่งใหญ่กว่าผลของการ "เพิ่ม 50 รายการจากสถานะที่มี 1,000 รายการอยู่แล้ว" มากนัก

สามารถจัดการได้ โดยจัดเก็บเอกสารแต่ละภาษาไว้ใน knowledge base และกรองด้วยรหัสภาษาใน metadata ในระบบของเรา เราประมวลผล 4 ภาษา ได้แก่ ภาษาญี่ปุ่น ภาษาอังกฤษ ภาษาไทย และภาษาลาว ภายใน RAG pipeline เดียว เนื่องจากภาษาไทยและภาษาลาวมีระบบการเขียนและไวยากรณ์ที่ใกล้เคียงกัน จึงสามารถรองรับได้ด้วย chunking strategy และ embedding model เดียวกัน

ระดับการตอบ FAQ (ความรู้ไม่เกิน 100 รายการ) สามารถสร้างได้ภายใน 2〜4 สัปดาห์ ค่าใช้จ่ายด้านโครงสร้างพื้นฐานและ API รายเดือนอยู่ที่ประมาณ $200〜500 สำหรับ chatbot แบบเต็มรูปแบบที่รวมการเชื่อมต่อกับระบบงาน ใช้เวลา 2〜3 เดือน โดยมีค่าใช้จ่ายรายเดือนเป็นแนวทางที่ $500〜2,000 ค่าใช้จ่ายส่วนใหญ่มาจากค่าบริการ API ของ LLM และต้องคำนึงไว้ในงบประมาณด้วยว่าภาษาลาวมีต้นทุนสูงกว่าภาษาอังกฤษ 2〜3 เท่า เนื่องจากปัญหา token inflation

ภาษาลาวคือ "ภาษาที่ LLM หลักของโลกแทบไม่รู้จัก" นั่นจึงเป็นเหตุผลที่การเติมเต็มความรู้ด้วย RAG สร้างความแตกต่างอย่างชี้ขาด การผสมผสานระหว่างกลยุทธ์การแบ่ง Chunk ที่เหมาะสม การเพิ่มความแม่นยำในการค้นหาด้วย Reranking และการติดตามคุณภาพอัตโนมัติ ทั้ง 3 อย่างนี้รวมกันทำให้สามารถสร้างการตอบสนองที่เชื่อถือได้แม้กับภาษาที่มีทรัพยากรน้อย

ทบทวน 5 ขั้นตอนที่อธิบายไว้ในบทความนี้

1. การแบ่งข้อความที่เหมาะกับคุณสมบัติของภาษาลาว (กลยุทธ์ Recursive + Overlap)
2. การสร้าง Vector DB ด้วย Supabase pgvector (Metadata พร้อม Language Code)
3. Pipeline การค้นหาแบบดึง 50 รายการ → Reranking → 5 รายการ
4. การตอบสนองแบบ Streaming ด้วย Bedrock Claude + Prompt ควบคุมภาษา
5. การติดตามอัตโนมัติ 3 ตัวชี้วัดด้วย Mastra Evaluations

มาตรการรักษาความปลอดภัย AI ของ Chatbot อธิบายไว้อย่างละเอียดใน "รายการตรวจสอบมาตรการรักษาความปลอดภัย AI สำหรับองค์กรลาว" และสำหรับผู้ที่ต้องการทำความเข้าใจภาพรวมของการนำ AI มาใช้ สามารถอ้างอิง "คู่มือการนำ AI มาใช้สำหรับองค์กรลาว" ได้เช่นกัน