How BlackRock Builds Custom Knowledge Apps at Scale — วิเคราะห์แนวทาง การออกแบบ และบทเรียนสำหรับองค์กร

เราเพิ่งชมคลิปการบรรยายจากทีมวิศวกรรมข้อมูลของ BlackRock โดย Vaibhav Page และ Infant Vasanth ซึ่งนำเสนอแนวทางการสร้าง Knowledge Apps สำหรับงานด้านการจัดการการลงทุนที่เน้นเอกสารเชิงเทคนิคเป็นหลัก ข้อสรุปหลักของเราไม่ได้เป็นเพียงการเล่าซ้ำ แต่เป็นการหยิบเอาแนวคิดเชิงสถาปัตยกรรม เทคนิคปฏิบัติ และกลยุทธ์การนำไปใช้อย่างเป็นระบบ เพื่อให้ทีมงานด้านข้อมูลและ AI ในองค์กรต่างๆ สามารถนำไปปรับใช้ได้จริง เราจะสรุป ประมวล วิเคราะห์ และให้มุมมองเชิงลึกเพิ่มเติมในแต่ละประเด็นสำคัญ พร้อมคำแนะนำสำหรับการนำแนวทางนี้ไปใช้ในองค์กรที่ต้องคำนึงถึงความปลอดภัยและการกำกับดูแล.

ทำไม Knowledge Apps จึงสำคัญสำหรับสถาบันการเงิน

จุดเริ่มต้นจากข้อเท็จจริงง่ายๆ: การจัดการการลงทุนต้องรับมือกับข้อมูลจำนวนมากและหลากหลาย ทั้ง prospectus, term sheets, research reports, รายงานการปฏิบัติงาน และเอกสารกฎระเบียบ ทีมงานที่ทำหน้าที่ "operational backbone" ต้องแปลงข้อมูลเหล่านี้ให้เป็นข้อมูลเชิงโครงสร้างที่ระบบอื่นหรือผู้ใช้งานด้านการลงทุนจะนำไปใช้ได้ทันเวลา

เรื่องที่ BlackRock ยกขึ้นมาเป็นกรณีศึกษา คือ การตั้งค่า security ใหม่เมื่อมีเหตุการณ์ตลาด เช่น IPO หรือ corporate action ต่างๆ กระบวนการนี้ต้องอ่านเอกสารยาวๆ คุยกับ domain experts สร้าง structured output แล้วนำไปเชื่อมต่อกับ downstream systems — กระบวนการแบบนี้ถ้าไม่มี automation และกรอบการทำงานที่ดี ใช้เวลานานและเสี่ยงต่อความผิดพลาด

สรุปภาพรวมของแนวทางที่นำเสนอ

ทีมของ BlackRock แนะนำการสร้างกรอบงานที่โมดูลาร์ ประกอบด้วยสององค์ประกอบสำคัญคือ Sandbox และ App Factory โดย Sandbox เป็นพื้นที่ให้ domain experts ทดลอง ปรับ prompt และ extraction templates ส่วน App Factory เป็น pipeline/operator แบบ cloud-native ที่เอาความรู้จาก sandbox มาสร้างเป็นแอปที่ deploy ได้จริง

แนวคิดสำคัญคือการกระจายจุดคอขวดออกมาให้ domain experts เข้าถึงได้ทันที: prompt engineering, extraction templates, LLM strategy, transformers และ executors ถ้าจับองค์ประกอบเหล่านี้เป็นโมดูลและให้ผู้เชี่ยวชาญ domain ปรับได้เอง การ iterate จะเร็วมากขึ้น และเวลาจากแนวคิดถึงผลิตภัณฑ์จะลดลงอย่างเห็นได้ชัด

ประเภทของ Knowledge Apps ที่พบในสถาบันการเงิน

จากการประเมินการใช้งาน BlackRock แยกแอปออกเป็น 4 กลุ่มหลัก

• Document Extraction — ดึงข้อมูลเชิงเอนทิตี้และค่าอื่นจากเอกสาร (เช่น issuer, maturity, coupon)
• Workflow/Automation — สร้าง automation หรือ orchestration สำหรับกระบวนการที่มีหลายขั้นตอน
• Q&A / Chat Interfaces — ให้ผู้ใช้งานถามตอบบนฐานข้อมูลหรือ knowledge base
• Agent Systems — ระบบตัวแทนอัตโนมัติที่สามารถทำงานหลายขั้นตอนแบบอิสระ (แต่ในโดเมนที่ซับซ้อนยังต้องระวัง)

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

กรณีศึกษาเชิงลึก: New Issue Operations

เราจะเจาะดู use case ที่ทีมได้เล่าเป็นตัวอย่างเพื่อเห็นภาพการออกแบบระบบแบบเป็นรูปธรรม

โจทย์งาน

เมื่อมีหุ้นใหม่หรือ security ใหม่เข้าตลาด ทีม New Issue Operations ต้องตั้งค่า security ในระบบภายในให้เรียบร้อยก่อนที่ portfolio managers และ traders จะใช้งานได้ ขั้นตอนทั่วไปคือ รับ prospectus หรือ term sheet → ดึงข้อมูลที่จำเป็น → คุยกับ domain experts เพื่อ validate → แปลงเป็น structure → เชื่อมต่อกับ downstream systems

อุปสรรคที่พบ

ประเด็นหลักที่ BlackRock ต้องรับมือคือ

• เอกสารมีความซับซ้อนและความยาวมาก — บางครั้งเป็นเอกสารหลายพันหน้า
• ต้องอาศัยความรู้เชิงธุรกิจ (domain knowledge) สูง — rule/field dependencies เยอะ
• ต้องมีการตรวจสอบโดยมนุษย์ (human-in-the-loop) เพราะเรื่อง compliance และ auditing
• ปัจจัยด้าน deployment — ควบคุม cluster types, cost, scaling, access control

แนวทางแก้ไขที่นำมาใช้

ทีมออกแบบแพลตฟอร์มที่ประกอบด้วย:

• Sandbox สำหรับให้ operator (domain expert) ทดลองและปรับ template เช่น field definitions, data types, validations, และ inter-field dependencies
• Document management layer สำหรับ ingest, tagging, embedding และ labeling
• Low-code/no-code transformation layer เพื่อให้ operator สร้าง workflow ที่เชื่อมต่อ output ไปยัง downstream systems ได้เลยโดยไม่ต้องเขียนโค้ดเยอะ
• App Factory — cloud-native operator ที่รับ definition จาก sandbox แล้ว build หรือ deploy เป็นแอปที่ผู้ใช้งานทั่วไปใช้งานได้

ผลลัพธ์ที่ได้คือ เวลาการสร้างแอปจากเดือน/ไตรมาส ลดลงมาเป็นวันหรือสัปดาห์สำหรับ use case ที่พอเหมาะ

ปัญหาหลัก 3 ด้านเมื่อจะขยายการใช้งาน AI Apps

จากประสบการณ์ของทีม มี 3 ประเด็นที่มักเป็นอุปสรรคเมื่อจะ scale:

1) Prompt engineering และการทำงานร่วมกับ domain experts

การนิยาม prompt ที่ดีต้องใช้เวลาและ iterative มาก โดยเฉพาะในโลกการเงินที่ศัพท์เฉพาะเยอะและบริบทสำคัญ หากปล่อยให้ทีมวิศวกรหรือ data scientist เป็นคน sole owner ของ prompt แล้วคาดหวังให้ domain experts แก้ปัญหาได้เร็ว จะเกิดคอขวด

แนวทางที่แนะนำคือสร้างเครื่องมือที่ให้ domain experts ปรับ prompt/field templates ด้วย interface ที่เข้าใจง่าย พร้อม versioning และ eval metrics เพื่อเปรียบเทียบประสิทธิภาพของ prompt ต่างๆ

2) การเลือกกลยุทธ์ LLM (LLM strategy)

ไม่มีสูตรสำเร็จเดียวสำหรับทุกเอกสารหรือทุกฟีเจอร์ บางงานอาจใช้ in-context learning, บางงานต้องใช้ chain-of-thought หรือ stepwise decomposition ขึ้นกับความยากของเอกสารและขนาดของ context

ตัวอย่างความท้าทาย:

• เอกสารสั้นและชัดเจน: ส่งทั้งเอกสารพร้อม prompt ไปยังโมเดลได้
• เอกสารยาว: ต้อง chunking, summarization, หรือใช้ retriever/reader แบบ RAG ที่เก็บ embedding แล้ว retrieve relevant passages
• ปัญหา context length: บางโมเดลรับได้จำกัด การออกแบบ pipeline ที่ผสมผสาน chunking+retrieval+fusion จึงสำคัญ

ทีม BlackRock เลือกใช้หลายกลยุทธ์ผสมกัน ขึ้นกับแต่ละ instrument และใช้วิธีทดสอบเปรียบเทียบผลลัพธ์

3) Deployment และ operational concerns

การนำ app เข้าสู่ production ไม่ใช่แค่การ deploy โค้ด แต่รวมถึงการตัดสินใจทางสถาปัตยกรรม เช่น:

• จะใช้ cluster แบบไหน: CPU-only, GPU inference, หรือ burstable cluster
• ควบคุมค่าใช้จ่ายและ scaling — มี policy สำหรับการ spin-up/spin-down
• access control และ audit trail — ใครเรียกใช้อะไรเมื่อไร และข้อมูลถูกนำไปใช้ยังไง
• การรวมกับ CI/CD เพื่อให้ deployment เป็น reproducible และ traceable

ตัวอย่างเช่น ถ้า equity team ต้องวิเคราะห์ 500 research reports ภายในคืนเดียว อาจต้อง spin up GPU inference cluster แต่ในหลายๆ กรณี burstable clusters ที่ผสมกับ cloud provider จะคุ้มค่ากว่า

รายละเอียดของ Sandbox — ทำไมถึงสำคัญ

Sandbox เป็นเครื่องมือที่ช่วยให้ domain experts ทำงานได้ใกล้กับข้อมูลจริงโดยไม่ต้องเป็นวิศวกร มาดูฟีเจอร์สำคัญ:

• Prompt and template management — กำหนด field, data type, source (extracted/derived), required flags, และ dependencies
• Validation & QC checks — หลายระดับการตรวจสอบสำหรับแต่ละฟิลด์ เช่น format validation, range checks, cross-field consistency
• Run extraction and review — ให้ operator ดูผลลัพธ์ที่โมเดลดึงมา แล้วทำ annotation/feedback แบบ interactive
• Comparative evaluation — เปรียบเทียบผลลัพธ์จาก prompt/strategy/LLM ต่างๆ เพื่อเลือกแนวทางที่ดีที่สุด

สิ่งที่ทำให้ Sandbox มีคุณค่าสูงคือมันย้ายความรู้ (knowledge) จากหัวของ domain experts เข้ามาเก็บเป็น artefacts ที่ใช้ซ้ำได้ใน App Factory

App Factory — จากความรู้ไปสู่การผลิต

เมื่อ template และ workflows ผ่านการทดสอบใน sandbox แล้ว ขั้นถัดไปคือการแพ็กความรู้นั้นให้กลายเป็นแอปที่ผู้ใช้งานธุรกิจทั่วไปใช้งานได้ โดยไม่ต้องรู้รายละเอียดด้านเทคนิค

App Factory รับ definition จาก sandbox แล้วทำหน้าที่:

• สร้าง pipeline สำหรับ ingestion → extraction → transform → delivery
• ตั้งค่า runtime: กำหนด cluster type, resource limits, autoscaling policy
• ตั้งค่า access control และ logging/audit
• publish เป็นบริการหรือ UI ให้ผู้ใช้งานอัปโหลดเอกสารและรับ structured output

เป้าหมายคือลด friction ระหว่าง prototyping กับ production ให้ใกล้เคียงกับ CI/CD ของซอฟต์แวร์ทั่วไป

การออกแบบ extraction templates ที่ใช้งานได้จริง

หัวใจของการดึงข้อมูลจากเอกสารคือ template ที่ต้องรองรับกรณีต่างๆ ซึ่งทีมแนะนำให้มีการกำหนดคุณสมบัติดังนี้:

• Field name และ data type ที่ชัดเจน (string, date, numeric, enumerations)
• Source: ระบุว่า field นี้ต้อง extract จากเอกสารหรือ derive จากฟิลด์อื่น
• Required flag: ระบุว่า field จำเป็นหรือ optional
• Fill dependencies: ระบุความสัมพันธ์ระหว่างฟิลด์ เช่น ถ้า callable=true ต้องมี call_date และ call_price
• Validation rules: regex, value ranges, cross-field checks

การมี schema-like definition เหล่านี้ช่วยให้ downstream transformations และ automations ทำงานได้สม่ำเสมอ

การทำงานร่วมกับโมเดลหลายเจ้าและหลายกลยุทธ์

ความหลากหลายของโมเดลและ vendor เป็นทั้งความท้าทายและโอกาส ความท้าทายคือการต้องทดสอบและดูแลหลาย stack ความได้เปรียบคือสามารถเลือกโมเดลที่เหมาะสมกับงาน เช่น generator model สำหรับ summarization, retriever+reader สำหรับเอกสารยาว, หรือ embedding-based similarity สำหรับการค้นหา

ข้อควรปฏิบัติ:

• สร้าง abstraction layer ระหว่างแอปกับ provider เพื่อเปลี่ยนผู้ให้บริการได้โดยไม่กระทบแอป
• ทำ benchmarking และการ evaluate อย่างเป็นระบบ (metrics เช่น precision/recall สำหรับ extraction, latency, cost-per-call)
• มี fallback strategies — ถ้าโมเดลใหญ่เกิด latency สูง ให้มี path สำรอง

Human-in-the-loop และการคุมความเสี่ยง

ในงานการเงินเรื่อง compliance เป็นข้อบังคับ การวางระบบต้องคำนึงถึงการตรวจสอบโดยมนุษย์ไว้ตั้งแต่ต้น

แนวทางปฏิบัติที่ดี:

• ออกแบบ UI/UX ที่รองรับการ review และ approve — "four eyes principle"
• เก็บ audit logs ทุกคำขอ ทุกการเปลี่ยนแปลง template และการ approve
• ให้มี workflow สำหรับ escalation เมื่อผลลัพธ์มี confidence ต่ำหรือขัดแย้งกับกฎ

ระบบอัตโนมัติที่ดีที่สุดคือระบบที่ผสานมนุษย์อย่างราบรื่น ไม่ใช่พยายามแทนที่มนุษย์ทั้งหมด โดยเฉพาะในโดเมนที่ต้องการความรับผิดชอบทางกฎหมาย

การประเมิน ROI และการตัดสินใจว่าจะใช้งานหรือซื้อของพร้อมใช้งาน

หนึ่งในข้อคิดสำคัญจากทีมคือก่อนลงทุนทำระบบภายใน ต้องประเมิน ROI ให้ละเอียด บางกรณีการซื้อเครื่องมือสำเร็จรูปอาจเร็วกว่าการพัฒนาระบบภายในที่ซับซ้อน

เกณฑ์ที่ควรประเมิน:

• ระยะเวลาไปสู่การใช้งานจริง (time-to-value)
• ความสามารถในการปรับแต่ง (customizability)
• ค่าใช้จ่ายระยะยาว (TCO) รวมค่า compute, license, maintenance
• ความเสี่ยงด้านข้อมูลและ compliance

ผลสรุปคือบางครั้ง hybrid approach ที่นำแกนกลางของแพลตฟอร์มมาใช้ร่วมกับ third-party tools จะคุ้มค่าที่สุด

ความปลอดภัยและการป้องกันข้อมูล

งานเอกสารทางการเงินมักมีความลับสูง การออกแบบแพลตฟอร์มต้องมีหลายชั้นของการควบคุม:

• Infrastructure level: isolated VPCs, encryption at rest และ in transit, dedicated clusters
• Application level: RBAC, tokenization of sensitive fields, input/output sanitization
• Network & policies: egress control, monitoring of calls to external model providers
• Operational: data retention policy, explicit consent and data classification

นอกจากนี้การใช้โมเดล third-party ต้องพิจารณาเรื่อง data leakage และต้องมี contractual & technical controls เช่น private endpoints, enterprise model hosting, และ differential privacy เมื่อจำเป็น

Operational Observability: Logging, Monitoring, and Eval

การให้ความสำคัญกับ observability ทำให้สามารถติดตามปัญหา, ตรวจสอบการเบี่ยงเบน และวัดผลการเปลี่ยนแปลงของ prompt หรือ strategy ได้

เครื่องมือที่ควรมี:

• End-to-end tracing ของ pipeline
• Metrics เกี่ยวกับ accuracy ของ extraction, latency, error rates, และ cost-per-extraction
• Dashboard สำหรับ track performance ของ model versions และ prompt versions
• Data drift detection — หากข้อมูลเข้าเปลี่ยน ลักษณะเอกสารเปลี่ยน จะต้องมี alert

คำแนะนำเชิงปฏิบัติสำหรับทีมที่อยากเริ่มต้น

สรุปคำแนะนำที่ได้จากแนวทาง BlackRock และเติมมุมมองจากประสบการณ์:

• เริ่มจาก use case ที่มี ROI ชัดเจนและขอบเขตจำกัด เช่น extraction fields ที่ชัดเจน แล้วขยาย
• สร้าง sandbox สำหรับ domain experts ให้เร็วที่สุด — อย่าให้ทุกอย่างต้องผ่าน data science team เพียงฝ่ายเดียว
• ออกแบบ schema/field definitions เป็นมาตรฐานตั้งแต่ต้น เพื่อให้ downstream integrations ง่าย
• วาง strategy สำหรับ multi-model: abstraction layer, benchmarking, และ fallback
• ออกแบบ human-in-the-loop และ audit trail ตั้งแต่เริ่มต้น
• ทดสอบ load และ define cluster policies ที่ชัดเจน เช่น burstable GPU สำหรับงานเร่งด่วน
• ประเมิน ROI เทียบกับการซื้อเครื่องมือสำเร็จรูป

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

• RAG (Retrieval-Augmented Generation) — การผสมระหว่าง retriever ที่ดึง passages ที่เกี่ยวข้องจากความรู้ภายนอก และ generator ที่สร้าง output โดยอาศัยบริบทที่ถูกดึงมา
• Embedding — การแทนข้อความเป็นเวกเตอร์ตัวเลขเพื่อนำมาใช้ในการวัดความใกล้เคียงหรือดึงข้อมูลที่เกี่ยวข้อง
• Chain-of-Thought — เทคนิคให้โมเดลสร้างขั้นตอนการคิด (internal reasoning) เพื่อแก้ปัญหาซับซ้อน แต่บางครั้งต้องระมัดระวังเรื่อง hallucination
• Human-in-the-loop — กระบวนการที่มนุษย์มีส่วนร่วมในการตรวจสอบหรือแก้ไขผลลัพธ์ของระบบอัตโนมัติ ซึ่งจำเป็นในโดเมนที่มีกฎระเบียบเข้มงวด
• Burstable Cluster — กลุ่มทรัพยากรที่สามารถเพิ่มลดได้ตามความต้องการชั่วคราวเพื่อรองรับงานเร่งด่วน โดยเน้น cost-efficiency

ตัวอย่างกระบวนการปฏิบัติ: จาก prospectus ถึง structured data

จะลองอธิบายในรูปแบบขั้นตอนเพื่อให้เห็นภาพการไหลของข้อมูลจริง:

1. Ingest: Prospectus ถูกอัปโหลดผ่าน UI หรือถูก fetch จาก data platform
2. Preprocessing: OCR, page segmentation, และ basic text cleaning
3. Embedding & Indexing (ถ้าต้องการ RAG): แบ่งเอกสารเป็น chunks แล้วสร้าง embeddings เก็บใน vector DB
4. Extraction: ใช้ extraction template จาก sandbox เลือก LLM strategy ที่เหมาะ (direct prompt / retriever+reader / chain-of-thought)
5. Validation: ระบบรันทดสอบ QC rules และ cross-field validations
6. Human Review: operator ตรวจสอบ/แก้ไข fields ที่ flagged
7. Transformation: ถ้ามี derived fields ระบบคำนวณค่าจาก logic ที่กำหนดไว้
8. Delivery: ส่งออกเป็น JSON/CSV หรือนำเข้า downstream system โดยอัตโนมัติ
9. Monitoring: บันทึก metrics, logs, และ feedback เพื่อนำไปปรับ prompt/strategy

สิ่งที่เรามองว่าเป็นโอกาสและความเสี่ยงในอนาคต

โอกาส

• การลดเวลาที่ใช้ในการ onboard securities และการประมวลผลเอกสารจะช่วยให้ทีมลงทุนตอบสนองตลาดได้เร็วขึ้น
• ความสามารถของ platform ในการรวบรวมความรู้ของ domain experts เป็น artefact ที่ใช้ซ้ำได้ จะทำให้ทีมลดความเสี่ยงจากการสูญเสีย knowledge เมื่อคนย้ายงาน
• การผสานหลายโมเดลและหลายกลยุทธ์ให้เหมาะกับแต่ละงาน จะช่วยให้ได้ผลลัพธ์ที่คุ้มค่าและยืดหยุ่น

ความเสี่ยง

• Data leakage เมื่อใช้โมเดล third-party ถ้าไม่มี technical & contractual controls ที่เหมาะสม
• Hallucination ของ LLM โดยเฉพาะเมื่อต้องสรุปหรือสกัดข้อมูลจากเอกสารที่ซับซ้อน
• ถ้าไม่มี governance ที่ชัดเจน prompt และ template อาจกระจัดกระจายและทำให้ควบคุมไม่ได้

มุมมองเชิงวิศวกรรม: การออกแบบ API/Interface ระหว่าง Sandbox กับ App Factory

เพื่อให้ระบบยืดหยุ่นและ maintainable เราแนะนำให้มี contract ระหว่าง sandbox และ app factory ดังนี้:

• Artifact format: JSON schema สำหรับ template definitions รวมถึง metadata เช่น version, author, last_edit
• Validation specs: rules ที่ App Factory สามารถอ่านและแปลงเป็น runtime validators
• Execution descriptor: ระบุ LLM strategy, provider hints, resource requirements (e.g., need_gpu: true)
• Audit metadata: list ของ changes และ approvals ที่ต้องใช้สำหรับการ deploy

การมี contract ที่ชัดเจนจะช่วยให้ automation ของการ build/deploy มีความน่าเชื่อถือและปลอดภัย

คำถามที่พบบ่อย (FAQ) และคำตอบเชิงเทคนิค

Q: ควรเก็บ prompt versions ยังไง?

A: ใช้ version control สำหรับ prompt template เช่น git-backed store พร้อม metadata และ metrics ของแต่ละเวอร์ชัน เพื่อให้สามารถ rollback และเปรียบเทียบผลได้

Q: ถ้าเจอเอกสารที่มี noise สูงจาก OCR ควรทำอย่างไร?

A: ลงทุนใน preprocessing (layout-aware OCR, table extraction, error correction) และออกแบบ pipeline ให้มี fallback เช่น human review หรือใช้ model ที่ trained บน data มี noise

Q: จะวัดความแม่นยำของ extraction ยังไง?

A: สร้าง ground truth dataset สำหรับฟิลด์ที่สำคัญ และประเมิน precision/recall/F1 รวมถึงการวัดความเชื่อมั่น (confidence) เพื่อ trigger human review

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

• ออกแบบระบบเพื่อให้ domain experts เป็นศูนย์กลางของ iteration: sandbox ช่วยลด friction ได้มาก
• มีหลาย LLM strategy: ไม่มีวิธีเดียวที่ตอบทุกโจทย์ ให้เลือกผสมตามลักษณะเอกสาร
• human-in-the-loop สำคัญในสภาพแวดล้อมที่ถูกกำกับดูแล — ออกแบบ workflow ให้รองรับการตรวจสอบและ audit
• วัด ROI และเปรียบเทียบกับโซลูชันสำเร็จรูป — บางครั้งซื้อสำเร็จรูปแล้วปรับเล็กน้อยเร็วกว่าพัฒนาเองทั้งหมด
• security ต้องถูกออกแบบเป็นหลายชั้น ตั้งแต่ infrastructure ถึง application และ policy