OmniDocMô hình tạo ra một trường bổ sung. Nó nên được hiển thị trực tiếp hay bị từ chối? Hãy xem liệu có thỏa thuận trước không
Có thêm `confidence` trong kết quả trích xuất. Giao diện người dùng trông rất hữu ích nên được hiển thị trực tiếp là "uy tín". Vấn đề là trường này có thể không được xác định hay hiệu chỉnh. Trường bổ sung không nhất thiết là vô hại: nó có thể cho phép người dùng xuôi dòng dựa vào các giá trị không được thống nhất.
Mô hình trả về một trường nữa trong kết quả trích xuất có cấu trúc và giao diện người dùng có thể dễ dàng hiển thị trực tiếp trường đó dưới dạng thông tin hữu ích. Ví dụ: nếu có thêm confidence trong kết quả trích xuất, nó sẽ được hiển thị dưới dạng "độ tin cậy" trên trang. Vấn đề là trường này có thể không được xác định hay hiệu chỉnh. Các trường bổ sung không nhất thiết vô hại và có thể cho phép người dùng tiếp theo sử dụng các giá trị không được thống nhất làm cơ sở để phán đoán.
Bài viết này phù hợp với những sinh viên chịu trách nhiệm thiết kế giao diện, front-end và back-end docking hoặc các quy trình xử lý tài liệu. Phần sau đây giải thích cách quyết định trước tiên xem giao diện đang mở hay đóng, cách biến các trường không xác định thành lỗi có thể quan sát được và thông tin nào sẽ được trả về sau khi bị từ chối. Sau khi đọc nó, bạn có thể quyết định xem các trường bổ sung sẽ bị từ chối, bỏ qua hay đưa vào phiên bản mới.
Bài viết này sử dụng các mẫu tổng hợp để trình bày phương pháp xử lý. Mã đã được kiểm tra bằng các ví dụ trong môi trường biệt lập và không đảm bảo cho tất cả các tệp thực hoặc hiệu suất sản phẩm. Trước khi xử lý các văn bản quan trọng, vui lòng giữ lại bản chính và xem xét theo ranh giới và các mục chấp nhận trong văn bản.
Có thể hiển thị trực tiếp nhiều trường của mô hình không? Một câu kết luận
Đồng ý với hợp đồng trước, sau đó quyết định chấp nhận hay từ chối hợp đồng: các trường không xác định và hiệu chỉnh không được hiển thị trực tiếp dưới dạng bằng chứng đáng tin cậy.
| hoàn cảnh của bạn | Các phương pháp được đề xuất | lý do |
|---|---|---|
| Công cụ khám phá nội bộ | Các trường mở rộng có thể được cho phép | Ưu tiên tính linh hoạt trong giai đoạn thăm dò |
| Giao diện phân phối ổn định | Đóng từng lớp bằng additionalProperties: false | Từ chối các thuộc tính không xác định để tránh đọc sai ở cuối dòng |
| Các lĩnh vực pháp lý mới xuất hiện | Xuất bản phiên bản mới của lược đồ | Đừng bí mật thư giãn các phiên bản cũ |
| Chọn bỏ qua các trường thừa | Ghi lại kết quả ban đầu và hành vi lọc | Thật thuận tiện để phân biệt xem dữ liệu nguồn không có trường này hay lớp giao diện đã loại bỏ nó. |
Đầu tiên hãy quyết định xem giao diện đang mở hay đóng
Các công cụ khám phá nội bộ có thể cho phép mở rộng các trường và giao diện phân phối ổn định thường yêu cầu ranh giới chặt chẽ hơn. Khi thuộc tính bổ sung của Lược đồ JSON được đặt thành false, các thuộc tính không xác định của đối tượng hiện tại có thể bị từ chối, nhưng mỗi đối tượng lồng nhau sẽ không được tự động ghi đè theo cách đệ quy. Những gì được phép ở mỗi cấp độ nên được viết rõ ràng.
Điều này không có nghĩa là tất cả các giao diện sẽ từ chối tất cả các tiện ích mở rộng. Điều quan trọng là đưa ra lựa chọn rõ ràng và để cơ chế tạo phiên bản mở cho các bản nâng cấp. Việc âm thầm bỏ qua các trường có cùng tên ngày hôm nay và đột nhiên sử dụng chúng vào ngày mai có thể dễ dàng dẫn đến những cách hiểu khác nhau về dữ liệu lịch sử.
Biến các trường không xác định thành lỗi có thể quan sát được
from jsonschema import Draft202012Validator
schema = {"type": "object", "required": ["name", "evidence"],
"properties": {"name": {"type": "string"},
"evidence": {"type": "object", "required": ["page"],
"properties": {"page": {"type": "integer", "minimum": 1}},
"additionalProperties": False}},
"additionalProperties": False}
validator = Draft202012Validator(schema)
valid = lambda x: not list(validator.iter_errors(x))
assert valid({"name": "Demo", "evidence": {"page": 1}})
assert not valid({"name": "Demo", "confidence": 0.99, "evidence": {"page": 1}})
assert not valid({"name": "Demo", "evidence": {"page": 1, "guess": True}})Giá trị số 0.99 trong ví dụ chỉ là đầu vào tổng hợp cần bị từ chối, không phải là kết quả chất lượng thực sự cho bất kỳ mô hình nào. Ví dụ kiểm tra các lớp cấp cao nhất và lồng nhau cùng lúc để tránh thiếu sót chỉ đóng lớp bên ngoài và cho phép lớp bên trong mở rộng tùy ý.
Cung cấp thông tin có thể sửa chữa sau khi bị từ chối
| Tình trạng | Thông tin trả lại phải bao gồm | không nên làm gì |
|---|---|---|
| Nhiều trường cấp cao nhất | Tên khóa không xác định, phiên bản giao thức | Tự động hiển thị nó dưới dạng chỉ báo đáng tin cậy |
| Đa trường bên trong | Đường dẫn đối tượng, tên khóa không xác định | Chỉ trả về một lỗi JSON |
| Phiên bản mới gia hạn hợp pháp | Lược đồ mới rõ ràng | Bí mật thư giãn các phiên bản cũ |
| Mô hình liên tục xuất ra các khóa dự phòng | Lý do lỗi trích xuất tác vụ | Sau mỗi lần xóa, nó được coi là đầu ra ban đầu đủ tiêu chuẩn. |
📊 So sánh cốt lõi: giao diện mở và giao diện đóng
| Kích thước | giao diện mở | giao diện đóng |
|---|---|---|
| Các tình huống áp dụng | Công cụ khám phá nội bộ | Giao diện phân phối ổn định |
| Xử lý các trường dư thừa | Cho phép gia hạn | Từ chối các thuộc tính không xác định |
| Rủi ro chính | Các giá trị không thống nhất được lấy làm cơ sở | Nhiệm vụ không thành công khi mô hình thỉnh thoảng xuất ra nhiều đầu ra và cần được điều tra. |
| Phương pháp nâng cấp | Sử dụng trực tiếp | Được mở rộng rõ ràng bởi các phiên bản mới của lược đồ |
Bỏ trường cũng là một quyết định xử lý dữ liệu
Nếu "đọc các trường đã biết, bỏ qua các trường khác" thực sự được sử dụng thì kết quả ban đầu và hành vi lọc phải được ghi lại. Nếu không, sẽ khó phân biệt được dữ liệu nguồn ban đầu không có mục nào đó hay lớp giao diện đã loại bỏ mục đó. Việc loại bỏ trường cũng không phải là một cách để che giấu sự không tuân thủ giao thức của mô hình.
Để lại ranh giới cho việc dịch và trích xuất
Đầu ra dịch tài liệu và đầu ra trường có cấu trúc là hai hợp đồng khác nhau. Khi sử dụng OmniDoc để xử lý tài liệu, bạn có thể sử dụng danh sách trường để xác minh sau dịch, nhưng bạn không thể tự động chấp nhận các trường phán đoán kinh doanh hoặc trường tin cậy bổ sung chỉ vì bản dịch trơn tru.
🎯 Phương pháp nào phù hợp với bạn?
Nếu bạn đang thực hiện các công cụ khám phá nội bộ
Các trường mở rộng có thể được cho phép nhưng chúng vẫn phải được hiển thị dưới dạng không xác định.
Nếu bạn đang duy trì giao diện phân phối ổn định
Bao bọc mỗi lớp bằng additionalProperties: false và xác định các ranh giới riêng biệt cho các đối tượng lồng nhau.
Nếu bạn muốn giới thiệu các lĩnh vực mới
Phát hành các phiên bản mới của lược đồ, đừng bí mật nới lỏng các phiên bản cũ.
Nếu tiến trình của bạn cần loại bỏ các trường dư thừa
Ghi lại kết quả ban đầu và hành vi lọc để dễ dàng theo dõi sau này.
❓ Câu hỏi thường gặp (FAQ)
1. additionalProperties: false có thể bao gồm tất cả các cấp độ không?
Không thể ghi đè tự động. Nó chỉ từ chối các thuộc tính không xác định của đối tượng hiện tại và mỗi đối tượng lồng nhau cần viết rõ ràng những gì được phép riêng.
2. Nhiều trường đầu ra trong một mô hình có nhất thiết phải có hại không?
Không nhất thiết, nhưng nó có thể cho phép người dùng tiếp theo sử dụng các giá trị chưa được thống nhất làm cơ sở, do đó, định nghĩa và trạng thái hiệu chuẩn của chúng phải được xác nhận trước tiên.
3. Điều gì sẽ được trả về khi từ chối các trường bổ sung?
Phải bao gồm tên khóa không xác định, đường dẫn đối tượng (khi ở bên trong) và phiên bản giao thức, không chỉ là lỗi JSON.
4. Có thể bỏ qua trực tiếp các trường thừa được không?
Có, nhưng kết quả thô và hành vi lọc phải được ghi lại và tránh sử dụng nó để che giấu các vấn đề trong đó mô hình không tuân thủ giao thức.
📝 Tóm tắt
Các trường bổ sung không thể được hiển thị trực tiếp chỉ vì chúng trông hữu ích. Trước tiên, bạn phải đồng ý về ranh giới giao diện, sau đó quyết định chấp nhận, từ chối hay nâng cấp phiên bản. Chỉ bằng cách làm rõ các quy tắc ở mỗi lớp thì dữ liệu lịch sử và diễn giải tiếp theo mới có thể nhất quán.
Thử ngay: Tải tài liệu lên để bắt đầu dịch, giữ nguyên bố cục ban đầu
