‏SchemaFlow: تغییر دیتابیس با کمک ایجنت‌های هوش مصنوعی

یه درخواست ساده مثل «یه ستون nullable اضافه کن و دیتای قدیمی رو پرش کن» در عمل می‌تونه روی کلی چیز اثر بذاره: جدول‌های landing، مدل‌های staging، جدول‌های core، مارت‌ها، منطق گزارش‌گیری و حتی فرضیات lineage. به گفتهٔ این کوک‌بوک OpenAI، مشکل اینه که این درخواست‌ها از چند دست رد می‌شن و سر هر دست یه بخشی از context گم می‌شه. SchemaFlow اومده همین درخواست آزاد رو به یه workflow ساختاریافته و قابل بازبینی تبدیل کنه.

ایدهٔ اصلی اینه که به‌جای یه مدل تک که مستقیم SQL نهایی بده، کار بین چند ایجنت تخصصی پخش می‌شه و هر کدوم یه مسئولیت باریک دارن. Parse Agent درخواست رو به یه JSON ساختاریافته تبدیل می‌کنه، Impact Agent جدول‌ها و ستون‌ها و ریسک‌های متاثر رو پیدا می‌کنه، Plan Agent پلن رول‌اوت می‌سازه و SQL Agent خود SQL رو در لایه‌های مختلف دیتا درفت می‌کنه. مزیتش اینه که اگه یه ستون تو SQL جا افتاد، می‌تونی دقیق ببینی مشکل از کدوم مرحله شروع شده.

خروجی هر مرحله typed هست؛ یعنی با مدل‌های Pydantic و output schema خود Agents SDK شکل دقیق خروجی مشخص می‌شه تا مرحلهٔ بعدی روی دیتای خراب کار نکنه. یه نکتهٔ مهم دیگه guardrailهای بین مرحله‌ایه: بعد از هر بخش چک‌های قطعی و برنامه‌نویسی‌شده اجرا می‌شن که مثلاً مطمئن شن یه فیلد nullable به اشتباه NOT NULL تولید نشده یا منطق backfill جا نیفتاده. این چک‌ها جای بازبینی انسانی رو نمی‌گیرن، ولی خطاهای خاموش و رایج رو زود می‌گیرن.

یه قابلیت اختیاری هم RAG روی PDF هست. اگه مسیر یه فایل PDF مثل یه schema spec یا داکیومنت lineage رو بدی، نوت‌بوک یه vector store تو OpenAI می‌سازه، فایل رو آپلود و ایندکس می‌کنه و به Impact Agent یه FileSearchTool می‌ده تا تحلیل تاثیر رو بر اساس همون مستندات grounded کنه. این وقتی به درد می‌خوره که درخواست تغییر نیاز به تکیه به یه مرجع معماری یا data contract داشته باشه.

نویسنده تاکید می‌کنه که SchemaFlow هیچ side effectی روی دیتابیس نداره؛ فقط SQL درفت و نتیجهٔ ولیدیشن تولید می‌کنه، migration اجرا نمی‌کنه و سیستم production رو دست نمی‌زنه. آخر کار هم همه‌چی تو یه bundle جمع می‌شه (درخواست تفسیرشده، تحلیل تاثیر، پلن، SQL و نتیجهٔ ولیدیشن) و به‌صورت JSON ذخیره می‌شه. حتی می‌شه با Promptfoo کل فلو رو eval کرد، چون فایل‌های اجرای eval از همون state فعلی نوت‌بوک ساخته می‌شن.

نکات کلیدی:

• کار تغییر دیتابیس به چند مرحله جدا می‌شه: parse، تحلیل تاثیر، پلن و تولید SQL
• هر مرحله ایجنت تخصصی خودش رو داره که دیباگ و ردیابی رو راحت می‌کنه
• خروجی‌ها typed هستن (Pydantic + output schema) و بین مرحله‌ها guardrail قطعی اجرا می‌شه
• RAG روی PDF اختیاریه و تحلیل تاثیر رو به مستندات واقعی وصل می‌کنه
• هیچ‌چی روی دیتابیس واقعی اجرا نمی‌شه؛ خروجی یه bundle قابل بازبینی JSONه