تقریباً هر سازمانی که چند سال داده جمع کرده، یک مشکل مشترک دارد: دادهها از منابع مختلف — فرم سایت، اکسل کارمندان، ورودی دستی، ایمپورت از سیستم قدیمی — وارد شدهاند و هرکدام قواعد خودشان را داشتهاند. تاریخ یکجا شمسی است و یکجا میلادی، شماره تماس گاهی با صفر شروع میشود و گاهی با کد کشور، و نامها گاهی برعکس ثبت شدهاند. پاکسازی دستی این حجم داده عملاً غیرممکن است، و همینجا هوش مصنوعی میتواند نقش مؤثری ایفا کند — بهشرط آنکه محدودیتهایش را بشناسید.
لیست مطالب
چرا این مسئله فقط «find and replace» نیست
یک اسکریپت ساده میتواند فرمتهای شناختهشده را با regex تشخیص دهد، اما دادهٔ واقعی پر از استثناست: نامی که هم اسم کوچک و هم فامیل در یک فیلد نوشته شده، شمارهای که یک رقم کم دارد، تاریخی که روز و ماهش جابهجا نوشته شده. مدل زبانی برخلاف regex، بافت را میفهمد — میتواند تشخیص دهد «رضایی، علی» همان «علی رضایی» است، یا «۰۹۱۲-۱۲۳-۴۵۶۷» و «+98 912 123 4567» یک شمارهاند. این توانایی، پاکسازی را از یک کار قانونمحور به یک کار استنتاجمحور تبدیل میکند.

نرمالسازی تاریخ
یکی از رایجترین مسائل، اختلاط تقویم شمسی و میلادی، و فرمتهای مختلف جداکننده (/، -، فاصله) است. یک prompt خوب برای نرمالسازی، باید فرمت خروجی را دقیق مشخص کند تا مدل حدس نزند:
ورودی: «تاریخ سفارش: 1402/11/03»
دستور: این تاریخ را به فرمت میلادی ISO 8601 (YYYY-MM-DD)
تبدیل کن. اگر تقویم منبع مشخص نیست، آن را حدس نزن و
فیلد «calendar_uncertain: true» را برگردان.
خروجی:
{
"normalized_date": "2024-01-23",
"source_calendar": "jalali",
"calendar_uncertain": false
}
نکتهٔ کلیدی همین بخش «حدس نزن» است. وقتی تاریخ مبهم است (مثلاً «03/04/1402» که میتواند سوم تیر یا چهارم خرداد باشد)، باید مدل این ابهام را بهجای حل خودسرانه، اعلام کند تا یک انسان تصمیم بگیرد.
نرمالسازی شماره تماس
شمارههای تماس ایرانی به شکلهای گوناگونی ثبت میشوند: با صفر ابتدایی، بدون آن، با کد کشور ۹۸+، با ارقام فارسی بهجای انگلیسی، یا حتی با فاصلهٔ اضافی وسط رقمها. یک قاعدهٔ عملی: خروجی را همیشه به یک فرمت واحد (مثلاً E.164: +989121234567) تبدیل کنید و اگر طول رقمها با هیچ الگوی معتبری جور درنمیآید، آن را invalid علامت بزنید نه اینکه رقم حدس زده شود.
| ورودی خام | مشکل | خروجی نرمال |
|---|---|---|
| ۰۹۱۲۱۲۳۴۵۶۷ (ارقام فارسی) | ارقام غیر ASCII | +989121234567 |
| 9121234567 | بدون صفر یا کد کشور | +989121234567 |
| 0912 123 45 67 | فاصلهٔ اضافی | +989121234567 |
| 091212345 | یک رقم کم | invalid — نیاز به بررسی دستی |
| رضایی علی | ترتیب نام و فامیل برعکس | نام: علی، نامخانوادگی: رضایی |
نرمالسازی نامها
نامها سختترین بخش هستند، چون هیچ قاعدهٔ ریاضی قطعی برای تشخیص «نام» از «نامخانوادگی» وجود ندارد. مدل زبانی با دانش زبانی خود میتواند حدس معقولی بزند (مثلاً بداند «رضایی» معمولاً نامخانوادگی است)، اما این حدس همیشه درست نیست — بهخصوص برای نامهای دوبخشی یا غیرایرانی. راهکار عملی این است که خروجی مدل را همراه با یک confidence یا فلگ عدمقطعیت بگیرید و رکوردهای confidence پایین را برای بازبینی انسانی جدا کنید، نه اینکه کل دیتابیس را کورکورانه بازنویسی کنید.
چرا نباید به مدل اجازهٔ overwrite مستقیم داد
بزرگترین ریسک در پاکسازی داده با AI این نیست که مدل اشتباه کند — طبیعی است که گاهی اشتباه کند — بلکه این است که اشتباهش بیسروصدا و در مقیاس بزرگ رخ دهد. اگر خروجی مستقیماً روی دادهٔ اصلی overwrite شود، یک الگوی سیستماتیک اشتباه (مثلاً تفسیر غلط یک فرمت تاریخ خاص) میتواند هزاران رکورد را خراب کند، بدون اینکه تا مدتها کسی متوجه شود. الگوی امنتر:
- خروجی نرمالشده را در یک ستون یا جدول جدید بنویسید، نه جایگزین دادهٔ خام.
- یک نمونهٔ تصادفی (مثلاً ۵٪ از رکوردها) را قبل از اعمال کامل، دستی بررسی کنید.
- رکوردهایی که مدل با عدمقطعیت مشخص کرده را از پردازش خودکار جدا نگه دارید.
- یک لاگ از تغییرات (قبل/بعد) نگه دارید تا در صورت خطا بتوان برگشت.
برای آشنایی با معماری بزرگتر pipelineهای دادهای مبتنی بر AI، نقشهٔ راه هوش مصنوعی و داده را ببینید؛ و برای نوشتن promptهایی که این نوع خروجی ساختاریافته و قابلاتکا تولید میکنند، نقشهٔ راه مهندسی پرامپت راهنمای خوبی است.
ادغام پاکسازی AI با قوانین موجود، نه جایگزینی آنها
یک اشتباه رایج این است که تیمها پاکسازی مبتنی بر AI را بهجای قوانین اعتبارسنجی ساده و شناختهشده (مثل regex برای فرمت ایمیل، یا چکسام برای کد ملی) قرار میدهند. این رویکرد هم گرانتر است و هم غیرضروری. روش درست، لایهبندی است: ابتدا قوانین قطعی و سریع اعمال شوند (فرمتهای شناختهشده، اعتبارسنجی چکسام)، و فقط رکوردهایی که از این فیلتر عبور نکردند یا واقعاً نیاز به استنتاج زبانی دارند (مثل تشخیص نام از یک رشتهٔ آزاد) به مدل زبانی سپرده شوند. این ترکیب هم هزینهٔ فراخوانی مدل را کاهش میدهد و هم دقت کلی pipeline را بالا میبرد، چون هر ابزار در حوزهٔ تخصص خودش کار میکند.
دستهبندی خطاهای رایج در پاکسازی با AI
سه الگوی خطا در پاکسازی داده با مدل زبانی بهکرات دیده میشود. اول، اعتماد بیشازحد به یک خروجی «قانعکننده» — مدل معمولاً حتی وقتی مطمئن نیست، جوابی روان و باورپذیر تولید میکند، که این ویژگی برای پاکسازی داده خطرناک است چون تشخیص خطا سختتر میشود. دوم، نادیده گرفتن رکوردهای لبهای (edge case) — مثلاً نامهای تککلمهای یا شمارههای بینالمللی غیرایرانی — که معمولاً بیشترین نرخ خطا را دارند و باید جداگانه بررسی شوند. سوم، عدم ثبت اینکه چه درصدی از رکوردها با عدمقطعیت علامت خوردهاند؛ بدون این عدد، تیم نمیداند چقدر از داده هنوز نیازمند بازبینی انسانی است.
جمعبندی
- پاکسازی داده با AI برای استثناهای زبانی (نام، ترتیب فیلد) قویتر از regex عمل میکند، اما جایگزین قوانین ساده و شناختهشده نیست.
- در promptهای نرمالسازی، فرمت خروجی را دقیق مشخص کنید و از مدل بخواهید در ابهام حدس نزند بلکه اعلام کند.
- همیشه شماره تماس و تاریخ را به یک فرمت استاندارد واحد (مثل E.164 و ISO 8601) تبدیل کنید.
- خروجی را در ستون/جدول جدا بنویسید و قبل از overwrite کامل، نمونهگیری و بازبینی انسانی انجام دهید.
- یک لاگ قابلبرگشت از هر تغییر نگه دارید تا خطای سیستماتیک قابل جبران باشد.
