Field Extractor 2B là mô hình AI 2 tỷ tham số do Dharma-AI công bố trên Hugging Face ngày 4/11/2026, chuyên trích xuất các trường dữ liệu cụ thể từ ảnh tài liệu và trả về JSON có cấu trúc, thay vì trả toàn bộ văn bản như OCR truyền thống. Nói cách khác, thay vì nhận về một “đống chữ” rồi tự viết code để bóc tách từng trường, người dùng nhận thẳng dữ liệu đã có cấu trúc, sẵn sàng đưa vào hệ thống nghiệp vụ. Đây là bước chuyển quan trọng từ “đọc được chữ” sang “hiểu được tài liệu” trong xử lý tài liệu thông minh (IDP — Intelligent Document Processing).
Bài viết này giải thích Field Extractor 2B hoạt động như thế nào, vì sao nó đạt điểm benchmark do hãng công bố là 0,834 — cao hơn cả các mô hình frontier như Claude Opus 5 (0,816) hay GPT-5.6 Luna (0,741) trong bài kiểm tra của hãng — khi nào doanh nghiệp nên dùng mô hình nhỏ chuyên biệt thay vì LLM lớn, và cách xây dựng pipeline trích xuất tài liệu thực tế cho doanh nghiệp Việt Nam. Lưu ý quan trọng: mọi số liệu hiệu năng trong bài đều do Dharma-AI tự công bố và chưa có kiểm chứng độc lập.
Field Extractor 2B là gì?
Field Extractor 2B là mô hình trí tuệ nhân tạo có 2 tỷ tham số, được Dharma-AI phát triển để trích xuất trường dữ liệu (field extraction) từ tài liệu. Khác với OCR truyền thống chỉ nhận diện và trả về toàn bộ văn bản trong ảnh, Field Extractor nhận đầu vào là ảnh tài liệu kèm theo một yêu cầu — ví dụ “lấy tất cả các trường” hoặc “lấy theo schema cho trước” — rồi trả về kết quả dưới dạng JSON có cấu trúc, trong đó mỗi trường dữ liệu đã được đặt đúng tên và đúng vị trí.
Ví dụ thực tế: đưa vào một hóa đơn VAT, thay vì nhận về hàng trăm dòng chữ thô rồi phải viết code để tìm “số hóa đơn ở đâu, tổng tiền nằm dòng nào, mã số thuế của bên bán là gì”, người dùng nhận thẳng một JSON dạng như {"so_hoa_don": "...", "ngay_phat_hanh": "...", "tong_tien": ..., "ma_so_thue_ben_ban": "..."}. Dữ liệu này có thể đưa trực tiếp vào phần mềm kế toán, hệ thống ERP hay cơ sở dữ liệu mà không cần thêm bước xử lý trung gian.
Mô hình được xây dựng trên nền tảng DharmaOCR-LITE v1.1 — một mô hình OCR cũng có 2 tỷ tham số, ra mắt tháng 4/2026, đã trải qua supervised fine-tuning (SFT) và tối ưu bằng DPO (Direct Preference Optimization). Trên nền tảng đó, Dharma-AI huấn luyện thêm một LoRA adapter — kỹ thuật tinh chỉnh hiệu quả chỉ cập nhật một phần nhỏ tham số — trên 43.384 ví dụ trích xuất trường, để biến một mô hình OCR thành một mô hình trích xuất trường chuyên biệt.
Dữ liệu huấn luyện của Field Extractor 2B
Theo Dharma-AI, tập huấn luyện 43.384 ví dụ bao gồm ba nhóm nguồn chính: tài liệu tiếng Anh thu thập từ web công khai, tài liệu thật bằng tiếng Bồ Đào Nha của Brazil, và một phần tài liệu đa ngữ ở châu Âu và châu Á. Sự đa dạng này giúp mô hình bao phủ nhiều loại tài liệu thực tế: hóa đơn, biên lai, biểu mẫu, sao kê ngân hàng và giấy tờ tùy thân. Đây là những loại tài liệu chiếm phần lớn khối lượng xử lý thủ công trong doanh nghiệp, từ phòng kế toán đến bộ phận nhân sự và vận hành.
Điểm đáng chú ý là tập huấn luyện có tài liệu thật (không chỉ tài liệu tổng hợp) và có cả tài liệu đa ngữ. Trong thực tế, tài liệu thật luôn “bẩn” hơn tài liệu mẫu: chữ in mờ, dấu đóng lệch, bảng kẻ không đều, chữ viết tay chen vào, ảnh chụp nghiêng hoặc thiếu sáng. Một mô hình chỉ huấn luyện trên tài liệu sạch thường sụt hiệu năng mạnh khi gặp tài liệu thật. Việc đưa tài liệu thật tiếng Bồ Đào Nha của Brazil và tài liệu đa ngữ vào huấn luyện cho thấy hãng ý thức được vấn đề này, dù người dùng vẫn cần tự kiểm chứng trên chính loại tài liệu của mình trước khi triển khai diện rộng.
Vì sao OCR thuần chưa đủ cho doanh nghiệp?
OCR (Optical Character Recognition) là công nghệ nhận diện ký tự trong ảnh và chuyển thành văn bản. OCR đã rất tốt ở việc “đọc chữ”, nhưng doanh nghiệp không cần chữ — doanh nghiệp cần dữ liệu có cấu trúc. Khoảng cách giữa hai thứ đó chính là chi phí ẩn mà nhiều dự án số hóa tài liệu thường đánh giá thấp.
Hãy hình dung quy trình xử lý 1.000 hóa đơn đầu vào mỗi tháng bằng OCR truyền thống. OCR trả về văn bản thô của từng hóa đơn. Sau đó, đội kỹ thuật phải viết và duy trì các quy tắc trích xuất: dùng biểu thức chính quy (regex) để tìm số hóa đơn, dùng vị trí tọa độ để đoán tổng tiền nằm ở góc dưới bên phải, dùng từ khóa để xác định mã số thuế. Mỗi nhà cung cấp có một mẫu hóa đơn khác nhau, mỗi lần nhà cung cấp đổi mẫu, quy tắc lại vỡ. Càng nhiều mẫu tài liệu, chi phí bảo trì quy tắc càng phình to, và độ chính xác càng khó kiểm soát. Đây chính là lý do nhiều doanh nghiệp “số hóa” xong vẫn phải thuê nhân sự ngồi kiểm tra và sửa tay từng chứng từ.
Một hạn chế khác của OCR thuần là nó không hiểu ngữ nghĩa. OCR không phân biệt được đâu là “ngày phát hành” và đâu là “ngày đến hạn thanh toán” khi cả hai đều là ngày tháng trên cùng một hóa đơn. Nó cũng không biết trường nào quan trọng, trường nào có thể bỏ qua, và không thể trả lời những yêu cầu dạng “chỉ lấy các trường tôi cần theo đúng tên tôi đặt”. Tất cả những việc đó đều phải do con người hoặc code viết thêm đảm nhiệm.
Field Extractor 2B ra đời để lấp đúng khoảng trống này: mô hình vừa “đọc” được tài liệu bằng thị giác, vừa “hiểu” yêu cầu trích xuất, rồi trả thẳng kết quả có cấu trúc. Thay vì pipeline ba tầng “OCR rồi regex rồi map trường”, doanh nghiệp có thể rút gọn thành “ảnh tài liệu vào, JSON ra”. Sự rút gọn này không chỉ tiết kiệm code mà còn giảm điểm lỗi: mỗi tầng trung gian là một nơi có thể sai, và sai ở tầng OCR sẽ lan sang cả tầng regex phía sau.
Field Extractor 2B hoạt động như thế nào?
Về bản chất, Field Extractor 2B là một mô hình thị giác — ngôn ngữ (vision-language model) cỡ nhỏ, chuyên biệt cho tài liệu. Đầu vào của mô hình gồm hai phần: ảnh tài liệu và một yêu cầu trích xuất. Yêu cầu này có thể ở hai dạng: lấy tất cả các trường mà mô hình nhận diện được trong tài liệu, hoặc lấy đúng các trường theo một schema cho trước — tức một danh sách tên trường và định dạng mong muốn do người dùng định nghĩa.
Quy trình xử lý bên trong có thể hình dung qua ba bước. Bước một, mô hình “nhìn” tài liệu: bộ mã hóa thị giác đọc bố cục trang, vị trí các khối văn bản, bảng biểu, con dấu và chữ ký, đồng thời nhận diện nội dung chữ. Bước hai, mô hình đối chiếu nội dung đã đọc với yêu cầu trích xuất: trường nào trong tài liệu tương ứng với trường nào trong schema, giá trị nào thuộc về trường nào. Bước ba, mô hình sinh ra đầu ra JSON, trong đó mỗi trường đã có tên, giá trị và đúng kiểu dữ liệu cần thiết.
Điểm khác biệt lớn so với cách làm truyền thống nằm ở bước hai. Trong pipeline OCR cộng regex, việc “trường nào ứng với giá trị nào” do quy tắc cứng quyết định: ví dụ “số tiền nằm sau chữ TỔNG CỘNG”. Trong Field Extractor, việc đối chiếu này do mô hình học được từ dữ liệu huấn luyện, nên nó linh hoạt hơn với các mẫu tài liệu chưa từng gặp: dù tổng tiền nằm ở vị trí khác nhau trên các mẫu hóa đơn khác nhau, mô hình vẫn có thể nhận ra nhờ ngữ cảnh xung quanh — nhãn trường, bố cục bảng, quan hệ vị trí với các trường khác.
Ba chế độ trích xuất theo schema
Theo công bố của Dharma-AI, mô hình hỗ trợ ba kịch bản sử dụng, cũng chính là ba kịch bản trong bộ benchmark của hãng. Kịch bản thứ nhất là trích xuất không có schema: người dùng không chỉ định trước trường nào, mô hình tự phát hiện và trả về tất cả các trường mà nó nhận diện được trong tài liệu. Chế độ này phù hợp khi khám phá một loại tài liệu mới hoặc khi doanh nghiệp chưa biết trước tài liệu chứa những trường gì.
Kịch bản thứ hai là trích xuất theo schema một phần: người dùng đưa ra một số trường cần lấy, mô hình chỉ trả về đúng những trường đó. Đây là chế độ phổ biến nhất trong thực tế, vì hệ thống nghiệp vụ thường chỉ cần một tập trường cố định — ví dụ phần mềm kế toán chỉ cần số hóa đơn, ngày phát hành, mã số thuế bên bán và tổng tiền, không cần mọi thông tin khác trên hóa đơn.
Kịch bản thứ ba là khó nhất và cũng thực tế nhất: schema có chứa cả trường không tồn tại trong tài liệu. Ví dụ người dùng yêu cầu lấy “số tài khoản ngân hàng” từ một hóa đơn mà trên đó không hề có số tài khoản. Một mô hình tốt phải trả lời rằng trường đó không tồn tại — hoặc bỏ trống — chứ không được bịa ra một dãy số trông có vẻ hợp lý. Đây là bài kiểm tra khả năng chống “ảo giác” (hallucination) của mô hình, và là điểm mà nhiều mô hình trích xuất yếu nhất. Việc Dharma-AI đưa kịch bản này vào benchmark cho thấy hãng coi chống bịa là một yêu cầu chất lượng cốt lõi, không phải tính năng phụ.
Nền tảng DharmaOCR-LITE v1.1 và huấn luyện LoRA
Field Extractor 2B không được huấn luyện từ đầu mà được xây dựng trên DharmaOCR-LITE v1.1, mô hình OCR 2 tỷ tham số mà Dharma-AI ra mắt tháng 4/2026. DharmaOCR-LITE v1.1 đã trải qua supervised fine-tuning và DPO. Supervised fine-tuning là quá trình dạy mô hình bằng các cặp ví dụ đầu vào — đầu ra đúng, giúp mô hình học được đúng định dạng và hành vi mong muốn. DPO (Direct Preference Optimization) là kỹ thuật tối ưu tiếp theo, dạy mô hình ưu tiên câu trả lời tốt hơn trong các cặp so sánh, giúp giảm lỗi và cải thiện độ tin cậy của đầu ra.
Trên nền tảng đó, Dharma-AI huấn luyện thêm một LoRA adapter trên 43.384 ví dụ trích xuất trường. LoRA (Low-Rank Adaptation) là kỹ thuật tinh chỉnh chỉ cập nhật một lượng nhỏ tham số bổ sung thay vì toàn bộ mô hình. Cách làm này có hai lợi ích. Thứ nhất, chi phí huấn luyện thấp hơn nhiều so với huấn luyện lại toàn bộ mô hình. Thứ hai, adapter có thể gắn vào hoặc tháo ra khỏi mô hình gốc, giúp việc triển khai linh hoạt: cùng một mô hình nền có thể phục vụ nhiều tác vụ khác nhau bằng cách thay adapter.
Cách tiếp cận “mô hình nền OCR tốt cộng adapter chuyên biệt” cũng phản ánh một xu hướng lớn hơn trong AI hiện nay: thay vì dùng một mô hình khổng lồ làm mọi việc, người ta dùng mô hình nhỏ nhưng được tinh chỉnh sâu cho một tác vụ cụ thể. Mô hình nhỏ có ưu thế về chi phí, tốc độ và khả năng triển khai trên hạ tầng riêng — và trong nhiều tác vụ hẹp, nó có thể đạt độ chính xác ngang hoặc cao hơn mô hình lớn đa năng, vì toàn bộ “năng lực” của nó tập trung vào đúng một việc.
Benchmark: điểm 0,834 và ý nghĩa thực sự của nó
Theo công bố của Dharma-AI, Field Extractor 2B được đánh giá trên một bộ benchmark gồm 546 tài liệu với tổng cộng 1.638 trường hợp trích xuất, bao phủ cả ba kịch bản đã nêu: không schema, schema một phần và schema có trường không tồn tại. Kết quả do hãng công bố: Field Extractor 2B đạt điểm 0,834, cao hơn các mô hình frontier được đưa vào so sánh, với Claude Opus 5 đạt 0,816 và GPT-5.6 Luna đạt 0,741. Ngoài ra, hãng cho biết đã kiểm tra thêm mô hình trên hai tập dữ liệu công khai là SROIE và FUNSD — hai bộ dữ liệu chuẩn trong nghiên cứu trích xuất thông tin từ tài liệu, trong đó SROIE tập trung vào biên lai và FUNSD tập trung vào biểu mẫu.
Con số 0,834 cần được đọc đúng bối cảnh. Thứ nhất, đây là số liệu do chính Dharma-AI công bố và chưa có kiểm chứng độc lập — người đọc không nên coi đó là kết luận cuối cùng về thứ hạng mô hình. Thứ hai, benchmark của hãng được thiết kế cho đúng tác vụ trích xuất trường, trong khi các mô hình frontier là mô hình đa năng, không được tối ưu riêng cho tác vụ này. Việc một mô hình chuyên biệt 2 tỷ tham số vượt mô hình đa năng lớn hơn hàng chục lần trong đúng tác vụ hẹp của nó là điều hoàn toàn hợp lý về mặt kỹ thuật — đó chính là lý do tồn tại của các mô hình chuyên biệt — nhưng nó không có nghĩa mô hình nhỏ “mạnh hơn” mô hình lớn nói chung.
Thứ ba, điều thực sự đáng chú ý trong benchmark này không phải thứ hạng tuyệt đối mà là kịch bản thứ ba: schema có trường không tồn tại. Đây là nơi phân biệt mô hình trích xuất tốt với mô hình hay bịa. Trong vận hành doanh nghiệp, một trường bị bịa ra — ví dụ một số tài khoản ngân hàng không có thật, một mã số thuế sai — có thể gây hậu quả nghiêm trọng hơn nhiều so với một trường bị bỏ trống. Một trường bị bỏ trống thì hệ thống sẽ báo thiếu và con người kiểm tra lại; một trường bị bịa thì hệ thống cứ thế chạy tiếp với dữ liệu sai. Vì vậy, khi tự đánh giá bất kỳ mô hình trích xuất nào, doanh nghiệp nên đặc biệt kiểm tra hành vi của mô hình với trường không tồn tại, thay vì chỉ nhìn điểm tổng.
Chi phí thấp hơn 6–147 lần: đọc sao cho đúng
Dharma-AI cho biết chi phí sử dụng Field Extractor 2B thấp hơn khoảng 6 đến 147 lần tùy mô hình so sánh, và trích dẫn giá thuê GPU L40S là 2,24 USD mỗi giờ. Khoảng dao động rất rộng này là điều bình thường: chi phí so sánh phụ thuộc vào việc đối chiếu với mô hình nào, qua API của nhà cung cấp hay tự vận hành, và với khối lượng xử lý ra sao. Một mô hình 2 tỷ tham số chạy trên một GPU thuê theo giờ có chi phí suy luận trên mỗi tài liệu thấp hơn nhiều so với gọi API của mô hình frontier — vốn tính phí theo token đầu vào và đầu ra, mà đầu vào ở đây còn là ảnh tài liệu có độ phân giải cao, tức rất nhiều token hình ảnh.
Tuy nhiên, doanh nghiệp cần tính tổng chi phí sở hữu, không chỉ chi phí suy luận trên mỗi tài liệu. Tự vận hành mô hình nhỏ còn có chi phí hạ tầng, chi phí tích hợp, chi phí kiểm chứng chất lượng và chi phí vận hành dài hạn. Ngược lại, gọi API mô hình lớn thì không tốn chi phí hạ tầng nhưng chi phí biến đổi theo khối lượng và dữ liệu phải rời khỏi hệ thống của doanh nghiệp. Bài toán lựa chọn vì vậy không có đáp án chung cho mọi doanh nghiệp — nó phụ thuộc vào khối lượng tài liệu, mức độ nhạy cảm của dữ liệu và năng lực kỹ thuật nội bộ. Phần sau của bài sẽ có checklist giúp doanh nghiệp tự đánh giá.
So sánh: OCR truyền thống, Field Extractor 2B và LLM đa phương thức lớn
Ba cách tiếp cận dưới đây không loại trừ nhau — nhiều hệ thống thực tế kết hợp cả ba — nhưng việc hiểu rõ điểm mạnh, điểm yếu của từng cách giúp doanh nghiệp chọn đúng công cụ cho từng khâu.
| Tiêu chí | OCR truyền thống | Field Extractor 2B | LLM đa phương thức lớn |
|---|---|---|---|
| Đầu ra | Văn bản thô toàn trang | JSON có cấu trúc theo trường | Văn bản hoặc JSON theo yêu cầu |
| Hiểu ngữ nghĩa tài liệu | Không, chỉ đọc chữ | Có, trong phạm vi trích xuất trường | Có, rất mạnh và linh hoạt |
| Cần viết quy tắc trích xuất | Có, regex và quy tắc vị trí | Không, dùng schema khai báo | Không, dùng prompt |
| Xử lý mẫu tài liệu mới | Kém, phải viết quy tắc mới | Tốt nếu cùng loại tài liệu đã huấn luyện | Rất tốt, ít cần chuẩn bị trước |
| Xử lý trường không tồn tại | Không áp dụng | Được thiết kế và kiểm tra riêng | Phụ thuộc prompt, vẫn có nguy cơ bịa |
| Chi phí suy luận | Rất thấp | Thấp, theo hãng thấp hơn 6–147 lần so với mô hình frontier | Cao, tính theo token ảnh và token văn bản |
| Độ trễ | Rất thấp | Thấp, mô hình chỉ 2 tỷ tham số | Cao hơn, nhất là với ảnh độ phân giải cao |
| Triển khai on-prem | Dễ dàng | Khả thi với mô hình nhỏ | Khó, thường phải dùng API đám mây |
| Dữ liệu nhạy cảm | Ở lại trong hệ thống | Có thể ở lại trong hệ thống | Thường phải gửi ra ngoài qua API |
| Linh hoạt ngoài trích xuất | Thấp | Thấp, chuyên một tác vụ | Rất cao: tóm tắt, phân loại, đối chiếu, trả lời câu hỏi |
Bảng so sánh cho thấy một nguyên tắc quan trọng: không có công nghệ nào thắng ở mọi tiêu chí. OCR truyền thống vẫn là lựa chọn hợp lý khi doanh nghiệp chỉ cần số hóa văn bản để lưu trữ và tìm kiếm, không cần trích xuất trường. LLM lớn vẫn là lựa chọn tốt nhất khi tài liệu rất đa dạng, yêu cầu thay đổi liên tục, hoặc cần cả suy luận phức tạp như đối chiếu hợp đồng và phát hiện điều khoản bất thường. Field Extractor 2B chiếm vị trí ở giữa: khi khối lượng tài liệu lớn, mẫu tài liệu tương đối ổn định, yêu cầu trích xuất cố định và chi phí là yếu tố quyết định.
Khi nào nên dùng mô hình nhỏ chuyên biệt thay vì LLM frontier?
Câu hỏi này không có đáp án duy nhất, nhưng có bốn tín hiệu cho thấy mô hình nhỏ chuyên biệt là lựa chọn hợp lý. Tín hiệu thứ nhất là khối lượng lớn và lặp lại. Khi doanh nghiệp xử lý hàng nghìn tài liệu mỗi tháng với cùng một tập trường cần trích xuất, chi phí trên mỗi tài liệu của mô hình lớn sẽ tích lũy thành một khoản đáng kể, trong khi mô hình nhỏ chạy trên hạ tầng riêng có chi phí biên thấp hơn nhiều. Đây chính là trường hợp mà mức chênh lệch chi phí 6–147 lần do Dharma-AI công bố trở nên có ý nghĩa thực tế.
Tín hiệu thứ hai là độ trễ và thông lượng. Mô hình 2 tỷ tham số suy luận nhanh hơn nhiều so với mô hình frontier, nên phù hợp với các quy trình cần xử lý gần thời gian thực — ví dụ quầy lễ tân quét giấy tờ tùy thân của khách và cần kết quả ngay, hoặc hệ thống tiếp nhận hồ sơ cần phản hồi tức thì cho người nộp. Tín hiệu thứ ba là dữ liệu nhạy cảm. Hóa đơn, sao kê ngân hàng, giấy tờ tùy thân đều là dữ liệu nhạy cảm; nhiều doanh nghiệp — đặc biệt trong tài chính, bảo hiểm và y tế — có chính sách không đưa dữ liệu này ra khỏi hạ tầng của mình. Mô hình nhỏ có thể chạy on-prem, tức dữ liệu không rời khỏi hệ thống nội bộ.
Tín hiệu thứ tư là tính ổn định của yêu cầu. Nếu schema trích xuất ít thay đổi theo thời gian và loại tài liệu đã biết trước, mô hình chuyên biệt sẽ phát huy tối đa lợi thế. Ngược lại, nếu mỗi tuần doanh nghiệp lại nhận một loại tài liệu mới với yêu cầu trích xuất khác nhau, chi phí chuẩn bị và kiểm chứng mô hình chuyên biệt có thể cao hơn lợi ích nó mang lại — khi đó LLM lớn với khả năng làm việc zero-shot qua prompt sẽ linh hoạt hơn.
Một mô hình triển khai thực tế mà nhiều doanh nghiệp đang áp dụng là kết hợp cả hai: dùng mô hình nhỏ chuyên biệt xử lý phần lớn tài liệu quen thuộc với chi phí thấp, và chuyển các trường hợp khó — tài liệu lạ, độ tin cậy thấp, trường hợp biên — sang LLM lớn hoặc sang con người kiểm tra. Cách làm này vừa tối ưu chi phí, vừa giữ được độ chính xác ở những ca khó nhất.
Hướng dẫn triển khai pipeline trích xuất tài liệu cho doanh nghiệp Việt
Với doanh nghiệp Việt Nam, ba nhóm tài liệu phổ biến nhất cần trích xuất là hóa đơn và chứng từ kế toán, hợp đồng và hồ sơ pháp lý, cùng giấy tờ tùy thân như căn cước công dân (CCCD) trong quy trình định danh khách hàng. Dưới đây là pipeline tham khảo gồm sáu bước, áp dụng được cho cả ba nhóm tài liệu này.
Bước 1: Chuẩn hóa đầu vào
Chất lượng ảnh quyết định phần lớn độ chính xác của mọi mô hình trích xuất. Doanh nghiệp nên quy định rõ cách chụp hoặc quét tài liệu: đủ sáng, tài liệu nằm gọn trong khung hình, không bị che khuất, độ phân giải đủ cao để đọc được chữ nhỏ nhất trên tài liệu. Với tài liệu giấy, quét ở độ phân giải 300 DPI là mức chuẩn phổ biến; với ảnh chụp bằng điện thoại, cần hướng dẫn người dùng chụp thẳng, tránh bóng và tránh chụp nghiêng quá nhiều. Một bước tiền xử lý đơn giản — xoay ảnh về đúng chiều, tăng độ tương phản, cắt lề thừa — có thể cải thiện đáng kể độ chính xác mà không tốn thêm chi phí mô hình.
Bước 2: Định nghĩa schema trích xuất
Trước khi chạy mô hình, doanh nghiệp cần liệt kê chính xác những trường nào cần lấy cho từng loại tài liệu, kèm theo tên trường, kiểu dữ liệu và trường nào bắt buộc, trường nào tùy chọn. Ví dụ với hóa đơn VAT: số hóa đơn, ký hiệu, ngày phát hành, tên bên bán, mã số thuế bên bán, tên bên mua, mã số thuế bên mua, tổng tiền chưa thuế, tiền thuế, tổng tiền thanh toán. Việc định nghĩa schema rõ ràng ngay từ đầu giúp tránh tình trạng mỗi bộ phận lấy một kiểu, và là cơ sở để kiểm tra chất lượng ở bước sau.
Bước 3: Chạy trích xuất và ghi lại độ tin cậy
Đưa ảnh tài liệu và schema vào Field Extractor 2B để nhận JSON đầu ra. Nếu mô hình cung cấp điểm tin cậy cho từng trường, hãy lưu lại cùng kết quả. Điểm tin cậy là tín hiệu quan trọng để quyết định trường nào có thể tự động đưa vào hệ thống, trường nào cần con người kiểm tra. Một sai lầm phổ biến là chỉ lưu kết quả mà không lưu độ tin cậy, khiến về sau không thể truy vết vì sao một dữ liệu sai lại lọt vào hệ thống.
Bước 4: Kiểm tra tính hợp lệ bằng quy tắc nghiệp vụ
JSON từ mô hình không nên đi thẳng vào hệ thống nghiệp vụ mà cần qua một lớp kiểm tra quy tắc. Các quy tắc này đơn giản nhưng hiệu quả: tổng tiền phải bằng tổng tiền chưa thuế cộng tiền thuế; mã số thuế phải đúng định dạng 10 hoặc 13 chữ số; ngày phát hành không được nằm trong tương lai; số CCCD phải đủ 12 chữ số. Lớp kiểm tra này bắt được nhiều lỗi mà mô hình có thể mắc phải, đặc biệt là lỗi nhận diện số — vì một chữ số sai trong tổng tiền hay mã số thuế có hậu quả lớn hơn nhiều so với một chữ cái sai trong tên người.
Bước 5: Luồng kiểm tra con người theo ngưỡng
Không có mô hình trích xuất nào đạt độ chính xác tuyệt đối, nên doanh nghiệp cần thiết kế luồng “human-in-the-loop”: kết quả có độ tin cậy cao và vượt qua mọi quy tắc kiểm tra sẽ đi thẳng vào hệ thống; kết quả có độ tin cậy thấp hoặc vi phạm quy tắc sẽ chuyển sang nhân sự kiểm tra. Ngưỡng này nên được điều chỉnh theo mức độ rủi ro: với chứng từ kế toán liên quan đến tiền, ngưỡng nên chặt hơn; với tài liệu lưu trữ nội bộ, ngưỡng có thể thoáng hơn. Quan trọng là mọi trường hợp con người sửa lại đều được ghi log, vì đó chính là dữ liệu để cải thiện hệ thống về sau.
Bước 6: Đo lường và cải thiện liên tục
Doanh nghiệp nên đo ba chỉ số chính: độ chính xác theo trường (tỷ lệ trường trích xuất đúng trên tổng số trường), tỷ lệ tài liệu xử lý hoàn toàn tự động không cần can thiệp, và thời gian xử lý trung bình mỗi tài liệu. Ba chỉ số này cho biết hệ thống có đang tạo ra giá trị thật hay không. Nếu tỷ lệ tự động thấp, cần xem lại chất lượng ảnh đầu vào hoặc schema; nếu một trường cụ thể hay sai, cần bổ sung ví dụ huấn luyện hoặc siết quy tắc kiểm tra cho trường đó.
Checklist đánh giá độ chính xác và chống bịa
Trước khi đưa bất kỳ mô hình trích xuất nào vào vận hành chính thức, doanh nghiệp nên chạy một đợt đánh giá trên chính tài liệu của mình. Checklist dưới đây tổng hợp các điểm cần kiểm tra, trong đó nhiều điểm xuất phát trực tiếp từ thiết kế benchmark của Dharma-AI.
- Tập kiểm tra đại diện: lấy ít nhất vài trăm tài liệu thật của doanh nghiệp, bao phủ đủ các nhà cung cấp, mẫu tài liệu và tình trạng chất lượng ảnh khác nhau — không chỉ dùng tài liệu mẫu đẹp.
- Đo theo từng trường, không chỉ đo chung: một mô hình có thể đúng 95% số trường nhưng sai đúng trường quan trọng nhất là tổng tiền. Hãy đo độ chính xác riêng cho từng trường trong schema.
- Kiểm tra trường không tồn tại: cố tình đưa vào schema những trường không có trên tài liệu và xem mô hình có bịa ra giá trị hay không. Đây là bài kiểm tra chống ảo giác quan trọng nhất.
- Kiểm tra trường số: đo riêng độ chính xác của các trường số như tiền, mã số thuế, số tài khoản, vì sai một chữ số là sai hoàn toàn giá trị.
- Kiểm tra tài liệu xấu: đưa vào ảnh mờ, ảnh nghiêng, ảnh thiếu sáng và tài liệu có chữ viết tay để biết giới hạn thực tế của mô hình.
- Kiểm tra tính nhất quán: cùng một tài liệu chạy nhiều lần có cho cùng một kết quả không; kết quả có ổn định khi ảnh được quét lại ở chất lượng khác nhau không.
- Kiểm tra định dạng đầu ra: JSON trả về có đúng schema đã khai báo không, có trường thừa hay thiếu không, kiểu dữ liệu có đúng không.
- Đo chi phí thật: đo chi phí và thời gian xử lý trên mỗi tài liệu trong môi trường triển khai thực tế của doanh nghiệp, không chỉ dựa vào con số hãng công bố.
Hạn chế và những điều chưa rõ về Field Extractor 2B
Một bài viết trung thực về mô hình mới cần nói rõ cả những điều chưa biết. Thứ nhất, mọi số liệu hiệu năng — điểm benchmark 0,834, mức chênh lệch chi phí 6–147 lần — đều do Dharma-AI tự công bố và chưa có kiểm chứng độc lập. Cho đến khi có bên thứ ba tái hiện được kết quả trên cùng bộ dữ liệu, các con số này nên được coi là tuyên bố của hãng, không phải kết luận đã được xác thực.
Thứ hai, hiện chưa rõ điều khoản cấp phép, trọng số mô hình hay gói thương mại của Field Extractor 2B. Doanh nghiệp quan tâm cần tìm hiểu rõ mô hình được phân phối theo giấy phép nào, có được dùng cho mục đích thương mại hay không, trọng số có được công khai để tự vận hành hay chỉ dùng qua dịch vụ của hãng, và chi phí sử dụng thực tế là bao nhiêu. Đây là những câu hỏi cần có đáp án trước khi đưa mô hình vào bất kỳ hệ thống sản xuất nào.
Thứ ba, tập huấn luyện của mô hình không đề cập rõ tài liệu tiếng Việt. Tài liệu huấn luyện gồm tiếng Anh, tiếng Bồ Đào Nha của Brazil và một phần đa ngữ châu Âu, châu Á — nhưng không có thông tin xác nhận tiếng Việt nằm trong đó với tỷ trọng bao nhiêu. Doanh nghiệp Việt Nam vì vậy càng cần tự kiểm chứng trên hóa đơn, hợp đồng và CCCD tiếng Việt của mình, vì hiệu năng trên tài liệu tiếng Anh không tự động chuyển sang tài liệu tiếng Việt, nhất là với các tài liệu có dấu tiếng Việt, chữ ký và con dấu đặc thù.
Câu hỏi thường gặp (FAQs)
Field Extractor 2B là gì?
Field Extractor 2B là mô hình AI 2 tỷ tham số do Dharma-AI công bố trên Hugging Face ngày 4/11/2026, chuyên trích xuất các trường dữ liệu cụ thể từ tài liệu và trả về JSON có cấu trúc. Khác với OCR truyền thống chỉ trả toàn bộ văn bản, Field Extractor trả thẳng dữ liệu đã có cấu trúc theo trường mà người dùng yêu cầu, sẵn sàng đưa vào hệ thống nghiệp vụ. Mô hình được xây dựng trên nền tảng OCR DharmaOCR-LITE v1.1 và tinh chỉnh bằng LoRA adapter trên 43.384 ví dụ trích xuất trường.
Field Extractor 2B khác OCR truyền thống như thế nào?
OCR truyền thống chỉ nhận diện chữ trong ảnh và trả về văn bản thô, còn Field Extractor 2B hiểu yêu cầu trích xuất và trả về JSON có cấu trúc với từng trường đã đặt đúng tên và đúng giá trị. Nhờ đó doanh nghiệp không cần viết thêm regex hay quy tắc map trường sau bước OCR. Nói ngắn gọn: OCR trả lời “tài liệu viết gì”, còn Field Extractor trả lời “từng trường dữ liệu trong tài liệu là gì”. Hai công nghệ này bổ sung cho nhau chứ không thay thế hoàn toàn: OCR vẫn đủ dùng khi doanh nghiệp chỉ cần số hóa văn bản để lưu trữ và tìm kiếm.
Field Extractor 2B có chính xác hơn các mô hình AI lớn không?
Theo số liệu do Dharma-AI tự công bố, Field Extractor 2B đạt điểm 0,834 trên bộ benchmark trích xuất trường của hãng, cao hơn Claude Opus 5 (0,816) và GPT-5.6 Luna (0,741) trong cùng bài kiểm tra. Tuy nhiên các số liệu này chưa có kiểm chứng độc lập, và benchmark được thiết kế cho đúng tác vụ trích xuất trường — nơi mô hình chuyên biệt có lợi thế tự nhiên trước mô hình đa năng. Doanh nghiệp nên tự kiểm chứng trên chính tài liệu của mình trước khi kết luận mô hình nào chính xác hơn cho trường hợp cụ thể của mình.
Field Extractor 2B xử lý trường không tồn tại trong tài liệu như thế nào?
Field Extractor 2B được thiết kế để xử lý trường hợp schema yêu cầu một trường mà tài liệu không có, và đây là một trong ba kịch bản trong bộ benchmark của hãng. Mô hình tốt phải báo rằng trường đó không tồn tại hoặc bỏ trống, chứ không được bịa ra một giá trị trông hợp lý. Trong thực tế, doanh nghiệp vẫn nên kiểm tra hành vi này bằng checklist riêng: cố tình đưa trường không tồn tại vào schema và quan sát kết quả, đồng thời luôn có lớp kiểm tra quy tắc nghiệp vụ phía sau để chặn dữ liệu bịa lọt vào hệ thống.
Doanh nghiệp Việt Nam có dùng được Field Extractor 2B cho hóa đơn và CCCD không?
Về nguyên tắc là có, vì mô hình bao phủ hóa đơn, biên lai, biểu mẫu, sao kê ngân hàng và giấy tờ tùy thân — đúng các loại tài liệu doanh nghiệp Việt Nam xử lý nhiều nhất. Tuy nhiên tập huấn luyện được công bố không nêu rõ tỷ trọng tài liệu tiếng Việt, nên hiệu năng trên hóa đơn VAT, hợp đồng và CCCD tiếng Việt cần được kiểm chứng trực tiếp trước khi triển khai diện rộng. Doanh nghiệp nên chạy thử trên vài trăm tài liệu thật của mình, đo độ chính xác theo từng trường và đặc biệt kiểm tra các trường số như tổng tiền và mã số thuế.
Nên chọn Field Extractor 2B hay LLM đa phương thức lớn?
Nên chọn Field Extractor 2B khi khối lượng tài liệu lớn và lặp lại, schema trích xuất ổn định, cần chi phí thấp và độ trễ thấp, hoặc dữ liệu nhạy cảm cần chạy on-prem trong hệ thống nội bộ. Nên chọn LLM đa phương thức lớn khi tài liệu rất đa dạng, yêu cầu thay đổi liên tục, hoặc cần cả suy luận phức tạp như đối chiếu hợp đồng và phát hiện điều khoản bất thường. Nhiều doanh nghiệp chọn cách kết hợp: mô hình nhỏ xử lý phần lớn tài liệu quen thuộc, LLM lớn xử lý các trường hợp khó và tài liệu lạ.
Chi phí sử dụng Field Extractor 2B thấp hơn bao nhiêu so với mô hình lớn?
Dharma-AI công bố chi phí thấp hơn khoảng 6–147 lần tùy mô hình so sánh, và trích dẫn giá thuê GPU L40S là 2,24 USD mỗi giờ. Khoảng dao động rộng này phụ thuộc vào việc đối chiếu với mô hình nào và triển khai theo cách nào. Doanh nghiệp nên tính tổng chi phí sở hữu — gồm hạ tầng, tích hợp, kiểm chứng chất lượng và vận hành — và đo chi phí thực tế trên mỗi tài liệu trong môi trường của mình, thay vì chỉ dựa vào con số hãng công bố.
Triển khai trích xuất tài liệu bằng AI cần lưu ý gì nhất?
Điều quan trọng nhất là đừng đưa kết quả của mô hình thẳng vào hệ thống nghiệp vụ mà không qua kiểm tra. Hãy chuẩn hóa ảnh đầu vào, định nghĩa schema rõ ràng, thêm lớp kiểm tra quy tắc nghiệp vụ như tổng tiền phải khớp và mã số thuế phải đúng định dạng, và thiết kế luồng kiểm tra con người cho các trường hợp độ tin cậy thấp. Đồng thời hãy đo ba chỉ số cốt lõi — độ chính xác theo trường, tỷ lệ tài liệu xử lý hoàn toàn tự động và thời gian xử lý mỗi tài liệu — để biết hệ thống có đang tạo ra giá trị thật hay không.
Field Extractor 2B cho thấy một hướng đi rõ ràng của AI xử lý tài liệu: mô hình nhỏ, chuyên biệt, trả dữ liệu có cấu trúc thay vì văn bản thô, với chi phí đủ thấp để triển khai rộng rãi. Dù các con số hiệu năng vẫn cần kiểm chứng độc lập và điều khoản cấp phép vẫn chưa rõ ràng, bản thân hướng tiếp cận này đã đủ để doanh nghiệp Việt Nam bắt đầu thử nghiệm — đặc biệt với hóa đơn, chứng từ và giấy tờ tùy thân, nơi bài toán trích xuất trường là nhu cầu có thật mỗi ngày. Doanh nghiệp nào xây dựng được pipeline trích xuất tài liệu tốt hôm nay sẽ tiết kiệm được rất nhiều giờ nhập liệu thủ công và giảm đáng kể lỗi dữ liệu trong vận hành.
Nếu doanh nghiệp của bạn đang xử lý nhiều hóa đơn, hợp đồng hay hồ sơ giấy tờ mỗi ngày và muốn tư vấn giải pháp AI trích xuất dữ liệu phù hợp với loại tài liệu và quy mô của mình, hãy liên hệ AIA qua hotline 0939 936 168 để được tư vấn giải pháp AI.
