Các tài liệu đã trải qua hàng thập kỷ kiên quyết bảo vệ nội dung của chúng trước phần mềm. Vào cuối những năm 1960, các kỹ thuật OCR (nhận dạng ký tự quang học) đầu tiên đã biến các tài liệu được quét thành văn bản thô. Bằng cách lập chỉ mục và tìm kiếm văn bản từ các tài liệu số hóa này, phần mềm đã thúc đẩy các dự án nghiên cứu và khám phá pháp lý tốn nhiều công sức trước đây.
Ngày nay, Google, Microsoft và Amazon cung cấp OCR chất lượng cao như một phần của các dịch vụ đám mây của họ. Nhưng các tài liệu vẫn không được sử dụng trong các công cụ phần mềm và dữ liệu có giá trị bị hao mòn trong
Giả định phổ biến là học máy, thường được gọi là “AI”, là cách tốt nhất để đạt được điều này, thay thế các kỹ thuật dựa trên khuôn mẫu đã lỗi thời và dễ vỡ. Giả định này là sai lầm. Cách tốt nhất để biến phần lớn tài liệu thành dữ liệu có cấu trúc là sử dụng thế hệ tiếp theo của các mẫu mạnh mẽ, linh hoạt để tìm dữ liệu trong tài liệu giống như một người.
Lời hứa của học máy là bạn có thể đào tạo một mô hình một lần trên một kho tài liệu đại diện lớn và sau đó tổng quát hóa suôn sẻ thành các bố cục tài liệu không thuộc mẫu mà không cần đào tạo lại. Ví dụ: bạn muốn đào tạo một mô hình ML về chính sách bảo hiểm nhà của công ty A, B và C, sau đó trích xuất dữ liệu tương tự từ các tài liệu tương tự do công ty Z phát hành. Điều này rất khó đạt được trong thực tế vì ba lý do:
Mục tiêu của bạn thường là trích xuất hàng chục hoặc hàng trăm phần tử dữ liệu riêng lẻ từ mỗi tài liệu. Một mô hình ở cấp độ chi tiết của tài liệu sẽ thường xuyên bỏ sót một số giá trị này và những lỗi đó khá khó phát hiện. Khi mô hình của bạn cố gắng trích xuất hàng chục hoặc hàng trăm phần tử dữ liệu đó từ các loại tài liệu không thuộc mẫu, bạn sẽ có cơ hội thất bại trong việc tổng quát hóa.
Trong khi một số tài liệu đơn giản có thể có bản thể luận khóa / giá trị cố định, hầu hết sẽ có cấu trúc con: hãy nghĩ đến danh sách các thiếu sót trong báo cáo kiểm tra nhà hoặc tập hợp các giao dịch trong bảng sao kê ngân hàng. Trong một số trường hợp, bạn thậm chí sẽ gặp phải các cấu trúc con lồng ghép phức tạp: hãy nghĩ đến danh sách các hợp đồng bảo hiểm, mỗi hợp đồng bảo hiểm đều có lịch sử yêu cầu bồi thường. Bạn cần mô hình học máy của mình để suy ra các cấu trúc phân cấp này hoặc bạn cần tham số hóa mô hình theo cách thủ công với các cấu trúc phân cấp này và bản thể luận tổng thể mong muốn trước khi đào tạo.
Tài liệu là bất cứ thứ gì nằm gọn trên một hoặc nhiều tờ giấy và chứa dữ liệu! Tài liệu thực sự chỉ là những túi biểu diễn dữ liệu đa dạng và tùy ý. Bảng, nhãn, văn bản tự do, phần, hình ảnh, đầu trang và chân trang: bạn đặt tên cho nó và một tài liệu có thể sử dụng nó để mã hóa dữ liệu. Không có gì đảm bảo rằng hai tài liệu, thậm chí có cùng ngữ nghĩa, sẽ sử dụng các công cụ biểu diễn giống nhau.
Không có gì ngạc nhiên khi các dự án phân tích cú pháp tài liệu dựa trên ML có thể mất hàng tháng, yêu cầu hàng tấn dữ liệu trước, dẫn đến kết quả không ấn tượng và nói chung là "mệt mỏi" (để trích dẫn trực tiếp một người tham gia vào một dự án như vậy với một nhà cung cấp hàng đầu trong lĩnh vực này ).
Những vấn đề này cho thấy rằng góc độ tấn công thích hợp để cấu trúc tài liệu là ở cấp độ phần tử dữ liệu hơn là cấp độ toàn bộ tài liệu. Nói cách khác, chúng ta cần trích xuất dữ liệu từ bảng, nhãn và văn bản tự do; không phải từ một “tài liệu” tổng thể. Và ở cấp độ phần tử dữ liệu, chúng ta cần các công cụ mạnh mẽ để thể hiện mối quan hệ giữa vũ trụ của các chế độ biểu diễn được tìm thấy trong tài liệu và cấu trúc dữ liệu hữu ích cho phần mềm.
Vì vậy, hãy quay lại với các mẫu.
Về mặt lịch sử, các mẫu đã có một phương tiện nghèo nàn để thể hiện ánh xạ giữa chế độ biểu diễn và cấu trúc dữ liệu. Ví dụ, họ có thể hướng dẫn: chuyển đến trang 3 và trả lại bất kỳ văn bản nào trong các tọa độ hộp này. Điều này bị hỏng ngay lập tức vì bất kỳ lý do nào, bao gồm nếu:
Không có thay đổi nhỏ nào đối với bố cục tài liệu có thể làm khó người đọc.
Đối với phần mềm để cấu trúc thành công các tài liệu phức tạp, bạn muốn có một giải pháp vượt qua cuộc chiến của các dự án ML kéo dài hàng tháng so với các mẫu giòn. Thay vào đó, hãy xây dựng một ngôn ngữ truy vấn dành riêng cho tài liệu (khi thích hợp) nhúng ML ở phần tử dữ liệu, thay vì mức tài liệu.
Trước tiên, bạn muốn các nguyên bản (tức là các hướng dẫn) bằng ngôn ngữ mô tả các chế độ biểu diễn (như một cặp nhãn / giá trị hoặc các tiểu mục lặp lại) và luôn linh hoạt với các biến thể bố cục điển hình. Ví dụ, nếu bạn nói:
“Tìm một hàng bắt đầu bằng từ này và lấy số tiền thấp nhất từ nó”
Bạn muốn nhận dạng “hàng” có khả năng chống lại sự thay đổi khoảng trắng, rung giật dọc, trang bìa và lệch tài liệu, đồng thời bạn muốn phát hiện và lọc kiểu mạnh mẽ.
Thứ hai, đối với các biểu diễn dữ liệu có thành phần ngôn ngữ trực quan hoặc ngôn ngữ tự nhiên, chẳng hạn như bảng, hộp kiểm và các đoạn văn bản tự do, phần nguyên thủy nên nhúng ML. Ở cấp độ phân tích này, Google, Amazon, Microsoft và OpenAI đều có những công cụ hoạt động khá tốt.
Sensible chỉ áp dụng cách tiếp cận đó: kết hợp các mẫu mạnh mẽ và linh hoạt với máy học. Với
Phạm vi nguyên thủy rộng lớn của SenseML cho phép bạn nhanh chóng ánh xạ các chế độ biểu diễn tới các cấu trúc dữ liệu hữu ích, bao gồm cả các cấu trúc con lồng nhau phức tạp. Trong trường hợp các nguyên tắc không sử dụng ML, chúng hoạt động một cách xác định để cung cấp các hành vi mạnh mẽ và đảm bảo độ chính xác. Và ngay cả đối với đầu ra không xác định của các nguyên thủy được hỗ trợ bởi ML của chúng tôi, chẳng hạn như bảng, các quy tắc xác thực có thể xác định lỗi trong đầu ra ML.
Điều này có nghĩa là phân tích cú pháp tài liệu với Sensible cực kỳ nhanh chóng, minh bạch và linh hoạt. Nếu bạn muốn thêm một trường vào mẫu hoặc sửa lỗi, bạn có thể thực hiện đơn giản.
Sự cân bằng cho thời gian nhanh chóng để định giá của Sensible là mỗi bố cục tài liệu khác biệt có ý nghĩa yêu cầu một mẫu riêng biệt. Nhưng sự đánh đổi này hóa ra không quá tệ trong thế giới thực. Trong hầu hết các trường hợp sử dụng kinh doanh, có một số lượng bố cục có thể đếm được (ví dụ: hàng chục hãng vận tải đường bộ tạo ra xác nhận giá cước ở Hoa Kỳ; một số ít hệ thống phần mềm tạo báo cáo kiểm tra tại nhà). Khách hàng của chúng tôi không tạo hàng nghìn mẫu tài liệu - hầu hết đều tạo ra giá trị to lớn chỉ với một số ít.
Tất nhiên, đối với mọi biểu mẫu thuế, chính sách bảo hiểm và xác minh việc làm được sử dụng rộng rãi, chúng ta chỉ cần tạo một mẫu một lần. Đó là lý do tại sao chúng tôi đã giới thiệu…
Nguồn mở của chúng tôi
Chúng tôi tin rằng phương pháp kết hợp này là con đường giải quyết một cách minh bạch và hiệu quả vấn đề biến tài liệu thành dữ liệu có cấu trúc cho nhiều ngành, bao gồm hậu cần, dịch vụ tài chính, bảo hiểm và chăm sóc sức khỏe. Nếu bạn muốn tham gia cùng chúng tôi trong hành trình này và kết nối tài liệu của bạn với phần mềm,