استيعاب البيانات غير المنظمة وشبه المنظمة

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

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

تتعامل RPA التقليدية مع هذا بمطابقة القوالب. يُعرَّف مكان ظهور رقم الفاتورة، وأين تبدأ بنود السطر، وأين يقع الإجمالي. ينجح هذا مع قالب البائع الحالي. ثم يحدّث البائع نظامه، يزحزح عموداً، يضيف صفحة رأس، أو يغيّر مولد PDF الخاص به، فيفشل الروبوت أو يستخرج بيانات غير صحيحة تنتشر في المجرى حتى يكتشفها شخص يدوياً.

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

كيف تحل Triggerfish هذا

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

تحليل المستندات بقوة LLM

عندما يدخل مستند سير عمل Triggerfish، يقرأ وكيل LLM الفرعي المستند بأكمله ويستخرج بيانات منظمة استناداً إلى ما يعنيه المستند، لا إلى مكان وجود بكسلات بعينها. رقم الفاتورة هو رقم فاتورة سواء كان في الزاوية العلوية اليمنى مُسمىً "Invoice #" أو في منتصف الصفحة مُسمىً "Factura No." أو مضمناً في فقرة نصية. يفهم LLM أن "Net 30" تعني شروط الدفع، وأن "Qty" و"Quantity" و"Units" تعني الشيء ذاته، وأن جدولاً بأعمدة للوصف والسعر والمبلغ يمثل قائمة بنود السطر بصرف النظر عن ترتيب الأعمدة.

هذا ليس نهج "أرسل المستند إلى ChatGPT وأمل في الأفضل" العام. يحدد تعريف سير العمل بدقة ما هو المخرج المنظم الذي يجب على LLM إنتاجه، وما هي قواعد التحقق المطبقة، وما يحدث عند انخفاض ثقة الاستخراج. تُعرّف وصف مهمة الوكيل الفرعي المخطط المتوقع، وتتحقق الخطوات اللاحقة في سير العمل من البيانات المستخرجة مقارنة بقواعد العمل قبل دخولها أي نظام مجرى.

أتمتة المتصفح لاسترداد المستندات

تبدأ كثير من سير عمل استيعاب المستندات بالحصول على المستند أصلاً. تقيم نماذج EOB التأمينية في بوابات شركات الدفع. تقيم فواتير الموردين في منصات المورّدين. تقيم النماذج الحكومية على مواقع الوكالات الحكومية. تستخدم الأتمتة التقليدية سكريبتات Selenium أو استدعاءات API لجلب هذه المستندات، وتتعطل هذه السكريبتات عند تغيير البوابة.

تستخدم أتمتة متصفح Triggerfish Chromium المتحكم بـ CDP مع LLM يقرأ لقطات الصفحة للتنقل. يرى الوكيل الصفحة كما يراها الإنسان ويضغط ويكتب ويتمرر استناداً إلى ما يراه لا إلى محددات CSS مُرمَّزة. عند إعادة تصميم بوابة دفع لصفحة تسجيل دخولها، يتكيف الوكيل لأنه لا يزال يستطيع تحديد حقل اسم المستخدم وحقل كلمة المرور وزر الإرسال من السياق البصري. عند تغيير قائمة التنقل، يجد الوكيل المسار الجديد إلى قسم تحميل المستند.

هذا ليس موثوقاً بشكل مثالي. CAPTCHAs وتدفقات المصادقة متعددة العوامل والبوابات المعتمدة بشكل كبير على JavaScript لا تزال تسبب مشاكل. لكن نمط الفشل يختلف جوهرياً عن السكريبتات التقليدية. تفشل سكريبتة Selenium بصمت عند توقف محدد CSS عن المطابقة. يُبلّغ وكيل Triggerfish عما يراه وما جرّبه وأين توقف، مانحاً المشغّل سياقاً كافياً للتدخل أو تعديل سير العمل.

المعالجة المحكومة بالتصنيف

تحمل المستندات مستويات مختلفة من الحساسية، ويعالج نظام التصنيف هذا تلقائياً. قد تكون الفاتورة المحتوية على شروط التسعير CONFIDENTIAL. قد تكون استجابة RFP العامة INTERNAL. مستند يحتوي على PHI هو RESTRICTED. عندما يقرأ وكيل LLM الفرعي مستنداً ويستخرج بيانات، يُصنّف hook POST_TOOL_RESPONSE المحتوى المستخرج ويتصاعد taint الجلسة وفقاً لذلك.

هذا يهم لتوجيه المجرى. البيانات المستخرجة من الفاتورة المصنفة بمستوى CONFIDENTIAL لا يمكن إرسالها إلى قناة Slack مصنفة بمستوى PUBLIC. سير عمل يعالج وثائق التأمين المحتوية على PHI يقيّد تلقائياً مكان تدفق البيانات المستخرجة. تطبق قاعدة منع الكتابة التنازلية هذا عند كل حدود، ولا يملك LLM أي سلطة لتجاوزها.

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

التكيف الذاتي مع تغييرات التنسيق

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

بمرور الوقت، يمكن للوكيل استخدام الذاكرة بين الجلسات لتعلم الأنماط. إذا كان البائع A دائماً يضمّن رسوماً لإعادة التخزين لا يدرجها بائعون آخرون، يتذكر الوكيل ذلك من الاستخراجات السابقة ويعرف أن يبحث عنها. إذا كان تنسيق نماذج EOB لشركة دفع بعينها دائماً يضع رموز التعديل في موقع غير معتاد، تجعل ذاكرة الوكيل للاستخراجات الناجحة السابقة المستقبلية أكثر موثوقية.

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

تنسيق خطوط الأنابيب

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

قد يبدو خط أنابيب التفويض المسبق للرعاية الصحية هكذا: تجلب أتمتة المتصفح صورة الفاكس من بوابة المزود، يستخرج وكيل LLM الفرعي معرفات المريض ورموز الإجراء، يتحقق استدعاء HTTP من المريض مقارنة بالسجل الصحي الإلكتروني، يقيّم وكيل فرعي آخر ما إذا كان التفويض يستوفي معايير الضرورة الطبية استناداً إلى الوثائق السريرية، ويُوجَّه الناتج إما للموافقة التلقائية أو إلى طابور المراجع السريري. كل خطوة مُتتبَّعة بالتصنيف. كل قطعة من PHI مُصنفة بـ taint. يوجد مسار التدقيق الكامل تلقائياً.

كيف يبدو هذا عملياً

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

مع Triggerfish، يعالج سير عمل خط الأنابيب الكامل. تسترد أتمتة المتصفح أو تحليل البريد الإلكتروني المستندات. تستخرج وكلاء LLM الفرعيون البيانات المنظمة بصرف النظر عن التنسيق. تتحقق خطوات التحقق من البيانات المستخرجة مقارنة بقواعد بيانات السجل الصحي الإلكتروني والصيدلانية. سقف تصنيف RESTRICTED يضمن عدم مغادرة PHI لحدود خط الأنابيب. المستندات التي لا يستطيع LLM تحليلها بثقة عالية تُوجَّه إلى مراجع بشري، لكن هذا الحجم ينخفض بمرور الوقت مع بناء ذاكرة الوكيل مكتبة من أنماط التنسيق.

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