خروجی ساختاریافته چیست؟ تبدیل پاسخ مدل زبانی به داده قابل‌استفاده

چرا پاسخ متنی برای اتصال به سامانه کافی نیست؟

فرض کنید کارشناس تدارکات از مدل می‌خواهد شماره سفارش، مبلغ و تاریخ تحویل را از یک نامه استخراج کند. اگر پاسخ هر بار با قالب متفاوت برگردد، اتصال آن به فرم سفارش شکننده می‌شود. خروجی ساختاریافته نام فیلدها، نوع مقدار و مقادیر مجاز را مشخص می‌کند تا برنامه بداند چه چیزی تحویل می‌گیرد.

در مستندات Google Cloud، تعیین طرح پاسخ راهی برای هدایت خروجی به ساختاری مشخص است. پشتیبانی از اجزای طرح به مدل و سرویس وابسته است؛ بنابراین نباید فرض کرد هر قاعده JSON Schema بدون بررسی اجرا می‌شود.

طرح را از نیاز کسب‌وکار بسازید

پیشنهاد اجرایی تحریریه برای همین مثال، شروع با پنج فیلد است: شناسه سفارش، مبلغ، واحد پول، تاریخ تحویل و نشانی شاهد در سند. برای مقدار نامعلوم، وضعیت خالی یا نیازمند بررسی تعریف کنید؛ مجبور کردن مدل به پر کردن همه فیلدها می‌تواند حدس را به داده ظاهراً معتبر تبدیل کند.

واحد پول را از مبلغ جدا کنید و تاریخ را با قالب مشخص نگه دارید. تاریخ شمسی موجود در نامه نباید بدون تبدیل معتبر به‌عنوان تاریخ میلادی ثبت شود. نسخه طرح را نیز ذخیره کنید تا تغییر نام یا نوع فیلد، مصرف‌کننده‌های قبلی را ناگهان از کار نیندازد.

اعتبارسنجی ساختار با صحت محتوا فرق دارد

یک مبلغ می‌تواند عددی معتبر و در عین حال متعلق به سطر اشتباه باشد. بعد از بررسی ساختار، قواعد دامنه را اجرا کنید: مبلغ منفی نباشد، واحد پول شناخته‌شده باشد و شناسه سفارش با داده مرجع تطبیق کند. شاهد استخراج باید به محل واقعی اطلاعات در همان سند برسد.

در صورت نقص، خطای مشخص برگردانید و تعداد تلاش مجدد را محدود کنید. برای داده حساس، نتیجه را پیش‌نویس نگه دارید تا کارشناس آن را تأیید کند؛ خروجی مرتب به‌تنهایی مجوز تغییر اطلاعات عملیاتی نیست.

برای ادامهٔ این بحث، مقالهٔ «اعتبارسنجی خروجی هوش مصنوعی با Pydantic؛ JSON کافی نیست» را در دانشنامهٔ لیان بخوانید.

یک آزمون کوچک و قابل‌اندازه‌گیری

برای آزمایش، مجموعه‌ای از نامه‌های عادی، اسکن کم‌کیفیت، مبلغ چندارزی و تاریخ مبهم بسازید. پاسخ مرجع را کارشناس تهیه کند. نرخ موفقیت ساختار، درستی هر فیلد و درصد ارجاع به انسان را جداگانه بسنجید.

قبولی زمانی معنا دارد که اطلاعات ناموجود نیز درست تشخیص داده شوند. اگر مدل در نبود شماره سفارش، شماره تلفن را جای آن می‌گذارد، افزایش زیبایی پاسخ یا طول دستور مسئله اصلی را حل نمی‌کند؛ تعریف فیلد، کیفیت ورودی و مسیر بازبینی باید اصلاح شوند.

نمونه کامل: از نامه خرید تا پیش‌نویس فرم

برای اجرای آزمایشی، نامه‌ای بسازید که در آن شماره سفارش PO-204، مبلغ ۱۲۵ میلیون ریال و تاریخ تحویل به‌صورت شمسی نوشته شده باشد. یک شماره تماس و شماره پیش‌فاکتور هم در نامه بگذارید تا تشخیص شناسه درست آزموده شود. خروجی موردانتظار را قبل از اجرای مدل بنویسید؛ کارشناس باید مشخص کند هر مقدار از کدام عبارت یا سطر آمده است. این نمونه پیشنهادی آموزشی است و لازم نیست با نامه واقعی مشتری شروع شود.

جریان را به چهار مرحله جدا تقسیم کنید: دریافت سند و شناسه آن، استخراج به قالب ثابت، کنترل قواعد و نمایش پیش‌نویس. در صفحه بازبینی، مقدار استخراج‌شده را کنار تصویر همان بخش نشان دهید. اگر کارشناس مبلغ را اصلاح کرد، مقدار اولیه، مقدار نهایی و علت اصلاح را نگه دارید. این تفکیک روشن می‌کند خطا از خواندن سند بوده، از انتخاب سطر یا از قاعده تبدیل واحد؛ در نتیجه اصلاح بعدی هدف مشخصی خواهد داشت.

با مقدار خالی، صفر و تعارض چگونه برخورد کنیم؟

صفر، نبود مقدار و نامشخص بودن سه وضعیت متفاوت‌اند. اگر هزینه حمل در سند ذکر نشده، قرار دادن صفر می‌تواند به معنی رایگان بودن حمل تفسیر شود. در طراحی پیشنهادی، برای هر فیلد حساس علاوه بر مقدار، وضعیت‌هایی مانند استخراج‌شده، ناموجود یا متعارض داشته باشید. دلیل وضعیت باید به شاهد وصل شود؛ توضیح آزاد مدل بدون ارجاع برای رفع تعارض کافی نیست.

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

خطاها را به مسیر اصلاح درست بفرستید

برای سه نوع شکست مسیر متفاوت تعریف کنید. پاسخ نامعتبر از نظر ساختار به مرحله تبدیل یا تولید برگردد؛ رقم ناخوانا به بازبینی سند ارجاع شود؛ شناسه سفارش ناموجود در سامانه مرجع به کارشناس تدارکات برسد. تکرار همان درخواست روی تصویر ناخوانا، معمولاً فقط مصرف و زمان را زیاد می‌کند و شواهد تازه‌ای ایجاد نمی‌کند. سقف تلاش و دلیل توقف باید در وضعیت کار دیده شود.

برای هر اجرا شناسه سند، نسخه طرح، نسخه دستور و نتیجه کنترل‌ها را ثبت کنید؛ ثبت متن کامل اسناد در گزارش عمومی ضروری نیست. اگر بعداً نام فیلد تغییر کرد، با نمونه‌های ذخیره‌شده بررسی کنید مصرف‌کننده قبلی چه می‌کند. مهاجرت را با نسخه مشخص انجام دهید و اجازه ندهید یک سرویس مبلغ را بر حسب ریال و دیگری همان عدد را تومان تفسیر کند. سازگاری قرارداد بین اجزا به اندازه درست بودن پاسخ مدل اهمیت دارد.

چک‌لیست تحویل و سنجش منفعت واقعی

در پایان پایلوت از کارشناس بخواهید چند فرم را بدون راهنمایی تیم توسعه تکمیل کند. زمان شروع تا تأیید، تعداد اصلاح هر فرم و نوع خطاها را ثبت کنید. زمان تولید پاسخ به‌تنهایی معیار کافی نیست؛ اگر یافتن شاهد و تصحیح داده بیشتر از ورود دستی زمان ببرد، فرایند هنوز ارزش عملی موردنظر را ایجاد نکرده است. نمونه‌های مبهم و بدون مقدار را نیز در همین اندازه‌گیری نگه دارید.

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