On-premise เต็มรูปแบบ
ทุกชั้นรันในศูนย์ข้อมูลขององค์กร ข้อมูลไม่ออกจากเครือข่ายเลย เหมาะกับข้อมูลที่มีการกำกับดูแลเฉพาะ ต้นทุนอยู่ที่การลงทุนครั้งแรกและพื้นที่ศูนย์ข้อมูล
สถาปัตยกรรมอ้างอิง
สถาปัตยกรรมอ้างอิงสำหรับ Enterprise AI
สถาปัตยกรรม Enterprise AI ที่ใช้งานได้จริงมีหกชั้น ตั้งแต่พนักงานที่ใช้งานลงไปถึงเซิร์ฟเวอร์ GPU ในศูนย์ข้อมูล รูปแบบเดียวกันนี้ใช้ได้กับธนาคาร โรงพยาบาล โรงงาน มหาวิทยาลัย และหน่วยงานรัฐ ต่างกันที่ขนาดของแต่ละชั้นและข้อกำหนดด้านกฎระเบียบที่บังคับใช้
ภาพรวม
หกชั้น จากผู้ใช้ลงไปถึงฮาร์ดแวร์
อ่านจากบนลงล่างคือลำดับที่เราออกแบบ อ่านจากล่างขึ้นบนคือลำดับที่เราติดตั้ง แต่ละชั้นเปลี่ยนได้โดยไม่ต้องรื้อชั้นอื่น ซึ่งเป็นเหตุผลหลักที่แยกชั้นตั้งแต่แรก
ความผิดพลาดที่พบบ่อยที่สุดคือการซื้อฮาร์ดแวร์ก่อนแล้วค่อยหางานให้มันทำ ผลลัพธ์คือ GPU ที่ใช้งานจริงไม่ถึงครึ่ง หรือระบบที่ช้าจนพนักงานเลิกใช้ภายในเดือนแรก ลำดับที่ถูกต้องคือเริ่มจากงาน แล้วไล่ลงมาถึงเครื่อง
พนักงาน (Employees)
01ผู้ใช้งานจริงในองค์กร เข้าผ่านบัญชีเดิมด้วย SSO ไม่ต้องจำรหัสผ่านชุดใหม่
Enterprise AI Interface
02หน้าจอสนทนา ค้นหาเอกสาร และเรียกใช้งาน agent สิทธิ์การเข้าถึงยึดตามกลุ่มใน IAM
Mimir Suites
03ชั้นซอฟต์แวร์ที่เชื่อมหน้าจอผู้ใช้เข้ากับโมเดล จัดการสิทธิ์ ข้อมูลองค์กร และ audit log
- RAG
- Agents
- OCR
- Applications
Model Serving
04รันโมเดลด้วย vLLM หรือ TGI ทำ batching และ routing ระหว่างโมเดลหลายตัวบนคลัสเตอร์เดียว
GPU Infrastructure
05เซิร์ฟเวอร์ GPU, storage, networking และระบบสำรอง ตั้งอยู่ในศูนย์ข้อมูลที่องค์กรกำหนด
รายละเอียดแต่ละชั้น
แต่ละชั้นรับผิดชอบอะไร
คำอธิบายระดับที่ทีม IT ใช้ประเมินได้ว่าระบบจะเข้ากับสภาพแวดล้อมเดิมขององค์กรอย่างไร
- พนักงาน
- ผู้ใช้จริงคือจุดตั้งต้นของการออกแบบ ไม่ใช่ปลายทาง เราเริ่มจากงานที่หน่วยงานทำอยู่ทุกวัน เช่น ค้นหาเงื่อนไขในสัญญา สรุปรายงาน หรือดึงข้อมูลจากเอกสารสแกน แล้วจึงย้อนกลับไปกำหนดว่าโครงสร้างพื้นฐานต้องรองรับอะไร การเริ่มจากสเปกเครื่องก่อนมักได้ระบบที่แรงเกินความจำเป็นในด้านหนึ่งและไม่พอในอีกด้านหนึ่ง
- Enterprise AI Interface
- หน้าจอสนทนา ค้นหาเอกสาร และเรียกใช้ agent เข้าใช้งานผ่าน SSO ด้วยบัญชีองค์กรเดิม สิ่งที่ผู้ใช้แต่ละคนเห็นถูกจำกัดด้วยกลุ่มสิทธิ์ใน directory ที่ใช้อยู่ ไม่ใช่ด้วยรายชื่อผู้ใช้ชุดใหม่ที่ต้องดูแลแยก ทุกคำตอบแสดงเอกสารต้นทางที่ใช้อ้างอิงเพื่อให้ผู้ใช้ตรวจสอบได้เอง
- Mimir Suites
- ชั้นที่เชื่อมหน้าจอผู้ใช้เข้ากับโมเดล จัดการว่าเอกสารใดถูกส่งให้โมเดลในแต่ละคำถาม บังคับใช้สิทธิ์การเข้าถึงก่อนการค้นคืน เก็บ audit log และเปิด API ให้ระบบเดิมขององค์กรเรียกใช้ การมีชั้นนี้ทำให้เปลี่ยนโมเดลข้างล่างได้โดยที่ผู้ใช้ข้างบนไม่ต้องเปลี่ยนวิธีทำงาน
- RAG, Agents, OCR, Applications
- RAG คือการค้นคืนเอกสารภายในมาประกอบคำตอบ agents คือลำดับงานที่เรียกเครื่องมือหลายตัวต่อกัน OCR แปลงเอกสารสแกนและ PDF เป็นข้อความที่ค้นได้ และ applications คืองานเฉพาะขององค์กรที่สร้างทับความสามารถทั้งสาม ทั้งหมดใช้ชุดสิทธิ์และ audit log เดียวกัน
- Model Serving
- โมเดลถูกให้บริการผ่าน runtime อย่าง vLLM หรือ TGI ซึ่งทำ continuous batching เพื่อให้ GPU ทำงานเต็มประสิทธิภาพเมื่อมีผู้ใช้พร้อมกันหลายคน ชั้นนี้ยังทำหน้าที่ routing ระหว่างโมเดลหลายตัว เช่น โมเดลขนาดเล็กสำหรับงานสรุป และโมเดลขนาดใหญ่สำหรับงานที่ต้องการเหตุผลซับซ้อน
- GPU Infrastructure
- เซิร์ฟเวอร์ GPU, storage สำหรับเอกสารและ vector index, เครือข่ายภายใน และระบบสำรองไฟ ตั้งอยู่ในศูนย์ข้อมูลที่องค์กรกำหนด ขนาดของชั้นนี้เป็นผลลัพธ์ของทุกชั้นด้านบน ไม่ใช่จุดเริ่มต้น และเป็นชั้นที่แก้ทีหลังได้ยากที่สุด จึงต้องเผื่อการขยายไว้ตั้งแต่แรก
การประเมินขนาด
อะไรกำหนดขนาดของระบบ
เราไม่เสนอสเปกก่อนได้คำตอบของห้าข้อนี้ ตัวเลขที่ได้จากการเดามักผิดไปในทางที่แก้แพง
- จำนวนผู้ใช้พร้อมกัน
- ไม่ใช่จำนวนพนักงานทั้งหมด แต่คือจำนวนคำขอที่เข้ามาพร้อมกันในช่วงพีค ตัวเลขนี้กำหนดจำนวน GPU มากกว่าตัวแปรอื่นใด องค์กรที่มีพนักงานหนึ่งพันคนอาจมีผู้ใช้พร้อมกันจริงเพียงหลักสิบในช่วงเช้า เราประเมินจากรูปแบบการทำงานจริงของหน่วยงาน
- ขนาดโมเดลและ VRAM
- โมเดลขนาดกลางที่ quantize แล้วมักพอสำหรับงานถามตอบเอกสารภาษาไทย ส่วนงานที่ต้องการการให้เหตุผลยาวหรือรองรับ context ขนาดใหญ่ต้องการ VRAM มากขึ้นอย่างมีนัยสำคัญ เราเลือกโมเดลก่อนแล้วจึงคำนวณ VRAM รวม KV cache ตามความยาว context และจำนวนคำขอพร้อมกันที่ตั้งไว้
- ปริมาณและชนิดของเอกสาร
- จำนวนหน้า สัดส่วนเอกสารสแกนที่ต้องผ่าน OCR และความถี่ในการอัปเดต กำหนดขนาด storage ปริมาณงาน embedding และรอบการ reindex เอกสารสแกนภาษาไทยจำนวนมากเปลี่ยนรูปโครงการมากกว่าที่คนส่วนใหญ่คาด เพราะงาน OCR เป็นภาระต่อเนื่อง ไม่ใช่งานครั้งเดียว
- ข้อกำหนดด้านความพร้อมใช้งาน
- ระบบที่หยุดได้ในช่วงบำรุงรักษากับระบบที่ต้องพร้อมใช้ตลอดเวลามีต้นทุนต่างกันชัดเจน หากต้องการอย่างหลัง ต้องมีโหนดสำรองพอที่จะรับโหลดเต็มขณะถอดเครื่องหนึ่งออก และต้องออกแบบ storage กับเครือข่ายให้ไม่มีจุดล้มเหลวจุดเดียว
- การเชื่อมต่อกับระบบเดิม
- directory สำหรับ SSO, ระบบจัดเก็บเอกสาร, ERP หรือระบบงานเฉพาะขององค์กร แต่ละจุดเชื่อมต่อมีข้อกำหนดด้านสิทธิ์และรอบการซิงก์ของตัวเอง ควรระบุให้ครบตั้งแต่ขั้นออกแบบ เพราะเป็นสาเหตุที่พบบ่อยที่สุดของการเลื่อนกำหนดส่งมอบ
รูปแบบการติดตั้ง
ติดตั้งไว้ที่ไหนได้บ้าง
การเลือกขึ้นกับชนิดของข้อมูลและข้อกำหนดด้านกฎระเบียบ ไม่ใช่ขนาดขององค์กร
Private cloud
รันบนทรัพยากรที่จัดสรรเฉพาะองค์กรในผู้ให้บริการที่เลือกไว้ เริ่มได้เร็วกว่าและขยายง่ายกว่า แต่ต้องพิจารณาเรื่องที่ตั้งของข้อมูลและสัญญาการเข้าถึงของผู้ให้บริการ
Hybrid
งานที่แตะข้อมูลอ่อนไหวรันในองค์กร งานที่ไม่แตะ เช่น การแปลงเอกสารสาธารณะ ย้ายออกไปข้างนอกได้ ใช้ชั้นซอฟต์แวร์และการควบคุมสิทธิ์ชุดเดียวกันทั้งสองฝั่ง
ส่งบริบทขององค์กรมาให้เรา แล้วเราจะตอบกลับด้วยสถาปัตยกรรมที่เป็นไปได้และข้อกำหนดด้านฮาร์ดแวร์ที่ตามมา
ปรึกษา Enterprise AI Architect