เพิ่งชมคลิปการบรรยายของ Ben Kus, CTO ของ Box มา แล้วรู้สึกว่าเรื่องราวการพัฒนาแพลตฟอร์มเพื่อจัดการข้อมูลไม่เป็นระเบียบ (unstructured content) ด้วยแนวคิดแบบ agentic นั้นให้มุมมองทางวิศวกรรมที่ชัดเจนและเป็นประโยชน์มากสําหรับทีมเทคในองค์กร เราจะสรุปและวิเคราะห์แนวทางของ Box ตั้งแต่ปัญหาเดิม ๆ ในการดึงข้อมูลจากเอกสาร ไปจนถึงการออกแบบสถาปัตยกรรมที่ใช้ตัวแทน (agents) ควบคุมกระบวนการ AI พร้อมข้อคิดเห็นเชิงเทคนิคและเชิงกลยุทธ์ที่น่าจะช่วยทีมงานนําไปปรับใช้ได้จริง

บทนํา: ทําไมการจัดการข้อมูลไม่เป็นระเบียบยังเป็นเรื่องสําคัญ

Box คือแพลตฟอร์มเก็บและจัดการเนื้อหาแบบไม่เป็นระเบียบที่มุ่งเน้นลูกค้าองค์กรขนาดใหญ่ มาเป็นเวลานานกว่า 15 ปี ด้วยลูกค้าที่เป็นบริษัทระดับ Fortune จํานวนมาก ตัวโจทย์ที่ Box รับผิดชอบชัดเจนคือทําให้ข้อมูลที่กระจายอยู่ในเอกสาร ไฟล์สแกน และโฟลเดอร์ต่าง ๆ กลายเป็นสิ่งที่ใช้งานได้ในเชิงธุรกิจ

เรามองว่าจุดสําคัญคือ 90% ของข้อมูลในบริษัทส่วนใหญ่ยังเป็น unstructured และการแปลงข้อมูลเหล่านั้นเป็น structured form มีประโยชน์เชิงธุรกิจอย่างมาก เช่น เปิดให้ค้นหาข้อมูล คัดกรองเอกสาร สร้าง workflow อัตโนมัติ ทํา risk assessment หรือนําข้อมูลไปใช้ในระบบบัญชีหรือระบบบริหารลูกค้าต่อได้

พื้นฐานและปัญหาที่พบก่อน generative AI

ก่อนยุค generative AI อุตสาหกรรมที่ทํางานด้านการสกัดข้อมูลจากเอกสาร (IDP, Intelligent Document Processing) มีความพยายามมานาน แต่ติดปัญหาจํานวนมาก เช่น ต้องเทรนโมเดลเฉพาะของแต่ละประเภทเอกสาร ต้องเตรียม dataset ขนาดใหญ่ ต้องพึ่ง vendor และมักจะได้ระบบที่เปราะบางเมื่อต้องขยายสู่เอกสารที่หลากหลาย

แนวทางเดิมจึงมักแนะนําให้พยายามทําให้ข้อมูลเข้าสู่ระบบฐานข้อมูลตั้งแต่ต้น แทนที่จะพยายามอัตโนมัติการสกัดจากเอกสารจํานวนมาก แต่เมื่อตลาดมีโมเดล generative (เช่น GPT-3, GPT-4 และรุ่นถัด ๆ มา) ปัญหานี้เริ่มถูกท้าทาย เพราะโมเดลเหล่านี้เข้าใจภาษาธรรมชาติได้ดีและสามารถสกัดข้อมูลจากข้อความทั่วไปได้อย่างยืดหยุ่น

ข้อจํากัดเดิมที่ทําให้การสกัดยังไม่ตอบโจทย์

เราควรหยุดสังเกตว่าปัญหาไม่ได้มีแค่ความแม่นยําของโมเดลเท่านั้น แต่รวมถึงกระบวนการทั้งหมดรอบ ๆ โมเดลด้วย เช่น การอ่านภาพ (OCR), รูปแบบไฟล์ที่หลากหลาย, ภาษาต่างประเทศ, การมีข้อมูลที่กระจัดกระจาย และความต้องการมาตรฐานความปลอดภัยระดับองค์กร

ก้าวแรกกับ LLM: ทางออกที่เห็นผล แต่ไม่พอ

เมื่อ Box เริ่มทดลองกับ LLMs ในปี 2023 แนวทางแรกคือเตรียม preprocessing เช่น OCR แล้วส่งข้อความให้โมเดลเพื่อสกัดฟิลด์ที่ต้องการ วิธีนี้ใช้ prompt-based approach เดี่ยวหรือรีบูทด้วย few-shot prompts ผลลัพธ์น่าประทับใจในหลายกรณี โมเดลเชิงภาษาแบบสาธารณะสามารถทําได้ดีกว่าโมเดลเฉพาะมากในบางงาน

จุดเด่นคือความยืดหยุ่น สามารถรับเอกสารหลากหลายและไม่ต้องเทรนโมเดลเฉพาะมากนัก แต่ความยืดหยุ่นนี้เองก็มาพร้อมขีดจํากัด เมื่อขนาดและความซับซ้อนของเอกสารเพิ่มขึ้น เช่น สัญญายาวหลายร้อยหน้า มีฟิลด์หลายร้อยฟิลด์ หรือต้องทํา risk assessment แบบเชิงบริบท โมเดลเริ่มสูญเสียสมาธิในการตอบ และความผิดพลาดจากขั้นตอน OCR ถูกขยายออกมาเมื่อส่งข้อมูลให้ LLM

ความท้าทายเชิงปฏิบัติ

ประเด็นที่ Box เผชิญและน่าจะเป็นประสบการณ์ร่วมขององค์กรหลายแห่งมีดังนี้:

จุดเปลี่ยน: ทําไมต้องคิดแบบ Agentic

หลังจากผ่านช่วงเวลาที่ LLM เพียว ๆ ให้ผลลัพธ์ดีในเคสง่าย แต่ล้มเหลวในเคสที่ซับซ้อน ทีมของ Box ตระหนักว่าสิ่งที่ขาดคือสถาปัตยกรรมที่สามารถผสานหลายขั้นตอนและหลายทูลเข้าด้วยกันอย่างเป็นระบบ นั่นคือจุดที่แนวคิด agentic เข้ามามีบทบาท

agentic คืออะไร ในมุมที่ใช้จริง

เราอธิบายสั้น ๆ ว่า agentic ในที่นี้หมายถึงการจัดเรียงการทํางานให้เป็น "ตัวแทน" ที่มีวิธีคิดหรือ objective, มี prompt/instruction, สามารถเลือกใช้เครื่องมือภายในหรือภายนอก, มีหน่วยความจําหรือ directed cache, และสามารถ orchestration ขั้นตอนตามแผนได้

จุดเด่นคือการทํางานเป็น workflow แบบ directed graph ที่แต่ละ node อาจเป็นโมเดล, เป็นการเรียก OCR, เป็นการตรวจสอบกฎ (regex) หรือเป็น module ที่ทํา voting ระหว่างโมเดลหลายตัว

ออกแบบ pipeline สําหรับการสกัดข้อมูลด้วย agentic

จากประสบการณ์จริง ทีม Box ออกแบบ pipeline ที่ประกอบด้วยขั้นตอนสําคัญหลายอย่าง เราจะอธิบายลําดับและเหตุผลของแต่ละขั้นตอน พร้อมความคิดเห็นว่าทําไมวิธีนี้ได้ผล

1) เตรียมฟิลด์และจัดกลุ่ม (Field Preparation & Grouping)

ก่อนเริ่มสกัด ต้องกําหนดฟิลด์ที่ต้องการอย่างระมัดระวัง และจําแนกฟิลด์ที่เกี่ยวข้องกัน เช่น ฟิลด์เกี่ยวกับ "party" กับ "address" ควรอยู่ในกลุ่มเดียวกัน เพราะความสัมพันธ์ระหว่างฟิลด์ช่วยในการตรวจสอบความสอดคล้อง

ความคิดเห็น: ขั้นตอนนี้มักถูกมองข้าม แต่เป็นหัวใจของระบบที่แม่นยํา วิธีทําได้โดยการสร้าง metadata schema ที่ยืดหยุ่น เพื่อให้ agent เข้าใจความสัมพันธ์ระหว่างคีย์ต่าง ๆ

2) หลายคําถามหลายรอบ (Multi-query on Document)

แทนที่จะส่งทั้งชุดคําถามครั้งเดียว ค่อย ๆ ถามเป็นรอบ ๆ ให้ agent สํารวจส่วนที่เกี่ยวข้องก่อน แล้วจึงสกัดรายละเอียด วิธีนี้ช่วยลดภาระ attention ของ LLM และเพิ่มความแม่นยํา

ความคิดเห็น: การแบ่งปัญหาเป็น subtask ทําให้ตรวจสอบและแก้ไขได้ง่ายขึ้น และช่วยให้สามารถใช้โมเดลหลาย ๆ ตัวร่วมกันได้อย่างยืดหยุ่น

3) ใช้เครื่องมือหลายชนิดและ multi-model voting

หลังสกัดข้อมูล ทีมใช้ทั้ง OCR แบบคลาสสิก, LLM จากหลาย vendor, และ tool พิเศษ รวมถึงการให้โมเดล "vote" เมื่อคําตอบขัดแย้งกัน เช่น ให้ 3 โมเดลตอบ หาก 2 ใน 3 เห็นตรงกัน คําตอบนั้นอาจมีความน่าเชื่อถือมากขึ้น

ความคิดเห็น: การผสมหลายเทคโนโลยีเป็นแนวคิดพื้นฐานในการลดความเสี่ยงจากข้อผิดพลาดของแต่ละระบบ แต่ต้องคํานึงต้นทุนและเวลาเพิ่มขึ้น

4) LM as judge — ให้โมเดลเป็นผู้ตัดสินและให้ feedback

หนึ่งในเทคนิคที่ Box ใช้คือให้โมเดลอีกตัวหนึ่งทําหน้าที่ประเมินคําตอบที่ได้ แล้วให้ feedback เพื่อลองทํารอบใหม่หากยังไม่ตรงเกณฑ์ วิธีนี้ไม่เพียงบอกว่า "ไม่แน่ใจ" แต่ยังบอกว่าควรพยายามแก้จุดไหน

ความคิดเห็น: การให้โมเดลเป็น judge ช่วยลดการต้องพึ่งมนุษย์มากเกินไป แต่ต้องออกแบบ prompt และเกณฑ์การตัดสินให้ชัดเจน มิฉะนั้นอาจได้รับ feedback ที่ไม่สอดคล้อง

5) Double-check โดยใช้ภาพต้นฉบับ

เมื่อ OCR ทําพลาด การกลับไปดูภาพหน้าหนังสือหรือ PDF ต้นฉบับและให้โมเดลตรวจสอบป้ายหรือบริบทช่วยยืนยันคําตอบได้ บางกรณีใช้การ crop ภาพส่วนที่มีคําตอบแล้วส่งให้โมเดลที่เชี่ยวชาญด้าน OCR/vision ตรวจสอบอีกครั้ง

ความคิดเห็น: การผสม vision model กับ text model เป็นแนวทางที่ชาญฉลาด โดยเฉพาะเมื่อต้องรับมือกับเอกสารสแกนหรือภาพที่มี noise

ผลลัพธ์: ทําไม agentic ช่วยได้

การยกชุดงานขึ้นเป็นตัวแทนที่สามารถ orchestration ได้ทําให้แพลตฟอร์มสามารถรับมือกับเคสซับซ้อนได้ดีขึ้น ข้อดีที่เห็นได้ชัดคือ

กรณีศึกษา: Deep Research บนข้อมูลภายใน

Box ใช้แนวคิดเดียวกันกับฟีเจอร์ค้นคว้าลึก (deep research) บนข้อมูลภายในองค์กร เปรียบเทียบกับการค้นข้อมูลบนเว็บโดยโมเดลสาธารณะ ความแตกต่างคือแหล่งข้อมูลเป็นเอกสารที่เป็นทรัพย์สินขององค์กร การออกแบบต้องคํานึงสิทธิ์ การเข้าถึง และความปลอดภัย

เรามองว่า deep research แบบนี้ต้องมี directed graph ที่ประกอบด้วยขั้นตอนการค้นหา สกัดข้อมูล, จัดลําดับความสําคัญ, สังเคราะห์ และสรุปผล พร้อมขั้นตอนตรวจสอบก่อนส่งคําตอบให้ผู้ใช้

บทเรียนเชิงสถาปัตยกรรมและการทํางาน

จากการเดินทางสองปี Box สรุปบทเรียนที่สําคัญหลายข้อ ซึ่งให้แนวทางกับทีมที่กําลังจะเริ่มหรือกําลังพัฒนาแพลตฟอร์ม AI ในองค์กร

แยกความรับผิดชอบ: Agentic layer vs Scale layer

เรื่องนี้สําคัญมาก โดยเฉพาะกับองค์กรที่มีปริมาณเอกสารมหาศาล ต้องออกแบบสองชั้นให้ชัดคือ

ความเห็น: การแยกระบบนี้ช่วยให้ทีมที่ออกแบบ workflow agentic สามารถทดลองได้เร็ว โดยไม่กระทบกับระบบ storage/scale หรือจําเป็นต้องเปลี่ยนสถาปัตยกรรมของทั้งองค์กรเมื่อปรับกระบวนการ

ออกแบบให้ evolve ได้ง่าย

agentic graph ทําให้การเปลี่ยน prompt หรือเพิ่ม node ใหม่ ๆ ทําได้เร็ว โดยไม่ต้อง re-architect ทั้งระบบ ยกตัวอย่างคือใน deep research เมื่อผลลัพธ์ออกมาไม่เป็นระเบียบ ทีมเพียงเพิ่ม node สรุปผลอีกตัว ปรับ prompt แล้ว deploy

ข้อคิด: ความสามารถปรับเปลี่ยนรวดเร็วเป็นข้อได้เปรียบเชิงธุรกิจ เพราะความต้องการของลูกค้ามักเปลี่ยนเร็ว

เปลี่ยนวิธีคิดทีมวิศวกรรม: Agent-first mindset

การนํา agentic เข้าสู่ทีมไม่ได้เกิดขึ้นอัตโนมัติ ต้องให้ทีมได้ลงมือสร้างและเห็นผลจริง เราเห็นว่าเมื่อวิศวกรได้สร้าง agent เล็ก ๆ ใช้งานได้ จะเกิดความคิดใหม่ ๆ เกี่ยวกับการออกแบบ API, tools และ agent-to-agent communication

นโยบายการเลือกใช้โมเดล: Fine-tuning หรือ Agentic?

คําถามยอดนิยมคือถ้า fine-tune โมเดลแล้วจะไม่สามารถแก้ปัญหาได้ไหม Box มีมุมมองชัดเจน ว่าปัจจุบันค่อนข้างไม่สนับสนุนการ fine-tune เป็นทางหลักสําหรับ use case ของพวกเขา เหตุผลหลักมีดังนี้

ความคิดเห็น: เรามองว่า fine-tuning ยังมีที่ของมัน แต่เมื่อองค์กรต้องการรองรับหลายภาษา หลายฟอร์แมต และหลายโมเดล การพึ่ง agentic orchestration จะลดความผูกติดทาง vendor และเพิ่มความสามารถในการ evolve

การประเมินคุณภาพและกลยุทธ์การทดสอบ

Box ใช้วิธีผสมผสานหลายอย่างเพื่อวัดคุณภาพของการสกัดข้อมูล ซึ่งสําคัญมากเพราะลูกค้าองค์กรต้องการระดับความเชื่อมั่นสูง

ชุดทดสอบ (eval sets) และ challenge sets

พวกเขามีชุดทดสอบมาตรฐานและชุด challenge ที่ออกแบบให้ยากกว่าปกติ เพื่อวัดความสามารถของระบบในเคสที่ไม่ใช่ชุดคําถามมาตรฐาน

ความคิดเห็น: การมี challenge set ช่วยป้องกันการ overfitting กับเคสง่าย และเตรียมระบบให้พร้อมเมื่อผู้ใช้นําเอกสารที่ยากกว่ามาใช้

LM as judge + human feedback

วิธีประเมินอีกวิธีคือให้ LM ทําหน้าที่เป็น judge แล้วรวมกับ feedback จากผู้ใช้จริง โดยเฉพาะในลูกค้าองค์กรที่ให้ข้อมูลกลับมาเป็นค่าประเมิน คุณภาพจะดีที่สุดเมื่อผสมทั้งสองอย่าง

การออกแบบ API และแพลตฟอร์ม: API-first และความเป็นโมดูล

Box ให้ความสําคัญกับการเป็น API-first เพื่อให้ลูกค้าองค์กรสามารถเรียกใช้งาน agent ผ่าน API ได้โดยตรง ซึ่งสอดคล้องกับความต้องการในการรวมเข้ากับ workflow ขององค์กรต่าง ๆ

การออกแบบให้ agent เป็นบริการที่สามารถเรียกผ่าน API ทําให้เกิดความยืดหยุ่นในการนําไปใช้ และช่วยให้ทีมพัฒนาภายนอกสามารถสร้างเครื่องมือเสริมได้ง่าย

เครื่องมือและการเชื่อมต่อ (tools & integrations)

แพลตฟอร์มต้องรองรับการใส่ tools ที่หลากหลาย เช่น OCR engines, external DB lookups, document viewers, permission checks และองค์ประกอบ security อื่น ๆ เพื่อให้ agent ทํางานครบกระบวนการ

ความคิดเห็น: ในองค์กรที่มีข้อจํากัดด้านข้อมูล การออกแบบเครื่องมือให้รองรับ policy-aware actions สําคัญมาก เช่น agent ควรตรวจสอบสิทธิ์ก่อนดึงข้อมูลที่ละเอียดอ่อน

สิ่งที่ควรระวังและข้อจํากัดที่ยังคงมี

แม้ agentic จะช่วยแก้ปัญหาหลายอย่าง แต่ก็มีข้อจํากัดที่ต้องตระหนัก เช่น

ข้อเสนอแนะ: ควรมีการตั้งค่าระดับบริการ (service tiers) เช่น เคสเร่งด่วนให้ path แบบ lightweight เฉพาะบางฟิลด์ ส่วนเคสต้องการแม่นยําสูงให้ path agentic ครบวงจร

แนวทางปฏิบัติสําหรับองค์กรที่ต้องการเริ่ม

จากประสบการณ์ มีแนวทางปฏิบัติที่แนะนําสําหรับทีมเทคที่ต้องการย้ายไปสู่สถาปัตยกรรม agentic:

ตัวอย่าง workflow แบบสั้น (แนวคิด)

1) Ingest document → 2) Preprocess OCR → 3) Group fields & create subtasks → 4) Run multi-model extraction → 5) Vote & judge → 6) Re-run / check images if low confidence → 7) Return structured output + provenance

ความคิดเห็น: แนวนี้ทําให้แต่ละขั้นตอนสามารถติดตามและปรับปรุงได้ง่าย เมื่อมีข้อผิดพลาดสามารถย้อนกลับไปแก้เฉพาะจุด

คําศัพท์เฉพาะทางเพิ่มเติม

IDP (Intelligent Document Processing)

ระบบที่ออกแบบมาเพื่อสกัดข้อมูลจากเอกสาร รูปแบบดั้งเดิมมักใช้ OCR + rules + ML models เฉพาะงาน [https://en.wikipedia.org/wiki/Document_processing]

Agentic / Agent

ชั้นของซอฟต์แวร์ที่มี objective และสามารถ orchestrate ขั้นตอนต่าง ๆ โดยเรียกใช้โมเดลหรือทูลเพื่อแก้ปัญหา

Directed Graph

โครงสร้าง workflow ที่ node แต่ละ node แทน task บางอย่าง เช่น query, extraction หรือ validation ซึ่งสามารถกําหนดทางเดินการทํางานได้

LM as judge

การให้ Language Model หนึ่งตัวทําหน้าที่ประเมินคําตอบของโมเดลอื่น ๆ และให้ feedback เพื่อปรับปรุงผลลัพธ์

Eval sets / Challenge sets

ชุดทดสอบมาตรฐานและชุดทดสอบที่จะยากกว่าปกติ เพื่อวัดความสามารถระบบในระดับสูง

บทสรุปส่งท้ายจากทีมงาน Insiderly

บทสรุปจาก Insiderly

มุมมองโดยรวมคือ agentic architecture ไม่เพียงเป็นเทคนิคใหม่ แต่เป็นวิธีคิดที่จะเปลี่ยนวิธีการออกแบบระบบ AI ในองค์กร โดยเฉพาะเมื่อต้องจัดการกับข้อมูลที่ไม่เป็นระเบียบและซับซ้อน เรารู้สึกว่าองค์กรที่ยังลังเลอยู่ควรเริ่มทดลองกับ POC ในงานสําคัญ ไม่จําเป็นต้อง scale ทันที แต่ต้องออกแบบให้ modular เพื่อปรับปรุงต่อเนื่อง

สรุปแล้ว agentic เป็นเครื่องมือที่ทรงพลังเมื่อนํามาใช้ร่วมกับวิธีการที่รัดกุม เช่น schema design, eval sets, multi-model orchestration และการควบคุมความปลอดภัย ขอให้ทีมเทคลองคิดแบบ agent-first และแยกความรับผิดชอบของ infrastructure ให้ชัด เพื่อให้การยกระดับเป็นไปได้จริงในเชิงธุรกิจ