النموذج يبصق حقل إضافي. هل يجب عرضه مباشرة أم رفضه؟ دعونا نرى ما إذا كان هناك اتفاق أولا

يقوم النموذج بإرجاع حقل آخر في نتائج الاستخراج المنظمة، ويمكن للواجهة الأمامية عرضه بسهولة مباشرة كمعلومات مفيدة. على سبيل المثال، إذا كان هناك confidence إضافي في نتيجة الاستخراج، فسيتم عرضه على أنه "مصداقية" على الصفحة. المشكلة هي أن هذا المجال قد لا يكون محددًا أو معايرًا. الحقول الإضافية ليست بالضرورة غير ضارة، وقد تسمح للمستخدمين النهائيين باستخدام القيم غير المتفق عليها كأساس للحكم.

هذه المقالة مناسبة للطلاب المسؤولين عن تصميم الواجهة أو الإرساء الأمامي والخلفي أو عمليات معالجة المستندات. يشرح ما يلي كيفية تحديد ما إذا كانت الواجهة مفتوحة أم مغلقة أولاً، وكيفية تحويل الحقول غير المعروفة إلى أخطاء يمكن ملاحظتها، وما هي المعلومات التي يجب إرجاعها بعد الرفض. وبعد قراءتها، يمكنك أن تقرر ما إذا كان يجب رفض الحقول الإضافية أو تجاهلها أو تضمينها في الإصدار الجديد.

تستخدم هذه المقالة عينات صناعية لتوضيح طريقة المعالجة. تم فحص الكود بأمثلة في بيئة معزولة ولا يضمن جميع الملفات الحقيقية أو أداء المنتج. قبل معالجة المستندات المهمة، يرجى الاحتفاظ بالنسخ الأصلية ومراجعتها وفقًا للحدود وبنود القبول في النص.

هل يمكن عرض الحقول المتعددة للنموذج مباشرة؟ استنتاج جملة واحدة

اتفق على العقد أولاً، ثم قرر ما إذا كنت تريد قبوله أو رفضه: لا ينبغي عرض الحقول غير المحددة والمعايرة بشكل مباشر كدليل موثوق.

حدد أولاً ما إذا كانت الواجهة مفتوحة أم مغلقة

يمكن أن تسمح أدوات الاستكشاف الداخلي بمجالات موسعة، وغالبًا ما تتطلب واجهات التسليم المستقرة حدودًا أكثر صرامة. عند تعيين خصائص إضافية الخاص بـ JSON Schema على false، يمكن رفض السمات غير المحددة للكائن الحالي، ولكن لن تتم الكتابة فوق كل كائن متداخل تلقائيًا بشكل متكرر. ما هو مسموح به في كل مستوى يجب أن يكون مكتوبا بوضوح.

هذا لا يعني أن جميع الواجهات يجب أن ترفض جميع الامتدادات. المفتاح هو جعل الاختيار واضحًا وترك آلية الإصدار مفتوحة للترقيات. إن تجاهل الحقول التي تحمل الاسم نفسه اليوم بصمت واستخدامها فجأة غدًا يمكن أن يؤدي بسهولة إلى تفسيرات مختلفة للبيانات التاريخية.

تحويل الحقول غير المعروفة إلى أخطاء يمكن ملاحظتها

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}})

القيمة الرقمية 0.99 في المثال هي مجرد مدخلات اصطناعية يجب رفضها، وليست نتيجة جودة حقيقية لأي طراز. يتحقق المثال من طبقات المستوى الأعلى والمتداخلة في نفس الوقت لمنع الإغفالات التي تغلق الطبقة الخارجية فقط وتسمح للطبقة الداخلية بالتوسع بشكل تعسفي.

تقديم معلومات قابلة للإصلاح بعد الرفض

📊 المقارنة الأساسية: الواجهة المفتوحة والواجهة المغلقة

يعد إسقاط الحقول أيضًا أحد قرارات معالجة البيانات

إذا تم استخدام "قراءة الحقول المعروفة وتجاهل الحقول الأخرى" بالفعل، فيجب توثيق النتائج الأصلية وسلوك التصفية. بخلاف ذلك، سيكون من الصعب التمييز بين ما إذا كانت البيانات المصدر لا تحتوي في الأصل على عنصر معين، أو ما إذا كانت طبقة الواجهة قد أزالته. لا ينبغي أيضًا أن يكون إسقاط الحقل وسيلة لإخفاء عدم امتثال النموذج للبروتوكول.

اترك حدودًا للترجمة والاستخراج

إن مخرجات ترجمة المستندات والمخرجات الميدانية المنظمة هما عقدان مختلفان. عند استخدام OmniDoc لمعالجة المستندات، يمكنك استخدام قائمة الحقول للتحقق بعد الترجمة، ولكن لا يمكنك قبول أحكام الأعمال الإضافية أو حقول الثقة تلقائيًا لمجرد أن الترجمة تتم بسلاسة.

🎯 ما هي الطريقة المناسبة لك؟

إذا كنت تقوم بأدوات الاستكشاف الداخلي

قد يُسمح بحقول الامتداد، ولكن يجب أن يتم عرضها على أنها غير محددة.

إذا كنت تحافظ على واجهة تسليم مستقرة

قم بإحاطة كل طبقة بـ additionalProperties: false وحدد حدودًا منفصلة للكائنات المتداخلة.

إذا كنت ترغب في تقديم مجالات جديدة

قم بإصدار إصدارات جديدة من المخطط، ولا تقم بإرخاء الإصدارات القديمة سرًا.

إذا كانت العملية الخاصة بك تحتاج إلى تجاهل الحقول الزائدة

قم بتسجيل النتائج الأصلية وسلوك التصفية لسهولة التتبع لاحقًا.

❓ الأسئلة الشائعة (الأسئلة الشائعة)

1. هل يمكن لـ additionalProperties: false تغطية كافة المستويات؟

لا يمكن الكتابة فوقه تلقائيًا. إنه يرفض فقط السمات غير المحددة للكائن الحالي، ويحتاج كل كائن متداخل إلى كتابة ما هو مسموح به بشكل منفصل بوضوح.

2. هل حقول الإخراج المتعددة في النموذج ضارة بالضرورة؟

ليس بالضرورة، ولكنه قد يسمح للمستخدمين النهائيين باستخدام قيم غير متفق عليها كأساس، لذلك يجب التأكد من حالة تعريفهم ومعايرتهم أولاً.

3. ما الذي يجب إرجاعه عند رفض الحقول الإضافية؟

يجب أن يتضمن اسم مفتاح غير معروف، ومسار الكائن (عندما يكون داخليًا) وإصدار البروتوكول، وليس مجرد خطأ JSON.

4. هل يمكن تجاهل الحقول الزائدة مباشرة؟

نعم، ولكن يجب توثيق النتائج الأولية وسلوك التصفية وتجنب استخدامها لإخفاء المشكلات حيث لا يلتزم النموذج بالبروتوكول.

📝 ملخص

لا يمكن عرض الحقول الإضافية مباشرةً لأنها تبدو مفيدة. يجب عليك الموافقة على حدود الواجهة أولاً، ومن ثم تحديد قبول الإصدار أو رفضه أو ترقيته. فقط من خلال توضيح القواعد في كل طبقة يمكن أن تكون البيانات التاريخية والتفسير النهائي متسقين.

جربه الآن: قم بتحميل المستند لبدء الترجمة، مع الاحتفاظ بالتخطيط الأصلي