
Clairic مدلی برای تبدیل ورودی نامنظم به مقدارهای مشخص است: مثلاً از متن یک فاکتور، شماره سند و مبلغ را بیرون میکشد. این مسئله با نوشتن پاسخ توضیحی یا تصمیمگرفتن درباره یک تیکت فرق دارد. اگر سامانه قرار است اطلاعات را در دیتابیس ذخیره کند، تفاوت این کارها مستقیماً روی طراحی برنامه و خطاهای آن اثر میگذارد.
در این راهنما ابتدا جای Clairic را در مسیر پردازش داده روشن میکنیم، سپس یک سناریوی سند فارسی میسازیم و روش ارزیابی خروجی را توضیح میدهیم. بخش آخر به اتصال نتیجه تأییدشده به API هوش مصنوعی پاستا اختصاص دارد؛ جایی که مدل متنی میتواند از داده معتبر، توضیح قابل فهم یا پاسخ پشتیبانی بسازد.
Clairic چه کاری انجام میدهد؟
طبق مستندات رسمی Clairic، این مدل در زمان بررسی، ۲۲ اکتبر ۲۰۲۶، در وضعیت Preview قرار دارد. خروجی بر اساس فیلدهای تعریفشده شکل میگیرد و میتواند شامل مقدار استخراجی، عدد محاسبهشده یا برآورد باشد. دریافت یک مقدار با برآورد آینده یکسان نیست؛ برنامه باید نوع هر فیلد را از ابتدا مشخص کند.
برای نمونه، «شماره فاکتور» معمولاً باید در متن پیدا شود، اما «مبلغ با احتساب هزینه ارسال» ممکن است به محاسبه نیاز داشته باشد. «احتمال دیرکرد پرداخت» هم پرسشی درباره آینده است و پاسخ قطعی ندارد. قرار دادن هر سه در یک ستون متنی آزاد، تشخیص خطا و بازبینی را دشوار میکند. بهتر است نوع و کاربرد خروجی در قرارداد داده ثبت شوند.
تفاوت استخراج، تصمیمگیری و تولید متن
فرض کنید فروشگاه روزانه پیامهایی شامل تصویر رسید، توضیح مشتری و شماره سفارش دریافت میکند. مرحله اول میپرسد چه شناسه و مبلغی واقعاً در ورودی وجود دارد. مرحله دوم میپرسد این پیام باید به امور مالی برود یا پشتیبانی سفارش. مرحله سوم میتواند پاسخی مؤدبانه بنویسد که از مشتری اطلاعات تکمیلی بخواهد. هر مرحله معیار موفقیت خودش را دارد.
| کار | خروجی مورد نیاز | معیار اصلی ارزیابی |
|---|---|---|
| استخراج با مدلی مانند Clairic | مقدار تایپشده، مقدار غایب و نشانه اطمینان | تطبیق هر فیلد با پاسخ مرجع |
| تصمیمگیری با مدلی مانند Jev | احتمال گزینه یا تصمیم تعریفشده | خطای مسیریابی و کالیبراسیون احتمال |
| پاسخنویسی با مدل زبانی | توضیح یا متن گفتوگو | درستی پاسخ، اتکا به منبع و کیفیت فارسی |
در راهنمای Jev کاربرد مدل تصمیمگیری بررسی شده است. صرف اینکه دو ابزار زیر عنوان هوش مصنوعی قرار میگیرند، آنها را جایگزین مستقیم هم نمیکند. برای انتخاب، ابتدا ببینید برنامه باید یک داده را پیدا کند، از میان چند مسیر انتخاب کند یا متنی تازه بنویسد. گاهی ترکیب دو مرحله از اصرار بر یک مدل همهکاره قابل مدیریتتر است.
پیش از انتخاب مدل، قرارداد سند فارسی را بنویسید
از یک سند فرضی شروع کنید: «فاکتور شماره A-104؛ مبلغ قابل پرداخت ۱٬۲۵۰٬۰۰۰ تومان؛ هزینه ارسال در مبلغ نهایی لحاظ شده است». پرسشهای مهم فقط استخراج رقم نیستند. آیا متن واحد را مشخص کرده؟ آیا مبلغ نهایی با جمع اقلام فرق دارد؟ آیا تاریخ صدور وجود دارد؟ اگر شماره پیگیری بانکی کنار شماره فاکتور آمده، کدامیک شناسه مورد نظر برنامه است؟
برای هر فیلد، تعریف دقیق و حالت غیبت بنویسید. شماره فاکتور رشته است تا صفر ابتدای آن حفظ شود. مبلغ باید همراه واحد نگهداری شود. تاریخ اولیه را در کنار شکل استانداردش نگه دارید تا تبدیل شمسی و میلادی قابل پیگیری بماند. برای اطلاعات غایب، مقدار خالی قراردادی تعیین کنید؛ عدد صفر نباید جای «پیدا نشد» را بگیرد.
از مدل نخواهید تفاوت ریال و تومان را با حدس پر کند. اگر واحد در سند نیست، آن فیلد به بررسی نیاز دارد. تبدیل واحد را در کد برنامه و با قاعده مشخص انجام دهید. در چنین مسیری، یک عدد از نظر ظاهری معتبر میتواند از نظر تجاری کاملاً اشتباه باشد. اعتبارسنجی نوع عدد، تمام اعتبارسنجی مبلغ نیست.
ورودی آزمایشی Clairic چگونه تعریف میشود؟
در قرارداد مستقیم Workers AI، ورودی و تعریف فیلدها جدا فرستاده میشوند. این نمونه برای بررسی ساختار است؛ به کلید و حساب همان سرویس نیاز دارد و شناسه آن را نباید در endpoint متنی پاستا جایگذاری کرد. جزئیات سازگاری فیلدها را هنگام اجرا با نسخه فعلی مستندات تطبیق دهید.
{
"model": "clairic",
"state": "فاکتور A-104، مبلغ نهایی ۱۲۵۰۰۰۰ تومان؛ هزینه ارسال لحاظ شده است.",
"fields": {
"invoice_id": { "type": "text" },
"amount": {
"type": "number",
"decimals": 0,
"unit": "toman",
"instructions": "مبلغ نهایی قابل پرداخت؛ اگر واحد روشن نیست مقدار را نامشخص در نظر بگیر"
}
}
}
نمونه را با داده ساختگی یا مجاز اجرا کنید. ارسال تصویر واقعی رسید ممکن است نام، شماره تماس یا اطلاعات مالی دیگری را هم از مرز سامانه خارج کند. پیش از استفاده از هر سرویس، مسیر انتقال، سیاست نگهداری و مجوز استفاده از داده را روشن کنید. برای ارزیابی اولیه، یک سند بازسازیشده معمولاً پاسخ پرسش فنی را با افشای کمتری میدهد.