چگونه AI و Python به نوسازی یک سیستم بیمه میراث کمک کردند

نوسازی یک سکوی میراث هرگز آسان نیست-به خصوص در صنایعی مانند بیمه ، جایی که سیستم ها و فرآیندهای چند ساله عمیقاً در حال غرق شدن هستند. در این پست ، من به اشتراک می گذارم که چگونه تیم توسعه ما با تزریق برخی از AI ، API و اتوماسیون با قدرت پایتون به یک جریان کار ، با یک چالش در دنیای واقعی در یک شرکت بیمه مقابله کرد. ما مشکلی را که با آن روبرو شدیم ، معماری راه حل ما ، برخی از قطعه های کد که قطعات کلیدی را نشان می دهد (بله ، کد پایتون واقعی!) و درسهایی که در طول مسیر آموخته ایم ، می پردازیم. در پایان ، خواهید دید که چگونه حتی یک سیستم میراث یکپارچه می تواند با فناوری مدرن تقویت شود – و امیدوارم الهام گرفته شود تا در پروژه های خود چیزی مشابه را امتحان کنید.

چالش میراث

نقطه شروع ما یک روند ادعاهای دردناک بود. هنگامی که مشتریان مطالبات بیمه ای را ارسال می کردند (اغلب به عنوان فرم های PDF یا ایمیل) ، تیمی از کارمندان به طور دستی هرکدام را بررسی می کنند ، اطلاعات مربوطه را استخراج می کنند ، آن را وارد سیستم اصلی ما می کنند و ادعای را به بخش مناسب اختصاص می دهند. این روند آهسته اغلب منجر به تاخیر ، خطاها و مشتریان ناامید شده می شود. به عنوان مثال ، استفاده نادرست از یک شماره سیاست یا طبقه بندی نادرست یک ادعا می تواند منجر به خطاهای پرداخت یا اصلاحات طولانی عقب و جلو شود. در طول صنعت ، این نوع خطاها (معروف به نشت مطالبات ، مانند پرداخت بیش از حد یا مطالبات پرداخت شده) تخمین زده می شود که در هر سال بین 30 تا 67 میلیارد دلار بیمه گذاران ایالات متحده هزینه داشته باشد. فراتر از ضرر پولی ، انتظار فزاینده ای برای خدمات دیجیتالی سریعتر وجود داشت – یک نظرسنجی نشان داد که 41 ٪ از مشتریان بیمه ممکن است در صورت عدم وجود قابلیت های دیجیتالی ، ارائه دهندگان را تغییر دهند. به طور خلاصه ، روند میراث ما در جبهه های مختلف پرهزینه بود. این مأموریت واضح بود: ما نیاز به ساده سازی و خودکار سازی این گردش کار بدون “RIP و Replacing” کل سیستم میراث داشتیم. چالش این بود که چگونه می توان فناوری مدرن – به ویژه هوش مصنوعی و اتوماسیون را معرفی کرد – به شکلی که با سکوی قدیمی ما خوب بازی کند (که دقیقاً با هوش مصنوعی ساخته نشده بود!). به عنوان یک پیچ و تاب اضافی ، ما باید اطمینان حاصل کنیم که هر تصمیم گیری خودکار وجود دارد دقیق و منصفانه، زیرا در بیمه ، یک اشتباه می تواند به افراد واقعی آسیب برساند و اعتماد را از بین ببرد.

معمار کردن یک راه حل با هوش مصنوعی

برای مقابله با این مشکل ، ما تصمیم گرفتیم که یک میکروسرویس جدید را در کنار سیستم میراث پیچ و مهره کنیم تا برآمدگی سنگین پردازش اسناد و سه گانه ادعای اولیه انجام شود. این رویکرد به ما اجازه می دهد تا سیستم اصلی را تا حد زیادی دست نخورده (کاهش خطر) در حالی که قابلیت های جدید را به سمت آن بارگیری می کنیم ، رها کنیم. ما راه حل را به چند مؤلفه اصلی تقسیم کردیم:
مصرف داده ها: اول ، ما باید داده های ادعا را از اسناد ورودی دریافت کنیم. ما از ابزارهای OCR و تجزیه برای استخراج خودکار متن از فرم های ادعای PDF و بدنه های ایمیل استفاده کردیم. این اسناد بدون ساختار را به داده های متنی ساختاری تبدیل کردیم که می توانیم با آنها کار کنیم.
تجزیه و تحلیل هوش مصنوعی: بعد از آن ، قسمت هوشمند – با استفاده از هوش مصنوعی برای تجزیه و تحلیل متن استخراج شده. ما بر روی دو مورد متمرکز شدیم: (1) طبقه بندی ادعا (به عنوان مثال تصادف خودکار ، خسارت ملک ، پزشکی و غیره) و (2) تشخیص هرگونه پرچم قرمز (مانند شاخص های احتمالی کلاهبرداری یا موارد فوری). پیشرفت های اخیر در هوش مصنوعی به این معنی بود که این کاملاً امکان پذیر بود: یادگیری ماشین و تکنیک های NLP می توانند کارهای روزمره مانند طبقه بندی اسناد و استخراج داده ها را با دقت بالا به صورت خودکار انجام دهند [researchgate.net]بشر آنها حتی می توانند با استفاده از الگوهای لکه بینی ، کارهایی مانند تشخیص کلاهبرداری را انجام دهند.
ادغام از طریق API: سرانجام ، نتایج AI برای بازگشت به سیستم میراث ما نیاز داشت. ما یک نقطه پایانی API REST سبک در سمت میراث (در اصل آداپتور) ایجاد کردیم که سرویس جدید پایتون ما می تواند برای به روزرسانی سیستم مطالبات با نتایج طبقه بندی تماس بگیرد یا گردش کار خاصی را ایجاد کند. این لایه API به عنوان پلی بین قدیمی و جدید عمل می کرد – یک رابط ایمن برای سوق دادن بینش هوش مصنوعی ما به نرم افزار قدیمی ادعاهای.

طوفان مغزی معماری با تیم. ما راه حل را برای اجرای ناهمزمان طراحی کردیم: با وارد شدن به ادعاهای جدید ، سرویس OCR و AI آنها را در پس زمینه پردازش می کند و سیستم میراث از طریق تماس های API به روز می شود. به این ترتیب ، از دیدگاه کاربر ، ادعاها شروع به طبقه بندی و مسیریابی تقریباً در زمان واقعی کردند ، بدون اینکه کارکنان در بیشتر موارد نیاز به مداخله داشته باشند. نکته مهم این است که ما در اوایل تصمیم گرفتیم که انسان ها را برای موارد بحرانی یا نامشخص در حلقه نگه داریم – اگر هوش مصنوعی با اطمینان یا پرچم گذاری چیزی غیرمعمول نبود ، ما به یک تنظیم کننده انسانی تعویق می کردیم. این تعادل برای حفظ انصاف و اعتماد بسیار مهم بود. حتی بهترین اتوماسیون در حوزه های حساس نیاز به نظارت دارد.

انتخاب پشته فنی

با توجه به نیازهای ما ، پایتون یک انتخاب آسان برای سرویس جدید بود. اکوسیستم غنی آن از کتابخانه های هوش مصنوعی و قابلیت های ساده HTTP ، آن را برای ساختن سریع این امر به عنوان اثبات مفهوم و بعداً یک سرویس تولید ایده آل کرده است. ما همچنین به جای ساختن خودمان از ابتدا ، از مدل های هوش مصنوعی موجود استفاده کردیم. در حقیقت ، اولین نمونه اولیه ما از API NLP خارجی (Openai’s GPT-3) برای طبقه بندی متن استفاده کرد-این به ما اجازه می دهد تا با نوشتن چند خط کد برای تماس با یک سرویس AI Cloud ، این ایده را در یک بعد از ظهر واحد تأیید کنیم. نمونه اولیه کار می کرد (می تواند به درستی یک تصادف خودکار در مقابل ادعای بیمه خانه از توضیحات را از هم جدا کند) ، که به ما اطمینان می داد. با این حال ، برای تولید باید حریم خصوصی و هزینه ها را در نظر بگیریم ، بنابراین ما به یک مدل NLP منبع باز تبدیل شدیم که می توانستیم در خانه اجرا کنیم. با استفاده از کتابخانه Transformers Face ، ما یک مدل از پیش آموزش داده شده را مستقر کردیم که می تواند طبقه بندی صفر را انجام دهد-به این معنی که می تواند متن را به دسته های تعریف شده توسط کاربر بدون آموزش صریح طبقه بندی کند.

اجرای: ورود هوش مصنوعی به گردش کار

بیایید به یک نسخه ساده از نحوه اجرای طبقه بندی AI در کد نگاه کنیم. در زیر یک قطعه پایتون وجود دارد که یک طبقه بندی کننده صفر را تنظیم می کند و از آن در نمونه توضیحات استفاده می کند توضیحات:

from transformers import pipeline

# Load a pre-trained zero-shot classification model
classifier = pipeline("zero-shot-classification", model="facebook/bart-large-mnli")

# Define possible claim categories (we can adjust these as needed)
labels = ["auto accident", "home property damage", "medical claim", "fraud risk"]

# Example claim description text
text = "I was involved in a car accident on the highway and my rear bumper is smashed."

# Use the classifier to predict which label fits best
result = classifier(text, candidate_labels=labels)
print(result)

در کد فوق ، ما یک طبقه بندی کننده مبتنی بر ترانسفورماتور را آغاز می کنیم و لیستی از برچسب های نامزد را ارائه می دهیم که مربوط به تجارت ما است. متنی که ما از آن استفاده می کنیم شرح یک ادعا است (برای مثال ، آنچه مشتری ممکن است بر روی فرم ادعا بنویسد یا به یک نماینده بگوید). این مدل برای هر برچسب نمره ای باز می گرداند ، اساساً می گوید که متن چقدر متناسب با آن دسته است. خروجی از چاپ (نتیجه) چیزی شبیه به این است (برای وضوح وضوح):

{
  "sequence": "I was involved in a car accident on the highway and my rear bumper is smashed.",
  "labels": ["auto accident", "fraud risk", "home property damage", "medical claim"],
  "scores": [0.98, 0.40, 0.05, 0.01]
}

در این مثال ، مدل به درستی “تصادف خودکار” را به عنوان گروه برتر با اعتماد به نفس بسیار بالا (98 ٪) شناسایی کرد. همچنین نمره ثانویه پایین تری به “خطر کلاهبرداری” (40 ٪) داد – به این معنی که ممکن است اشاره ای به مشکوک وجود داشته باشد ، اما به اندازه یک تصادف روشن رانندگی نیست. این پیش بینی ها به ما این امکان را می دهد تا Triage را خودکار کنیم: این ادعا به طور خودکار به عنوان یک ادعا خودکار برچسب گذاری می شود و به یک تیم متخصص Publics Auto مراجعه می شود. اگر نمره “خطر کلاهبرداری” بالاتر از آستانه خاصی بوده است ، ما همچنین می توانیم برای یک نگاه دقیق تر به واحد تحقیقات کلاهبرداری خود هشدار دهیم. این رویکرد ، با استفاده از NLP ، به ما این امکان را می داد تا به طور خودکار در مقابل ادعاهای خطرناک به صورت خودکار ، انجام دهیم ، کاری که در مقیاس به صورت دستی انجام می شود.

با استفاده از قطعه AI ، مرحله بعدی ادغام آن با بقیه سیستم بود. ما یک حلقه ساده (در یک کار برنامه ریزی شده) نوشتیم که ادعاهای جدیدی را به خود جلب می کند و طبقه بندی های تولید شده توسط AI را به عقب می اندازد. در اینجا یک تصویر شبه کد از آن ادغام آورده شده است:

import requests

# Imagine we have an API endpoint to fetch pending (newly submitted) claims
pending_claims = requests.get("http://legacy-system.local/api/claims?status=pending").json()

for claim in pending_claims:
    desc = claim["description_text"]
    # Use the same classifier and labels defined earlier
    result = classifier(desc, candidate_labels=labels)
    top_label = result["labels"][0]

    # Prepare the data to send back – e.g., update claim with category (and maybe priority)
    update_data = {"claimId": claim["id"], "predictedCategory": top_label}
    resp = requests.post("http://legacy-system.local/api/claims/route", json=update_data)
    if resp.status_code == 200:
        print(f"Claim {claim['id']} categorized as '{top_label}' and updated successfully!")

در عمل ، کد واقعی ما قوی تر بود (رسیدگی به تأیید اعتبار ، موارد خطا ، دسته بندی و غیره) ، اما ایده یکسان است. این اسکریپت به صورت دوره ای اجرا می شود (هر چند دقیقه می گویند) ، ادعاهای جدیدی را از سیستم میراث (از طریق API که اضافه کردیم) دریافت می کند ، هر کدام را با طبقه بندی AI پردازش می کند و سپس از یک تماس API دیگر برای به روزرسانی سیستم میراث با تصمیم طبقه بندی یا مسیریابی استفاده می کند. اساساً ، ما از انتهای تا انتها گردش کار را خودکار کردیم: به محض اینکه یک ادعا وارد می شود ، خوانده می شود ، درک می شود و بدون شخصی در حلقه برای اکثر پرونده ها عمل می کند. چند نکته در مورد ادغام: از آنجا که ما با یک سکوی میراث سر و کار داشتیم ، باید مراقب نحوه به روزرسانی آن باشیم. در مورد ما ، سیستم میراث با یک میکروسرویس جدید که می تواند این به روزرسانی ها را بپذیرد گسترش یافت – اصلاح خود پایه کد قدیمی بی اهمیت نبود. اگر یک API مستقیم گزینه ای نبود ، استراتژی دیگری که ما در نظر گرفتیم استفاده از یک صف پیام یا حتی اتوماسیون روباتیک فرآیند (RPA) برای وارد کردن داده ها به UI قدیمی بود. خوشبختانه ، اضافه کردن یک لایه API امکان پذیر بود و معلوم شد نه فقط برای این پروژه بلکه به عنوان یک رویکرد نوسازی عمومی بسیار مفید است. (نکته حرفه ای: بسته بندی یک سیستم میراث با API یک راه عالی برای گسترش زندگی خود در حالی که شما به صورت قطعه قطعه قطعه می کنید.)

چالش ها و شگفتی ها در طول راه

هیچ پروژه ای بدون سکسکه آن نیست! ما در حین اجرای با چالش های مختلفی روبرو شدیم:
کیفیت داده ها و خطاهای OCR: گرفتن متن تمیز از اسناد ادعای مشکل بود. OCR کامل نیست – گاهی اوقات “1000 دلار” به عنوان سردرگمی “1000” یا “L/O” در شناسه های سیاست خوانده می شود. ما برای تمیز کردن داده های استخراج شده قبل از تغذیه آن به هوش مصنوعی ، مجبور شدیم قوانین اعتبار سنجی و حتی برخی از فرآیندهای پس از فرآیند (به عنوان مثال ، اصلاحات Regex) را قرار دهیم. همانطور که می گویند زباله داخل ، زباله بیرون است.
تنظیم مدل و موارد لبه: مدل NLP از قبل آموزش دیده یک نقطه شروع عالی بود ، اما ما باید آن را برای متن خود تنظیم کنیم. ما مدل را در یک مجموعه داده کوچک از ادعاهای گذشته تنظیم کردیم تا دقت آن را در ژارگون خاص ما بهبود بخشیم. موارد خاص ، مانند تمایز ادعای “سرقت” از ادعای “خرابکاری” ، نیاز به اضافه کردن داده های نمونه بیشتر یا منطق اضافی داشت. ما همچنین آستانه ای را برای اعتماد به نفس مدل اضافه کردیم – اگر اینطور نبود ، حداقل 80 ٪ اطمینان در هر گروه ، ما این ادعا را برای بررسی دستی نشان می دهیم. این خطای انسانی اطمینان داد که وقتی هوش مصنوعی نامشخص بود ، طبقه بندی نمی کنیم.
مسائل ادغام سیستم: همانطور که با هر سیستم میراث انتظار می رود ، آزمایش ادغام برخی از سؤالات را نشان داد. به عنوان مثال ، نقطه پایانی API که ما برای به روزرسانی سیستم میراث در ابتدا ساختیم ، نمی تواند حجم بالایی را تحمل کند (فراموش کردیم که بانک اطلاعاتی قدیمی دارای قفل هایی است که باعث کندی می شود). ما با صف به روزرسانی ها و پردازش آنها در دسته های کوچکتر ، و با بهینه سازی شاخص های میراث DB برای زمینه هایی که در حال جستجوی/به روزرسانی بودیم ، این موضوع را پرداخت کردیم. ما همچنین مجبور شدیم با تیم OPS هماهنگ شویم تا اطمینان حاصل کنیم که خدمات جدید ما از دسترسی مناسب برخوردار است و هیچ سیاست امنیتی را نقض نمی کند.
انصاف و شفافیت: از طرف تجاری ، ما مجبور شدیم به ذینفعان (و خودمان) اطمینان دهیم كه هوش مصنوعی “جعبه سیاه” نبود كه تصمیمات بدون بررسی را انتخاب كند. ما تصمیمات و عوامل مهم مدل را وارد کردیم و یک داشبورد داخلی برای توضیح و نظارت بر پیشنهادات هوش مصنوعی ایجاد کردیم. این مهم بود زیرا ** حفظ انصاف و شفافیت در تصمیم گیری خودکار بسیار مهم در بیمه است.
ما با نگه داشتن یک حلقه انسان برای ناهنجاری ها و ارائه توضیحات ، اعتماد به سیستم ایجاد کردیم. در حقیقت ، پس از گذشت چند ماه از مشاهده خوب AI ، تنظیم کننده ها به توصیه های خود اطمینان بیشتری پیدا کردند – این از یک چیز جدید مشکوک به یک دستیار مفید در چشمان آنها تبدیل شد.

نتایج: جهشی به جلو برای میراث

پس از استقرار اتوماسیون هوش مصنوعی ما ، ضربه چشمگیر بودبشر آنچه قبلاً یک تیم کامل را در یک روز کامل کار می کرد ، اکنون می تواند در عرض چند دقیقه انجام شود. ادعاهای روتین تقریباً فوراً در حال طبقه بندی و مسیریابی به تیم مناسب بودند و میانگین زمان پردازش را بیش از 70 ٪ کاهش می داد. حجم کار دستی در تیم ما به همین ترتیب کاهش یافته است-آنها به جای اینکه وقت خود را برای ورود به داده ها و تریاژ بگذرانند ، آنها بر روی موارد پیچیده یا با ارزش که واقعاً به قضاوت انسانی احتیاج داشتند ، متمرکز شدند. این نه تنها کارآیی را بهبود بخشید بلکه روحیه را نیز بهبود بخشید (بیایید با آن روبرو شویم ، هیچ کس از کپی کردن داده ها در تمام روز لذت نمی برد). کیفیت و دقت نیز شاهد پیشرفت بود. ترکیبی از اتوماسیون و بررسی هدف انسانی منجر به خطاهای کمتری در رسیدگی به ادعای شد. هوش مصنوعی هرگز خسته یا بی دقتی نمی شود و اشتباهاتی را در پی داشت که ممکن است انسان از آن غافل شود. به عنوان مثال ، در طی ماه اول ، سیستم تعداد معدودی از مطالبات را به عنوان “خطر کلاهبرداری” پرچم گذاری کرد که معلوم شد که واقعاً کلاهبرداری است و به طور بالقوه ما را در پرداخت های اشتباه صرفه جویی می کند. مثل این بود که ما به سیستم میراث خود یک ابرقدرت جدید دادیم-شخصی که در زمان واقعی و در مقیاس فعالیت می کند به شکلی که طراحان اصلی هرگز نمی توانستند تصور کنند. شاید بهترین بخش بازخورد بخش های دیگر باشد. نمایندگان خدمات به مشتری گزارش دادند که مشتریان از اینکه اکنون ادعاهای خود را در حال حاضر پردازش می کنند ، خوشحال شدند. و مدیریت ما عاشق KPI ها بود: زمان چرخه سریعتر ، رضایت مشتری بالاتر و کاهش ملموس در هزینه های پردازش. این موفقیت علاقه بیشتری به نوسازی سایر بخش های پلتفرم ما داشته است (حتی صحبت از استفاده از چت بابات برای سوالات مشتری و هوش مصنوعی بیشتر برای تحریریه وجود دارد). به راحتی می توان گفت این پروژه دروازه ای برای تحول دیجیتال گسترده تر بود.

غذای اصلی برای توسعه دهندگان

برای کسانی که به دنبال آوردن AI یا اتوماسیون در یک پروژه میراث هستید ، در اینجا برخی از درس ها و نکات مربوط به تجربه ما آورده شده است:
شروع کوچک ، هدف بزرگ: ما با یک مشکل باریک (اتوماسیون ادعای اتهام) شروع کردیم که در یک زمان معقول قابل دستیابی بود. ارائه یک پیروزی سریع برای خرید برای تلاش های نوسازی بزرگتر بسیار مهم است. هنگامی که مردم موفقیت را مشاهده می کنند ، گسترش به موارد بیشتر استفاده می شود.
ابزارها و API های موجود را اهرم کنید: چرخ را دوباره اختراع نکنید. ما با استفاده از مدل های هوش مصنوعی از پیش ساخته و خدمات ابری برای نمونه اولیه خود ، زمان صرفه جویی کردیم. به همین ترتیب ، اگر سیستم میراث شما هر نوع API را دارد یا می توان از آن استفاده کرد ، از آن استفاده کنید! عملکرد میراث بسته بندی با API های مدرن می تواند عمر خود را گسترش داده و ادغام را بسیار آسان تر کند.
داده ها را در نظر بگیرید (زباله در ، زباله خارج): زمان سرمایه گذاری در تهیه داده ها. متن ورودی خود را تمیز کنید ، موارد لبه را کنترل کنید و برخی از داده های تاریخی را برای تنظیم مدل های خود جمع کنید. در دامنه هایی مانند بیمه ، داده های خاص دامنه همه تفاوت را ایجاد می کند. برای درک تفاوت های ظریف داده ها و نتایج ، کارشناسان دامنه را درگیر کنید.
انسان ها را در حلقه نگه دارید: اتوماسیون در هنگام تقویت انسان بهتر عمل می کند ، نه کورکورانه آنها را جایگزین می کند. ما به یک دلیل آستانه و مراحل بررسی دستی را تنظیم کردیم – برای گرفتن مواردی که ممکن است هوش مصنوعی اشتباه شود یا مطمئن نیست. این شبکه ایمنی برای انصاف و ایجاد اعتماد به سیستم مهم است
بشر با گذشت زمان ، تعادل ممکن است با افزایش اعتماد به نفس بیشتر به سمت اتوماسیون تغییر کند ، اما نظارت انسان همچنان ارزشمند است.
شفافیت و نظارت: این فقط مربوط به ساختن سیستم نیست – به این فکر کنید که چگونه آن را نظارت و توضیح می دهید. ما داشبورد داخلی را برای ردیابی عملکرد هوش مصنوعی (به عنوان مثال ، نرخ توافق با انسان ، زمان چرخش) و برای کمک به توضیح تصمیمات آن ساخته ایم. این مهم برای اعتماد ذینفعان و مشکلات اشکال زدایی بود. هنگامی که هوش مصنوعی پیش بینی عجیبی انجام داد ، می توانیم بر این اساس مدل یا قوانین را بررسی و بهبود بخشیم.

نتیجه گیری (داستان شما چیست؟)

نوسازی یک سیستم میراث با هوش مصنوعی و اتوماسیون سفری فوق العاده با ارزش بود. ما یک فرآیند قدیمی و لاغر را انجام دادیم و آن را به چیزی هوشمندانه و کارآمد تبدیل کردیم – تقریباً مانند تبدیل تلفن تلنگر به یک تلفن هوشمند. و ما این کار را بدون شکستن سیستم موجود یا بانک انجام دادیم ، با هوشمندی فن آوری های قدیمی و جدید. برای توسعه دهندگان ، پروژه هایی از این دست فرصتی برای تأثیر واقعی با مخلوط کردن نوآوری (هوش مصنوعی ، API های ابر ، کد جدید) با عمل گرایی (احترام به محدودیت های سیستم قدیمی) هستند. امیدوارم این داستان ایده ها و بینش هایی را در مورد چگونگی نزدیک شدن به چالش های مشابه به شما ارائه دهد. اگر تا به حال یک سیستم میراث را مدرن کرده اید ، یا اگر به فکر تزریق هوش مصنوعی/اتوماسیون به یک پروژه هستید ، دوست دارم از شما بشنوم! با چه چالش هایی روبرو هستید و چگونه آنها را حل می کنید؟ افکار ، تجربیات یا سؤالات خود را در نظرات به اشتراک بگذارید – بیایید در مورد یکدیگر بحث کنیم و یاد بگیریم. برنامه نویسی مبارک!