AI ngành dọc không bắt đầu từ model

AI ngành dọc không bắt đầu từ model

Case study Cara cho thấy AI enterprise thắng ở chẩn đoán workflow, schema nghiệp vụ và audit trail — không phải ở việc chọn model ồn ào nhất.

“Team mình muốn làm AI cho bảo hiểm, nên chọn model nào?”

Câu hỏi này nghe quen đến mức mình muốn in ra dán cạnh máy pha cà phê. Không phải vì nó sai hoàn toàn, mà vì nó giống hỏi bác sĩ: “Em nên uống thuốc gì?” trước khi nói mình đau ở đâu, đau từ bao giờ, có bệnh nền không, và đang dùng thuốc gì.

Case Cara trong mảng insurance brokerage đáng đọc không phải vì họ “dùng AI trên AWS”. Điểm đáng giữ nằm ở chỗ khác: họ không bán một chatbot thông minh hơn, họ đóng gói lại một quy trình nghiệp vụ vốn đang chảy máu thời gian.

Sau bài này, nếu bạn đang build AI cho doanh nghiệp, mình muốn bạn đổi một cách nghĩ: domain-specific AI không phải là model được dạy thêm vài thuật ngữ ngành; nó là hệ thống biết chịu trách nhiệm trong một workflow cụ thể.

Sơ đồ minh họa cho bài AI ngành dọc không bắt đầu từ model

Sơ đồ tóm tắt ý chính của bài viết.

Ca bệnh: môi giới bảo hiểm không thiếu chữ, thiếu đường đi

Trong bảo hiểm doanh nghiệp, nhân viên môi giới phải làm nhiều việc lặp đi lặp lại: điền application, so coverage giữa các policy, nhập lại dữ liệu qua nhiều hệ thống, chuyển thông tin giữa client và carrier. Ngành này còn có áp lực nhân sự: muốn tăng doanh thu nhưng không thể cứ tăng headcount tương ứng.

Điểm đau ở đây không phải “không ai biết viết email”. Điểm đau là dữ liệu nằm rải rác, biểu mẫu mỗi carrier một kiểu, yêu cầu compliance luôn rình sau gáy, và mỗi quyết định cần có dấu vết để kiểm tra lại.

Cara chọn bài toán này khá khôn: họ không cố làm một general assistant cho mọi phòng ban. Họ đi vào back-office của brokerage, nơi có đủ ba điều kiện để AI có đất diễn:

Nói thẳng ra thì: đây không phải bài toán “hỏi đáp với PDF”. Đây là bài toán điều phối nghiệp vụ có kiểm soát.

Quyết định quan trọng: đóng khung workflow trước, chọn model sau

Các team dễ bị cuốn vào câu hỏi model: LLM nào, context window bao nhiêu, benchmark ra sao. Nhưng trong case này, quyết định nền là đóng khung workflow bảo hiểm thành các bước AI có thể tham gia mà vẫn kiểm soát được.

Có thể mổ hệ thống theo 5 lớp:

  1. Domain schema — mô hình dữ liệu nghiệp vụ: policy, coverage, limit, deductible, carrier requirement, applicant data. Nếu không có lớp này, AI chỉ đang đọc chữ, chưa hiểu “xương sống” của hồ sơ.
  2. Document intelligence — trích xuất và chuẩn hóa thông tin từ tài liệu. Không chỉ OCR, mà còn map field vào schema đúng.
  3. Retrieval — tìm lại tài liệu, precedent, điều khoản liên quan. Với hệ thống enterprise, retrieval là nơi quyết định AI có “khám đúng hồ sơ” hay lôi nhầm bệnh án.
  4. Orchestration — điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành việc. Ví dụ: đọc application, kiểm tra thiếu field, đối chiếu coverage, sinh draft cho agent duyệt.
  5. Governance — kiểm soát truy cập, logging, PII, audit trail, human review. Đây là lớp khiến hệ thống sống được trong môi trường regulated.

Điểm thú vị: lớp model nằm trong hệ thống, nhưng không phải trung tâm vũ trụ. Model là một bộ phận xử lý; workflow mới là bệnh án đầy đủ.

Ví dụ cụ thể: giả sử team bạn làm AI cho một công ty môi giới ở Việt Nam. Nếu chỉ đưa policy PDF vào chatbot, user hỏi “gói này thiếu gì so với yêu cầu của carrier X?”, câu trả lời có thể nghe hợp lý nhưng khó kiểm chứng. Còn nếu bạn có schema rõ, hệ thống sẽ biết carrier X cần các trường nào, hồ sơ hiện thiếu trường nào, tài liệu nào chứng minh điều đó, và bước tiếp theo nên giao cho ai duyệt.

Đó là khác biệt giữa “trả lời hay” và “làm được việc”.

Hệ quả vận hành: AI ngành dọc cần hồ sơ theo dõi, không chỉ demo đẹp

Trong các case enterprise gần đây, mình thấy một mẫu lặp lại. Siemens không hiện đại hóa legacy code bằng cách ném toàn bộ codebase vào coding assistant rồi cầu may; họ phải tạo lớp knowledge đủ hiểu code công nghiệp. Amazon Finance xử lý regulatory inquiries cũng không chỉ cần RAG — retrieval-augmented generation, tức sinh câu trả lời dựa trên tài liệu được truy xuất — mà còn cần state management, observability và knowledge base riêng cho từng team. Databricks khi nói về revenue cycle trong healthcare cũng nhấn mạnh rằng parse định dạng chuẩn như X12 chưa đủ; workflow mới là phần khó.

Các case khác ngành, nhưng cùng một triệu chứng: AI fail không phải vì không biết nói, mà vì không biết nằm ở bước nào trong quy trình.

Với Cara, hệ quả tốt nếu làm đúng là brokerage có thể giảm các bước thủ công và tăng độ nhất quán. Nhưng hệ quả vận hành đi kèm cũng không nhẹ:

Confidence ở đây không nên hiểu là “model tự tin bao nhiêu phần trăm” theo kiểu trang trí dashboard. Trong workflow thật, confidence nên gắn với quyết định: tự động đi tiếp, yêu cầu bổ sung tài liệu, hay chuyển cho người có thẩm quyền.

Chỗ dễ bị thổi quá tay: domain-specific không đồng nghĩa fine-tune ngay

Một hiểu lầm phổ biến: cứ AI ngành dọc là phải fine-tuning — tinh chỉnh model bằng dữ liệu riêng. Fine-tuning có chỗ dùng, nhưng trong nhiều workflow regulated, nó không giải quyết vấn đề gốc.

Nếu dữ liệu carrier thay đổi, biểu mẫu cập nhật, quy định mới xuất hiện, fine-tune không tự giúp bạn biết tài liệu nào đang là bản mới nhất. Nếu audit hỏi “vì sao hệ thống kết luận hồ sơ này thiếu coverage A?”, câu trả lời “vì model đã học” không đủ an toàn.

Framework mình hay dùng khi hội chẩn kiến trúc AI ngành dọc:

| Câu hỏi | Nếu câu trả lời là “có” | Ưu tiên |
|---|---|---|
| Kiến thức thay đổi thường xuyên? | Carrier requirement, regulation, pricing rule cập nhật liên tục | Retrieval + versioned knowledge base |
| Output cần truy vết? | Compliance, finance, insurance, healthcare | Citation, audit log, human review |
| Format đầu vào rất đa dạng? | PDF scan, email, spreadsheet, form | Document pipeline + schema mapping |
| Cách viết chuyên ngành cố định? | Reply template, clause language, internal tone | Có thể cân nhắc fine-tuning hoặc prompt template |
| Cần gọi hệ thống nội bộ? | CRM, policy admin, ticketing, data warehouse | Tool calling — model gọi API/tool thay vì chỉ trả lời chữ |

Điểm mấu chốt: fine-tune là một toa thuốc, không phải chẩn đoán. Nếu bệnh nằm ở dữ liệu rời rạc và workflow không có checkpoint, uống nhầm thuốc chỉ làm bạn tốn thêm tiền GPU.

Một buổi chiều để soi lại hệ thống của bạn

Không cần dựng lại toàn bộ platform. Nếu bạn là tech lead đang có một ý tưởng AI ngành dọc, hãy dành một buổi chiều làm bài kiểm tra nhỏ này.

Bước 1: Vẽ “đường đi của một hồ sơ”

Chọn một workflow thật: xử lý claim, review hợp đồng, trả lời inquiry, chuẩn hóa application. Ghi lại từng bước:

Input → Extract → Validate → Compare → Decide → Draft → Review → Submit → Archive

Ở mỗi bước, đánh dấu: AI nên làm, người nên làm, hay hệ thống rule-based nên làm.

Bước 2: Tách data model khỏi prompt

Đừng nhét mọi thứ vào prompt dài. Viết ra schema tối thiểu:

policy:
  carrier: string
  effective_date: date
  coverage:
    type: string
    limit: number
    deductible: number
  source_documents:
    - document_id
    - page
    - extracted_field

Nếu không viết được schema, bạn chưa sẵn sàng automate. Bạn mới đang nhờ AI đoán hộ nghiệp vụ.

Bước 3: Định nghĩa điểm dừng an toàn

Mỗi workflow cần “triage” — phân luồng xử lý theo mức rủi ro:

Bước 4: Gắn log với quyết định, không chỉ request

Log kiểu “user hỏi gì, model trả lời gì” là chưa đủ. Bạn cần biết:

Đây là phần nhiều demo bỏ qua, nhưng production sẽ hỏi đầu tiên.

Bài học giữ lại từ Cara

Cara đáng chú ý vì họ xuất phát từ người từng vận hành brokerage thật, rồi biến copilot nội bộ thành sản phẩm. Siemens, Amazon Finance, Databricks hay Vexcel cũng cho thấy cùng một hướng: AI enterprise hiệu quả khi nó bám vào domain, dữ liệu, checkpoint và trách nhiệm vận hành.

Điều bạn nên nghĩ khác sau bài này: đừng bắt đầu dự án AI ngành dọc bằng câu “dùng model nào?”; hãy bắt đầu bằng “quyết định nào trong workflow cần được hỗ trợ, và bằng chứng nào khiến quyết định đó đáng tin?”

Model tốt giúp hệ thống nói trôi chảy. Thiết kế đúng giúp hệ thống không phát thuốc nhầm toa.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo