Case Study: Local RAG สำหรับสำนักกฎหมายไทย — ตรวจสัญญาด้วย AI โดยคงสิทธิ์ attorney-client

สรุปสั้น: Scenario สมมติ — สำนักกฎหมาย 20 ทนายในไทยต้องการ AI ช่วยตรวจสัญญาเร็วขึ้น แต่ใช้ ChatGPT หรือ Claude กับเอกสารลูกความไม่ได้ การใช้ Qwen3-32B + vector-DB RAG บน workstation dual-GPU 48 GB (~320,000 บาทฮาร์ดแวร์ + ~60,000 บาทติดตั้ง) ให้ทนายมี ‘ask my contract library’ assistant ที่ไม่ส่งเนื้อหาไปคนนอกเลย

ข้อเท็จจริงสำคัญ

• นี่คือ scenario สมมติเพื่อแสดงแนวคิด ไม่ใช่ client engagement จริง สำนักที่อธิบายไม่มีอยู่จริง
• Attorney-client privilege + PDPA ทำให้ cloud-API AI ใช้ไม่ได้สำหรับเอกสารลับในไทย
• Qwen3-32B dense ทำได้ดีกว่า MoE variant บน legal-language edge cases — คุ้มที่จะยอม trade throughput สำหรับ use case นี้
• Hardware ทั่วไป: workstation dual-GPU 48 GB (RTX 5090 + 5080 = ~320,000 บาท); ติดตั้ง 60,000-100,000 บาท; TCO 3 ปีประมาณ 500,000-700,000 บาท
• Matter-level access control ไม่สามารถยืดหยุ่นได้: retrieval filter ตาม case/client ID ก่อนผลลัพธ์ไปถึงโมเดล
• ผลกระทบที่คาดหวัง: การตรวจสัญญาเร็วขึ้นประมาณ 2-3 เท่าสำหรับ lookup clause ประจำ โมเดลไม่แทนที่การตัดสินของทนาย

ทำไมถึงเขียน case study ชิ้นนี้

Disclosure เหมือน case study อื่น: นี่ไม่ใช่ engagement จริง เราเขียนเพราะลูกค้าที่สนใจ — สำนักกฎหมายที่กำลังพิจารณา AI ในปี 2026 — ควรเห็นว่าเราจะคิดกับ privacy requirement ที่เข้มงวดผิดปกติของงานกฎหมายอย่างไร ก่อนที่เราจะมีรายชื่อสำนักกฎหมายจริงให้อ้างอิง เมื่อมี case จริงพร้อม consent จะแยกเผยแพร่

Legal-tech space ปี 2026 เต็มไปด้วย cloud AI startup ที่สัญญา “ตรวจสัญญาในไม่กี่วินาที” สำหรับสำนักไทยที่ผูกมัดกับทั้งจรรยาบรรณทนายและ PDPA ผลิตภัณฑ์เหล่านั้นส่วนใหญ่ใช้ไม่ได้หากไม่ลงทุน diligence ในการจัดการข้อมูลระดับที่ผลผลิตภาพที่ได้ถูกหักล้างกลับไป

Scenario (สมมติ)

สำนักกฎหมายขนาดกลางในกรุงเทพ 20 ทนายครอบคลุม corporate, M&A, และ employment practice group ผู้บริหารถูกกดดันจาก 2 ด้าน: ทนายรุ่นใหม่อยากใช้ AI tools (ใช้ ChatGPT ที่บ้านและอยากใช้ที่ทำงาน); ลูกค้าใน regulated industry เริ่มถามว่าสำนักจัดการเอกสารลับอย่างไรเมื่อใช้ AI สำนักทดสอบ cloud-based legal AI platform 2 เจ้า ปฏิเสธทั้งสอง — ไม่ใช่เพราะเทคโนโลยีแย่ แต่ compliance lead ไม่ได้คำตอบตรง ๆ ว่าข้อความในเอกสารเก็บที่ไหน นานเท่าไหร่ ใครเข้าถึงได้

สำนักติดต่อเราหาทางเลือก on-premise ที่ให้ผลผลิตภาพโดยไม่เสี่ยงสิทธิ์

ทำไมเรื่องนี้สำคัญต่องานกฎหมายไทยในปี 2026

Attorney-client privilege ในไทยเป็นแบบ contractual และ ethics-based เป็นหลัก ไม่ได้ codify แบบที่ US ทำ แต่ผลในทางปฏิบัติเหมือนกัน: เอกสารที่แชร์ภายใต้ retainer เป็นความลับ และการส่งไปคนที่ 3 โดยไม่มี consent จากลูกความ = ปัญหาจรรยาบรรณวิชาชีพ PDPA เพิ่มอีกชั้น: ข้อมูลในเอกสารกฎหมายหลายอย่าง (บันทึกการจ้างงาน, M&A due-diligence personal data, คำฟ้อง litigation) เป็น personal หรือ sensitive personal data พร้อมข้อจำกัดการโอนข้ามประเทศเดียวกับที่อธิบายใน case คลินิก ของเรา

การเรียก cloud AI API ที่มีข้อความสัญญารวมอยู่ = กรณีเลวร้ายที่สุดทั้งทำลายสิทธิ์และละเมิด PDPA Local deployment กำจัดทั้งสองความเสี่ยงในครั้งเดียว: ข้อความไม่ออกจากเครือข่ายของสำนัก

เงื่อนไขที่เราจะทำงานภายใน

• Matter-level data isolation: ทนายใน Matter A ต้อง query ข้าม Matter B ไม่ได้ Retrieval filter enforce สิ่งนี้ ไม่ใช่ prompt
• ไม่มีข้อมูลออกจากเครือข่ายสำนัก — ไม่มี cloud inference, ไม่มี analytics telemetry, ไม่มี third-party embedding model ที่ “phone home”
• สัญญาไทย + อังกฤษ: สำนักใช้ทั้งสองอย่างตลอด stack ต้องจัดการ bilingual retrieval โดยไม่ต้องแยก index
• Audit trail: ทุก query log ด้วย user, timestamp, matter, เอกสารที่ retrieve, และคำตอบที่สร้าง — retention ตาม data-retention policy ของสำนัก
• Performance: response 5-10 วินาทีสำหรับ clause-lookup query ประจำรับได้ 30 วินาทีไม่ไหว

สิ่งที่เราจะเสนอ

ฮาร์ดแวร์: workstation dual-GPU RTX 5090 (24 GB) สำหรับโมเดลหลัก, RTX 5080 (16 GB) โฮสต์ embedding model และ vector DB ใน GPU memory สำหรับ retrieval เร็ว VRAM รวม 40-48 GB Hardware capex ประมาณ 280,000-360,000 บาท รวม chassis, RAM 128 GB, NVMe 4 TB สำหรับ document vault, UPS คู่, และ drive สำรอง offsite

Software stack:

• Ollama เสิร์ฟ Qwen3-32B dense เป็น inference model หลัก เราแนะนำ dense มากกว่า MoE ตรงนี้เพราะภาษากฎหมายต้องละเอียด และ internal brutal tier ของเราเห็นว่า dense 32B ได้ 90% vs. 50% ของ 30B-A3B MoE ตัวเก่า gap 10-40 จุดสำคัญมากเมื่อ downstream user คือทนายที่ต้องตัดสินใจ
• nomic-embed-text (หรือ multilingual embedder เทียบเท่า) สำหรับ index เอกสาร โหลดบน GPU ใบที่สอง
• Qdrant หรือ Weaviate เป็น vector database พร้อม Postgres metadata layer สำหรับ case/client/privilege tagging
• FastAPI middleware บาง ๆ enforce matter-level access control: ทุกการเรียก retrieval ต้อง include authorized matter list ของผู้ใช้ และ filter ฝั่ง SQL กรองผลไม่อนุญาตออกก่อนเนื้อหาไปถึง LLM
• Web UI ผ่าน Open WebUI หรือ React custom front-end ที่มี branding สำนัก

Workflow:

1. สัญญา ingest เข้า vault (PDF / DOCX / scan → OCR ตามต้องการ), chunk พร้อม overlap, embed, index ด้วย metadata matter/client/date
2. ทนายถาม “หา indemnification clause จากสัญญา acquisition ปี 2024 ที่ cap liability ต่ำกว่า 2 เท่าของราคาซื้อ”
3. Access control ตรวจ matter ที่ทนายได้รับอนุญาต
4. Retrieval จัดอันดับ clause candidate; top 15-20 ส่ง LLM
5. LLM สังเคราะห์คำตอบพร้อม inline citation (ชื่อสัญญา + หน้า + clause number)
6. ทนายคลิก citation ใดก็ได้เพื่อดู source ต้นฉบับในที่ตั้ง
7. ทุกขั้นตอน log

ทำไม Qwen3-32B dense แทน Qwen3.6-35B-A3B: Routing ของ MoE ดีกับ chat ทั่วไป แย่กว่าใน sustained reasoning บนข้อความเทคนิค Probe 3 bench ของเราเห็นว่า dense model ชนะ MoE 35-40 จุดใน 10% ยากสุดของ prompt การตรวจสัญญาอยู่ใน 10% นั้น เราแลก throughput ประมาณ 70% เพื่อความแม่นยำ — response 5 วินาทียังเร็วพอ

ผลลัพธ์ที่คาดหวัง

Honest framing อีกครั้ง — อธิบายสิ่งที่ pattern นี้มอบโดยปกติ ไม่ใช่คำสัญญา:

• Clause lookup: query “หา clause ประเภท X ใน matter Y” ที่ปัจจุบันใช้ทนายหรือ paralegal อ่านมือ 20-40 นาที เสร็จภายใน 30 วินาทีพร้อม inline citation
• Contract comparison: “indemnification clause นี้ต่างจาก standard form ของเราอย่างไร?” ให้ diff structured ที่ทนาย review ใน 2-3 นาทีแทน 15
• Precedent search: “สำนักเคยมี position X ใน matter ก่อนหน้าไหม?” — สำคัญสำหรับความสอดคล้อง มักทำไม่ได้กับเครื่องมือก่อน AI
• สิ่งที่ไม่ได้ทำ: แทนการตัดสินของทนาย เขียนสัญญาใหม่ตั้งแต่ต้นโดยไม่มี human review หรือเป็น authority ทางกฎหมาย jurisdiction โดยไม่ verify source ต้นฉบับ ทุก output นำเสนอเป็น input สำหรับทนาย ไม่ใช่แทนที่ทนาย
• การเพิ่มผลผลิตภาพ: เราเห็น range ที่เผยแพร่ 2-3 เท่าบนงาน contract review ประจำใน deployment คล้าย ๆ กันที่อื่น เราไม่สัญญาตัวเลขเฉพาะให้ลูกค้า

คำคัดค้านที่พบบ่อย

“ถ้าโมเดล hallucinate clause ล่ะ?” RAG retrieval เป็น safeguard ทุกข้อเท็จจริงในคำตอบโมเดลต้อง ground บน passage ที่ retrieve มา และทุก citation link กลับไปเอกสารต้นทาง ทนายคลิก citation เห็นว่า passage พูดสิ่งที่โมเดลอ้างจริงไหม Hallucination ตรวจได้ในไม่กี่วินาที

“ทีม IT ของเราไม่รู้ machine learning” ไม่จำเป็น เราติดตั้ง, document, และสอน maintenance พื้นฐาน (storage, backup, user management) สำหรับคำถามระดับโมเดลหรือ tuning quarterly support retainer ครอบคลุม remote

“หุ้นส่วนของสำนักจะไม่อนุมัติ capital spend ขนาดนี้” เทียบกับเงินเดือนทนายรุ่นใหม่ 1 คนของสำนักขนาดกลางในกรุงเทพ (1-2M บาท/ปีรวม benefit + overhead) TCO รวม 3 ปี (500-700k บาท) คืนทุนถ้าประหยัดเวลา billable hour ของทนายรุ่นใหม่ได้แค่ 20% การคำนวณมักน่าสนใจกว่าที่หุ้นส่วนคาดในตอนแรก

Pattern นี้เหมาะกับใคร

• สำนักกฎหมาย 10-50 ทนาย เอกสารระดับ tens of thousands
• สำนัก boutique ที่มีลูกค้า regulated industry (financial service, healthcare) ที่ cloud AI ใช้ไม่ได้
• ทีม in-house legal ในบริษัทใหญ่ที่มีข้อกังวล privilege/IP sensitivity เหมือนกัน

ไม่เหมาะกับ: สำนักเล็กมาก (cost ไม่คุ้มต่ำกว่า 5-8 ทนาย), สำนักที่เน้น litigation เพียวที่ corpus varied เกินกว่าจะได้ประโยชน์จาก systematic indexing, สำนักที่ไม่พร้อม commit เป็นเจ้าของ infrastructure

วิธีเริ่มต้น

เหมือน case study อื่น ขั้นถัดไปคือ free 30-minute scoping call ส่งอีเมลถึง บรรณาธิการ พร้อมอธิบาย setup สำนักและสิ่งที่คุณอยากให้ระบบช่วย ตอบกลับภายใน 1 วันทำการ

ดู แพ็กเกจบริการ และ มาตรฐานบรรณาธิการ ก่อน