- เราใช้ qwen38-uni (21GB) บน Mac สร้างแชทบอทตอบคำถามทีมเทรดจากเอกสารภายใน
- ตั้งค่า Ollama + Web UI บนเครื่องเดียว ใช้ GPU 16GB ของเราได้จริง
- ข้อจำกัด: ตอบช้ากว่าคลาวด์เล็กน้อย แต่ข้อมูลไม่ออกนอกเครื่อง
ทีมเทรดเราเคยมีเอกสาร policy, playbook, และบันทึกการตัดสินใจสะสมกันหลายร้อยหน้า ทุกครั้งที่คนใหม่เข้ามาหรือมีคำถามซ้ำ ๆ ก็ต้องถาม senior trader หรือค้นเอกสารเอง เราจึงตัดสินใจใช้โมเดลภาษาในเครื่องสร้างแชทบอทตอบคำถาม (FAQ builder) จากเอกสารทีมโดยตรง
ทำไมต้องสร้างแชทบอทตอบคำถามในเครื่องเอง?
แชทบอทในเครื่องใช้โมเดล qwen38-uni ขนาด 21GB ที่เราโหลดลง Mac พร้อม GPU 16GB ข้อดีหลักคือข้อมูลเอกสารทีมไม่ไหลออกนอกเครื่อง ต่างจากบริการคลาวด์ที่ต้องส่ง prompt และ context ออกไปทุกครั้ง เราเคยทดสอบกับเอกสาร playbook ที่มีราคาเป้าหมายและเงื่อนไขการเข้าออเดอร์ ซึ่งเราไม่ต้องการให้โมเดลภายนอกเห็น
ตามข้อมูลผลการทดสอบของเรา ณ กันยายน 2026, qwen38-uni ตอบคำถามจากเอกสารทีมได้ถูกต้องประมาณ 85% สำหรับคำถามที่เอกสารมีคำตอบชัดเจน ส่วนคำถามที่เอกสารไม่ครอบคลุม โมเดลจะเดาตอบ ซึ่งเราแก้โดยสอนโมเดลให้ตอบว่า "ไม่พบในเอกสาร" แทนการเดา
เราเลือกโมเดลนี้เพราะมีขนาดพอเหมาะกับฮาร์ดแวร์ในเครื่อง ไม่ใหญ่เกินไปจนช้า และไม่เล็กเกินไปจนตอบคำถามเชิงตรรกะไม่ได้ การตั้งค่าใช้เวลาประมาณ 1 ชั่วโมง และใช้พื้นที่ดิสก์ประมาณ 25GB รวมไฟล์เอกสาร
สร้างแชทบอทจากเอกสารทีมด้วย qwen38-uni อย่างไร?
อ่านเพิ่ม: thai model retirement
ขั้นตอนการสร้างแบ่งเป็น 3 ส่วนหลัก: เตรียมเอกสาร, ตั้งค่าโมเดล, และสร้างอินเทอร์เฟซ ส่วนที่ 1: เตรียมเอกสาร เราเก็บเอกสาร policy, playbook, และบันทึกการตัดสินใจทั้งหมดไว้ในโฟลเดอร์เดียว แล้วใช้สคริปต์ Python แปลงไฟล์ PDF และ Word เป็น text ล้วน จากนั้นแบ่งเป็น chunk ขนาด 500-1000 คำ เพื่อใช้กับ RAG (Retrieval-Augmented Generation) ส่วนที่ 2: ตั้งค่าโมเดล เราติดตั้ง Ollama บน Mac แล้วโหลด qwen38-uni ด้วยคำสั่ง ollama pull qwen38-uni โมเดลจะดาวน์โหลดประมาณ 21GB และเก็บไว้ในเครื่อง จากนั้นทดสอบด้วยคำสั่ง ollama run qwen38-uni "ทดสอบภาษาไทย" เพื่อยืนยันว่าโมเดลทำงานได้ ส่วนที่ 3: สร้างอินเทอร์เฟซ เราใช้ Open WebUI ซึ่งเป็น Web UI ที่รองรับ Ollama ติดตั้งผ่าน Docker และตั้งค่าให้เชื่อมต่อกับ Ollama ในเครื่อง จากนั้น upload เอกสารที่เตรียมไว้เป็น knowledge baseตั้งค่า RAG กับ qwen38-uni ต้องเตรียมอะไร?
อ่านเพิ่ม: thai tts pacing
RAG (Retrieval-Augmented Generation) คือเทคนิคที่ดึงข้อมูลที่เกี่ยวข้องจากเอกสารก่อนส่งให้โมเดลตอบ ทำให้โมเดลตอบจากข้อมูลจริง ไม่ใช่จาก training data เดิม เราใช้ ChromaDB เป็น vector database สำหรับเก็บ embedding ของเอกสาร chunk แต่ละ chunk จะถูกแปลงเป็น vector ด้วยโมเดล embedding ขนาดเล็ก แล้วเก็บใน ChromaDB เมื่อมีคำถามเข้ามา ระบบจะค้นหา chunk ที่คล้ายกันที่สุด 3-5 chunk แล้วส่ง context นั้นให้ qwen38-uni ตอบ การตั้งค่า ChromaDB ใช้เวลาประมาณ 30 นาที เราใช้ Python script แปลงเอกสารเป็น chunk และสร้าง embedding พร้อมกัน สคริปต์จะประมวลผลเอกสารทั้งหมดแล้วเก็บใน ChromaDB ซึ่งใช้พื้นที่ประมาณ 5GB สำหรับเอกสารทีมของเรา ข้อควรระวังคือเอกสารต้องเป็น text ที่อ่านได้ชัดเจน ไฟล์ PDF ที่สแกนเป็นภาพจะต้องผ่าน OCR ก่อน และเอกสารที่มีตารางซับซ้อนอาจสูญเสียโครงสร้างเมื่อแปลงเป็น text ซึ่งส่งผลต่อความแม่นยำของคำตอบทดสอบแชทบอทกับคำถามทีมเทรดจริงอย่างไร?
อ่านเพิ่ม: trading bot api integration guide
เราทดสอบแชทบอทด้วยคำถามจริงที่ทีมเคยถามกันบ่อย โดยแบ่งเป็น 3 กลุ่ม: คำถามที่มีคำตอบชัดเจนในเอกสาร, คำถามที่ต้องคิดวิเคราะห์, และคำถามที่เอกสารไม่ครอบคลุม กลุ่มที่ 1: คำถามที่มีคำตอบชัดเจน เช่น "policy เรื่อง maximum position size คืออะไร" แชทบอทตอบถูกต้องและอ้างอิงแหล่งที่มาในเอกสารได้ กลุ่มนี้มีความแม่นยำประมาณ 90% กลุ่มที่ 2: คำถามที่ต้องคิดวิเคราะห์ เช่น "ควรปรับ risk management อย่างไรเมื่อ volatility สูง" แชทบอทสามารถสังเคราะห์ข้อมูลจากหลายส่วนในเอกสารเพื่อตอบได้ แต่บางครั้งอาจพลาดบริบทบางประการ กลุ่มที่ 3: คำถามที่เอกสารไม่ครอบคลุม เช่น "view ของทีมเกี่ยวกับ crypto ETF คืออะไร" เราตั้งค่าให้โมเดลตอบว่า "ไม่พบในเอกสาร" แทนการเดา ซึ่งสำคัญมากเพราะเราไม่ต้องการให้โมเดลสร้างข้อมูลขึ้นมา เราวัดผลด้วยการให้ senior trader ประเมินคำตอบ 50 คำถาม พบว่า 42 คำตอบถูกต้องหรือใกล้เคียง 5 คำตอบต้องแก้ไขเล็กน้อย และ 3 คำตอบผิด ซึ่งยอมรับได้สำหรับระบบภายในทีมข้อจำกัดของแชทบอทในเครื่องคืออะไร?
ข้อจำกัดหลักคือความเร็วและการอัปเดตเอกสาร เรื่องความเร็ว: qwen38-uni บน GPU 16GB ของเราใช้เวลาคิดประมาณ 3-5 วินาทีต่อคำตอบ ซึ่งช้ากว่าบริการคลาวด์ แต่ยอมรับได้สำหรับการใช้งานภายในทีม ถ้าต้องการความเร็วมากขึ้น อาจต้องอัปเกรด GPU หรือใช้โมเดลขนาดเล็กกว่า เรื่องการอัปเดต: เมื่อเอกสารทีมอัปเดต ต้องรันสคริปต์แปลงเอกสารและสร้าง embedding ใหม่ ซึ่งใช้เวลาประมาณ 15-30 นาที เราตั้ง cron job ให้รันสคริปต์นี้ทุกสัปดาห์ตอนกลางคืน อีกข้อจำกัดคือโมเดลในเครื่องไม่สามารถเรียนรู้จาก interaction ได้เหมือนโมเดลคลาวด์ที่ fine-tune ต่อเนื่อง ดังนั้นความแม่นยำจะคงที่จนกว่าจะอัปเดตโมเดลหรือเอกสาร สำหรับทีมที่ต้องการความแม่นยำสูงมาก อาจพิจารณาใช้โมเดลขนาดใหญ่กว่าหรือใช้ hybrid approach ที่ใช้โมเดลในเครื่องสำหรับเอกสารลับ และโมเดลคลาวด์สำหรับคำถามทั่วไป เราแนะนำว่าควรเริ่มด้วยเอกสารที่สำคัญที่สุดก่อน แล้วค่อย ๆ เพิ่มเอกสารอื่น ๆ เข้าไป และควรทดสอบความแม่นยำเป็นระยะเพื่อตรวจสอบว่าระบบยังทำงานได้ดีอยู่เขียนโดย อ.บอม · ทีม THE TERMINAL | AI x Trading
