Document AI / RAG Pilot

Offer brief Document AI / RAG Pilot: biến lớp xử lý tài liệu thành gói pilot 7-14 ngày có chỉ số nghiệm thu, phân tích license, pricing VND và lộ trình mở rộng.

Secure document AI pilot workspace with PDFs, tables, citations, retrieval paths, evaluation checks, and compliance controls.

Bước tiếp theo

Biến điều vừa đọc thành hành động

Lưu bài để đọc lại, tạo kế hoạch 7 ngày hoặc mở playbook phù hợp.




route
Xem playbook liên quan
Đi từ kiến thức sang hướng triển khai phù hợp.

Offer brief thương mại hóa từ cụm Document AI và RAG trong kho tri thức AIToEarn. Mục tiêu: biến lớp xử lý tài liệu — khâu bẩn nhất và khó nhất của mọi sản phẩm AI — thành một gói pilot 7–14 ngày bán được cho SME, consultant và professional service.

Document AI / RAG Pilot là gói thiết lập hệ thống hỏi đáp trên tài liệu nội bộ có nguồn dẫn, có phạm vi rõ và có số đo nghiệm thu. Điểm khác biệt của bản cập nhật này so với cách làm RAG phổ biến: chúng tôi coi chất lượng dữ liệu đầu vào là sản phẩm chính, không phải giao diện chatbot.

Định vị gói

Khách hàng không mua “chatbot đọc PDF”. Thị trường đã bão hoà những demo hỏi đáp tài liệu trả lời trôi chảy nhưng sai chi tiết. Thứ khách trả tiền là một quy trình giúp họ:

  • gom tài liệu rải rác thành knowledge base có cấu trúc và có chủ sở hữu;
  • nhận câu trả lời kèm nguồn dẫn tới đúng trang, đúng điều khoản thay vì diễn giải mơ hồ;
  • giảm thời gian tra cứu trong hợp đồng, policy, SOP, proposal, báo cáo, hồ sơ khách hàng;
  • kiểm chứng được câu trả lời dựa trên tài liệu gốc, và biết khi nào hệ thống không đủ dữ liệu để trả lời;
  • có số liệu để quyết định nên mở rộng hay dừng, thay vì cảm tính.

Một câu định vị để dùng khi bán: “Chúng tôi không bán cho anh một con bot. Chúng tôi biến kho tài liệu của anh thành thứ mà bất kỳ AI nào cũng trả lời đúng được — và đưa cho anh con số chứng minh.”

Tín hiệu thị trường hậu thuẫn

Cụm công cụ xử lý tài liệu là nhóm tăng trưởng bền nhất trong các bản tin AIToEarn gần đây. Bản tin ngày 01/09/2026 dành trọn cho tầng dữ liệu và kết luận: khi mô hình ngày càng rẻ và giống nhau, lợi thế cạnh tranh dịch chuyển về chất lượng dữ liệu đầu vào — ai làm chủ khâu biến PDF, hợp đồng, hoá đơn và trang web lộn xộn thành context sạch sẽ chiếm phần khó nhất, và dễ bán nhất, của mọi sản phẩm AI.

Ba lý do khiến đây là cụm phù hợp nhất cho đội nhỏ:

  • Không cần huấn luyện mô hình, không cần GPU đắt. Toàn bộ giá trị nằm ở kỹ thuật xử lý và kỷ luật kiểm thử — thứ một người làm được.
  • Nguồn cung công cụ đã chín. Kho tri thức AIToEarn hiện có trang phân tích riêng cho gần như toàn bộ mắt xích: MarkItDown (~177,2k sao, ghi nhận 01/09), Firecrawl (~166,2k sao, ghi nhận 01/09), RAGFlow (73k sao) và AnythingLLM (65k sao) — cùng lớp Rust tốc độ cao mới ra như Anydoc và pdf-inspector.
  • Giấy phép thoáng, bán lại được. Xem phần phân tích license bên dưới — đây là điều kiện tiên quyết trước khi bàn tới doanh thu.

Lưu ý minh bạch: mọi số sao là con số ghi nhận tại thời điểm biên tập bản tin, mang tính tham khảo và thay đổi theo ngày.

Phân tích giấy phép trước khi bàn doanh thu

Toàn bộ stack đề xuất trong gói này đã được đối chiếu trực tiếp với file LICENSE trên kho mã nguồn. Kết quả:

Thành phần Giấy phép Hệ quả thương mại
MarkItDown (Microsoft) MIT Self-host, chỉnh sửa, bán lại dịch vụ — tự do
Docling (IBM) MIT Tự do như trên
Anydoc (Firecrawl) MIT Tự do như trên
Docstrange (NanoNets) MIT Tự do như trên
AnythingLLM MIT Tự do như trên
Unstructured Apache-2.0 Tự do, kèm điều khoản cấp phép sáng chế
RAGFlow Apache-2.0 Tự do, kèm điều khoản cấp phép sáng chế
ContextGem Apache-2.0 Tự do, kèm điều khoản cấp phép sáng chế

Kết luận thực dụng: bạn được self-host toàn bộ, tuỳ biến, đóng gói dưới thương hiệu riêng và bán theo mô hình dịch vụ. Ba lưu ý bắt buộc giữ trong hợp đồng: giữ nguyên thông báo bản quyền của từng thư viện; không dùng nhãn hiệu của dự án gốc để đặt tên dịch vụ; và kiểm tra lại giấy phép của bất kỳ thư viện phụ trợ nào bạn thêm vào sau — một thành phần AGPL lọt vào có thể kéo theo nghĩa vụ mở mã cho toàn hệ thống.

ICP / khách hàng đầu tiên

  • Văn phòng luật nhỏ cần tra cứu hợp đồng, điều khoản, quy trình tư vấn.
  • Consultant B2B cần tổng hợp tài liệu khách hàng, meeting note, proposal, audit memo.
  • Agency hoặc studio có nhiều brief, brand guideline, campaign report.
  • SME có SOP, policy, tài liệu đào tạo và tài liệu vận hành nằm rải rác.
  • Phòng khám, trung tâm đào tạo, dịch vụ HR cần hỏi đáp trên tài liệu chuyên môn nhưng chưa sẵn sàng đưa dữ liệu lên cloud.

Dấu hiệu nhận biết khách tốt: họ trả lời được câu “một tháng nhân sự mất bao nhiêu giờ đi tìm lại thông tin đã có?”. Nếu không có con số, nỗi đau chưa đủ lớn để ký hợp đồng — hãy bán gói scan nhỏ trước.

Không nên bắt đầu với enterprise procurement hoặc dữ liệu cực kỳ nhạy cảm khi chưa có quy trình bảo mật, phân quyền và audit log rõ ràng.

Vấn đề khách hàng đang gặp

  • File nằm rải rác trong Drive, email, folder nội bộ, Notion, PDF và slide;
  • nhân sự mất thời gian tìm lại câu trả lời tổ chức đã có sẵn;
  • AI cloud trả lời nhanh nhưng không dẫn nguồn đủ tin để dùng cho quyết định;
  • tài liệu dài có bảng, layout nhiều cột, bản scan hoặc nhiều phiên bản khiến retrieval sai âm thầm;
  • chủ sở hữu không biết câu trả lời dựa trên nguồn nào nên không dám ra quyết định dựa vào nó;
  • scope mở quá rộng khiến pilot RAG biến thành dự án hạ tầng kéo dài không có điểm dừng.

Vấn đề thứ tư là nguyên nhân gốc bị bỏ qua nhiều nhất: token bẩn làm hỏng RAG và tốn tiền gọi mô hình. Một bảng bị parse sai thứ tự đọc sẽ tạo ra câu trả lời sai mà nghe vẫn rất thuyết phục. Đây chính là chỗ gói dịch vụ này tạo giá trị.

Kiến trúc và repo stack đề xuất

Stack chia làm ba lớp rõ ràng để có thể báo giá và bàn giao từng phần.

Lớp 1 — Ingest và làm sạch (nơi tạo ra lợi thế):

  • MarkItDown — chuyển PDF, Office, ảnh, HTML sang Markdown sạch; lựa chọn mặc định cho tài liệu văn phòng.
  • Docling — parse PDF, DOCX, PPTX giữ được cấu trúc bảng và bố cục đọc, mạnh với tài liệu nhiều cột.
  • Anydoc và pdf-inspector — cặp thư viện Rust parse ở mức mili-giây, dùng khi khối lượng tài liệu lớn và chi phí xử lý trở thành vấn đề.
  • Docstrange — xử lý tài liệu scan cần OCR, xuất Markdown/JSON/CSV.
  • Unstructured — lớp ingest đa định dạng, phù hợp khi nguồn tài liệu tạp.
  • ContextGem — trích xuất dữ liệu có cấu trúc theo schema, dùng cho hợp đồng và biểu mẫu có trường cố định.

Lớp 2 — Index và hỏi đáp:

  • RAGFlow — nền tảng RAG có workflow rõ, phù hợp khi khách cần kiểm soát pipeline.
  • AnythingLLM — giao diện self-host, triển khai nhanh, phù hợp pilot ngắn.
  • PageIndex — giữ cấu trúc trang và mục cho tài liệu dài, cải thiện chất lượng trích dẫn.

Lớp 3 — Vận hành, bộ nhớ và rào chắn:

  • n8n — điều phối import, refresh tài liệu định kỳ, gửi báo cáo, nhắc review.
  • mem0 hoặc Graphiti — lớp bộ nhớ khi pilot cần giữ bối cảnh khách hàng qua nhiều phiên.
  • LLM Guard và Guardrails — lọc dữ liệu nhạy cảm và ràng buộc cấu trúc đầu ra trước khi trả kết quả cho người dùng.

Nguyên tắc chọn: bắt đầu bằng cấu hình mỏng nhất chạy được (MarkItDown hoặc Docling + AnythingLLM), chỉ thêm thành phần khi có một lỗi cụ thể đo được đòi hỏi nó. Mỗi thư viện thêm vào là một khoản nợ vận hành mà bạn phải trả sau khi bàn giao.

Deliverables

  • Audit tài liệu: loại file, quyền sử dụng, độ nhạy cảm, chất lượng OCR và layout, chủ sở hữu từng nhóm tài liệu.
  • Scope pilot chốt bằng văn bản: một domain tài liệu, 50–300 file hoặc một thư mục nguồn có kiểm soát.
  • Knowledge base đầu tiên: tài liệu đã parse, chunk, index, gắn nguồn tới trang và mục.
  • Bộ 30 câu hỏi kiểm thử thật thu từ chính người dùng cuối, kèm đáp án chuẩn do khách xác nhận.
  • Bộ prompt hỏi đáp có quy tắc trích dẫn bắt buộc và fallback “không đủ dữ liệu”.
  • Bảng QA ghi câu hỏi, câu trả lời, nguồn, đúng/sai, ghi chú cần sửa — công cụ khách tự dùng sau khi bàn giao.
  • Báo cáo chi phí vận hành ước tính theo lượng truy vấn thực tế.
  • Training 60–90 phút cho nhóm người dùng đầu tiên.
  • Báo cáo cuối pilot: use case nên mở rộng, use case chưa nên dùng, rủi ro dữ liệu, hành động tiếp theo.

Chỉ số nghiệm thu

Đây là phần tách gói dịch vụ chuyên nghiệp khỏi một bản demo. Chốt bốn chỉ số với khách trước khi bắt đầu, đo trên đúng bộ 30 câu hỏi đã thống nhất:

  • Độ chính xác trả lời: tỷ lệ câu trả lời được người phụ trách chấm đúng. Ngưỡng cam kết hợp lý cho pilot đầu: 80% trở lên trên tập câu hỏi đã chốt.
  • Độ đúng của trích dẫn: tỷ lệ câu trả lời dẫn đúng nguồn. Chỉ số này quan trọng hơn độ trôi chảy — một câu đúng nhưng dẫn sai nguồn vẫn là lỗi.
  • Tỷ lệ từ chối đúng lúc: khi không đủ dữ liệu, hệ thống phải nói không biết. Bot trả lời liều là rủi ro, không phải tính năng.
  • Thời gian tra cứu trước và sau: đo bằng đồng hồ trên 10 tác vụ thật. Đây là con số khách mang đi thuyết phục cấp trên.

Nguyên tắc trung thực khi bán: không cam kết ROI khi chưa có baseline. Hãy đo thời gian tra cứu thủ công trong tuần đầu, rồi so sánh — con số tự nó thuyết phục.

Chi phí vận hành và cách kiểm soát

Nhiều dịch vụ RAG lãi trên hợp đồng nhưng lỗ khi vận hành, vì chi phí gọi mô hình không được đo từ đầu. Bốn biện pháp đưa thẳng vào scope:

  • Đo lượng token thực tế theo từng truy vấn ngay từ ngày đầu, tách riêng chi phí embedding và chi phí sinh câu trả lời.
  • Bộ nhớ đệm cho câu hỏi lặp lại — trong tra cứu nội bộ, tỷ lệ câu hỏi trùng thường rất cao và đây là khoản tiết kiệm dễ nhất.
  • Đặt trần truy vấn theo gói và cảnh báo khi vượt, thay vì phát hiện lúc nhận hoá đơn.
  • Ưu tiên parse tốt ở lớp 1 — tài liệu sạch giảm số chunk phải nạp vào ngữ cảnh, nên tiết kiệm chi phí đồng thời tăng độ chính xác.

Tham khảo thêm cách tiếp cận trong bài dịch vụ audit và tối ưu chi phí LLM cho doanh nghiệp.

Kế hoạch triển khai 14 ngày

Giai đoạn 1 — Khung và dữ liệu (ngày 1–4). Chốt ICP, loại tài liệu và câu hỏi kinh doanh cần trả lời. Audit dữ liệu mẫu, loại tài liệu rác, bản trùng và file không được phép dùng. Thu 30 câu hỏi thật kèm đáp án chuẩn từ người dùng — làm bước này trước khi chọn công cụ.

Giai đoạn 2 — Dựng pipeline (ngày 5–8). Parse tài liệu bằng MarkItDown hoặc Docling, bổ sung Docstrange cho phần scan. Kiểm tra thủ công 10 tài liệu khó nhất để bắt lỗi bảng và thứ tự đọc. Dựng AnythingLLM hoặc RAGFlow, index bộ tài liệu mẫu, gắn quy tắc trích dẫn.

Giai đoạn 3 — Đo và sửa (ngày 9–12). Chạy toàn bộ 30 câu hỏi, ghi lỗi theo ba nhóm: sai nguồn, thiếu nguồn, bịa nội dung. Sửa chunking, prompt và chính sách nguồn theo đúng nhóm lỗi chiếm tỷ trọng lớn nhất. Thêm fallback “không đủ dữ liệu”. Đo lại và ghi bảng so sánh trước/sau.

Giai đoạn 4 — Bàn giao (ngày 13–14). Demo cho khách trên chính tài liệu của họ, training người dùng đầu tiên, bàn giao bảng QA và báo cáo chi phí, chốt đề xuất phạm vi mở rộng.

Với khách nhỏ và tài liệu sạch, nén lại thành 7 ngày bằng cách bỏ giai đoạn 3 xuống một vòng đo duy nhất. Không nên nén giai đoạn 1 — bỏ bước thu câu hỏi thật là nguyên nhân số một khiến pilot thất bại.

Pricing gợi ý

Gói Phù hợp Giá gợi ý
Document QA Scan 1 bộ tài liệu nhỏ, 30 câu hỏi kiểm thử, báo cáo khả thi 8–15 triệu VND
RAG Pilot 50–300 file, setup pipeline, bảng QA, training 20–50 triệu VND
Private Knowledge Base tài liệu nhạy cảm, self-host/local-first, memory cơ bản 50–120 triệu VND
Monthly Care refresh tài liệu, QA định kỳ, prompt tuning, báo cáo 5–25 triệu VND/tháng

Gợi ý chiến thuật: dùng Document QA Scan làm cửa vào giá thấp. Nó tự trả chi phí, cho bạn nhìn thấy dữ liệu thật trước khi báo giá pilot, và loại sớm những khách có tài liệu quá bẩn — nhóm dễ khiến dự án vỡ tiến độ. Monthly Care mới là nơi tạo doanh thu lặp lại: hãy đưa vào đề xuất ngay từ buổi demo, không để tới lúc bàn giao.

Risk controls

  • Ranh giới dữ liệu: xác định bằng văn bản tài liệu nào vào pilot, tài liệu nào bị loại.
  • Quy tắc trích dẫn: câu trả lời quan trọng buộc phải có nguồn; không có nguồn thì trả lời không đủ dữ liệu.
  • Human review: người dùng đầu tiên review 30–50 câu hỏi trước khi mở rộng phạm vi.
  • Giới hạn phạm vi: không nhận “toàn bộ tài liệu công ty” trong pilot đầu tiên, dù khách đề nghị.
  • Dữ liệu cá nhân: lọc thông tin nhạy cảm ở lớp đầu vào và đầu ra; dùng dữ liệu giả lập cho mọi demo bán hàng.
  • Quyền sử dụng tài liệu: xác nhận khách có quyền đưa tài liệu bên thứ ba vào hệ thống — điểm hay bị bỏ qua với hợp đồng có điều khoản bảo mật.

Demo flow

Mở một thư mục tài liệu mẫu — hợp đồng, SOP hoặc proposal. Cho thấy tài liệu đã được parse và chia nguồn, đặc biệt là một trang có bảng để chứng minh cấu trúc được giữ đúng. Hỏi ba câu đơn giản để chứng minh retrieval, rồi hỏi hai câu khó có chủ đích để cho thấy hệ thống biết từ chối khi thiếu dữ liệu — đây là khoảnh khắc tạo niềm tin mạnh nhất, mạnh hơn mọi câu trả lời đúng. Mở bảng QA để khách thấy cách tự kiểm chứng. Kết thúc bằng đề xuất pilot với 30 câu hỏi thật của chính họ.

Lộ trình mở rộng sau pilot

Pilot thành công mở ra bốn hướng tăng doanh thu, xếp theo độ dễ:

  • Mở rộng theo chiều rộng tài liệu — thêm domain thứ hai, thứ ba trong cùng khách hàng. Dễ nhất vì niềm tin đã có và pipeline đã chạy.
  • Tự động hoá vòng cập nhật — dùng n8n để tài liệu mới tự vào index, kèm báo cáo định kỳ. Đây là cầu nối tự nhiên sang hợp đồng Monthly Care.
  • Nối vào quy trình nghiệp vụ — biến hệ thống từ “chỗ để hỏi” thành “chỗ để làm việc”: soạn thảo dựa trên tài liệu mẫu, đối chiếu hợp đồng, kiểm tra tuân thủ.
  • Đóng gói theo ngành — sau ba khách cùng ngành, bạn có kho câu hỏi chuẩn và cấu hình parse riêng cho ngành đó. Đây là lúc dịch vụ bắt đầu có lợi thế phòng thủ thật: đối thủ sao chép được công cụ nhưng không sao chép được bộ câu hỏi kiểm thử và kinh nghiệm xử lý tài liệu đặc thù.

Nếu khách cần dữ liệu chạy hoàn toàn nội bộ hoặc cần trợ lý có bộ nhớ cá nhân, hướng nâng cấp là Private AI Assistant Setup.

Câu hỏi thường gặp

Khác gì so với việc tải tài liệu lên một AI cloud có sẵn?

Khác ở ba điểm đo được: nguồn dẫn tới đúng trang thay vì tóm tắt chung; phạm vi dữ liệu được kiểm soát và ghi log; và có bảng QA để khách tự kiểm chứng chất lượng theo thời gian. Với tài liệu ngắn và không nhạy cảm, AI cloud là lựa chọn hợp lý — hãy nói thẳng điều đó, vì nó xây niềm tin và giúp bạn tập trung vào khách thực sự cần giải pháp riêng.

Bao nhiêu tài liệu thì đủ để bắt đầu?

50–300 file trong một domain hẹp là điểm ngọt. Ít hơn thì khách chưa thấy giá trị; nhiều hơn trong pilot đầu thì thời gian dồn vào xử lý dữ liệu và không kịp chứng minh kết quả.

Nếu tài liệu của khách toàn bản scan chất lượng kém?

Bán Document QA Scan trước và báo cáo trung thực rằng chất lượng nguồn là rào cản. Một số trường hợp lời khuyên đúng là số hoá lại tài liệu trước khi làm RAG. Nhận một dự án mà dữ liệu đầu vào không cứu được là cách nhanh nhất để mất uy tín.

Có cần GPU hay hạ tầng riêng không?

Cho pilot thì không. Một VPS cấu hình vừa đủ chạy được lớp ingest và index cho vài trăm tài liệu. Nhu cầu hạ tầng riêng chỉ xuất hiện khi khách yêu cầu mô hình chạy hoàn toàn nội bộ vì lý do bảo mật — và đó là cuộc trò chuyện về gói Private Knowledge Base, không phải pilot.

Làm sao chứng minh giá trị khi khách chưa từng đo gì?

Đo thủ công trong tuần đầu: chọn 10 tác vụ tra cứu thật, bấm giờ. Con số đó thành baseline. Không có baseline thì mọi cam kết cải thiện đều là lời nói suông, và khách sẽ tự tìm lý do để không gia hạn hợp đồng.

Qualified Opportunity Actions

  • Chọn một domain tài liệu hẹp và một người chịu trách nhiệm review — không có người này thì không nhận dự án.
  • Thu đủ 30 câu hỏi thật kèm đáp án chuẩn trước khi chọn công cụ.
  • Chốt bốn chỉ số nghiệm thu bằng văn bản trong đề xuất, kèm ngưỡng cam kết.
  • Nếu tài liệu chưa đủ sạch, bán Document QA Scan trước khi bán RAG Pilot.
  • Đọc thêm cách dựng RAG chatbot tài liệu nội bộ chi phí thấp cho SME để nắm bức tranh chi phí trước khi báo giá.
  • Chuyển sang Private AI Assistant Setup khi khách yêu cầu dữ liệu chạy nội bộ hoặc cần memory cá nhân.

— Ban biên tập AIToEarn