پرسش ساده، تعریف تجاری پیچیده
مدیر فروش می‌پرسد «فروش این ماه شعبهٔ غرب چقدر است؟»؛ اما فروش ممکن است مبلغ فاکتور، مبلغ وصول‌شده یا مبلغ خالص پس از برگشت باشد. «این ماه» هم به تقویم، منطقهٔ زمانی و زمان ثبت وابسته است. ساخت یک SQL معتبر از نظر دستور زبان هنوز پاسخ این ابهام‌ها نیست.
در سناریوی آموزشی این مقاله، ابتدا شاخص فروش خالص و بازهٔ زمانیِ مصوب را مشخص می‌کنیم. اگر عبارت کاربر با دو تعریف معتبر سازگار باشد، سامانه باید سؤال روشن‌کننده بپرسد. ثبت یک پاسخ اشتباه با عدد دقیق و نمودار زیبا، مشکل را جدی‌تر می‌کند؛ دقت ظاهری جای تعریف مشترک را نمی‌گیرد.
مدل به قرارداد معنایی داده نیاز دارد
در مقالهٔ فنی Google Cloud دربارهٔ Text-to-SQL، زمینهٔ پایگاه داده و معنای سؤال از مسائل اصلی تولید پرس‌وجو هستند. برای نمونهٔ ما، فقط فرستادن فهرست نام جدول‌ها کافی نیست. باید رابطهٔ فاکتور و اقلام، وضعیت لغوشده، واحد مبلغ و تعریف تاریخ قابل استفاده روشن باشد.
یک نمای تحلیلی محدود می‌تواند نام‌گذاری و محاسبات مصوب را متمرکز کند. این پیشنهاد به معنای مناسب‌بودن یک View برای همهٔ سازمان‌ها نیست؛ مالک داده باید تعیین کند چه قرارداد معنایی قابل نگه‌داری است. مستند آن قرارداد را نسخه‌بندی کنید و مثال‌های صحیح و خطاهای رایج را کنار آن بگذارید تا تغییر طرح، پاسخ را بی‌صدا عوض نکند.
برای ادامهٔ این بحث، مقالهٔ «معماری داده برای عامل‌های هوشمند سازمانی» را در دانشنامهٔ لیان بخوانید.
پیش از اجرا چه چیزی قابل بازبینی است؟
در جریان پیشنهادی، سامانه ابتدا برداشت خود را نشان می‌دهد: فروش خالص، شعبهٔ مجاز، بازهٔ شروع و پایان، واحد مبلغ و سطح تجمیع. سپس پیش‌نویس پرس‌وجو ساخته می‌شود. کارشناس نباید برای فهمیدن معنای گزارش مجبور باشد فقط SQL را تفسیر کند؛ تعریف شاخص باید به زبان قابل استفاده هم ثبت شود.
اگر سؤال دربارهٔ اطلاعات فردی یا تجمیعی بسیار ریز باشد، مسیر پاسخ می‌تواند محدود یا به بازبین ارجاع شود. پارامترهای استخراج‌شده از سؤال دادهٔ قابل اعتبارسنجی‌اند، نه مجوز تازه. مجوز مشاهدهٔ شعبه یا ستون از سیاست جاری برنامه می‌آید و نباید با تأیید تفسیر سؤال اشتباه شود.
فقط‌خواندنی بودن کافی نیست
PostgreSQL برای تراکنش فقط‌خواندنی و سیاست‌های امنیت سطر سازوکار مشخص دارد. نقش مالک جدول و نقش‌های دارای اختیار ویژه نیز استثناهایی دارند که باید در طراحی دیده شوند. نتیجهٔ عملی این است که اتصال Agent را با یک حساب کم‌اختیارِ مناسب سناریو آزمایش کنید، نه حساب مدیریتی که هنگام دمو همه‌چیز را می‌بیند.
این کنترل‌ها به‌تنهایی تضمینِ بی‌خطر بودن هر پرس‌وجو نیستند. حتی یک خواندن مجاز می‌تواند دادهٔ بیش از نیاز، محاسبهٔ سنگین یا تابع نامناسب را درگیر کند. پیشنهاد این مقاله محدودسازی اشیای قابل دسترسی، بررسی ساختار پرس‌وجو و کنترل تابع و خروجی است؛ یک جست‌وجوی متنی برای کلمهٔ SELECT مرز امنیتی کاملی نمی‌سازد.
بودجهٔ اجرا را بیرون از مدل اعمال کنید
مستندات PostgreSQL تنظیم‌هایی مانند statement_timeout را برای کنترل زمان اجرای دستور توضیح می‌دهد. در کاربرد سازمانی، مهلت اجرا را ابزار اجرایی اعمال می‌کند، نه اینکه فقط در Prompt به مدل گفته شود سریع باشد. سقف تعداد ردیف، اندازهٔ خروجی و هم‌زمانی درخواست‌ها نیز باید از ظرفیت واقعی محیط بیاید.
برای نمونهٔ فروش، گزارش موردنظر تجمیعی است و معمولاً نیازی به فرستادن تک‌تک فاکتورها به مدل نیست. اگر پرس‌وجو از بودجه فراتر رفت، سامانه نباید برای تمام‌شدن کار، خودسرانه محدودیت را بردارد. باید دامنه را کوچک‌تر کند، درخواست را صف‌بندی کند یا گزینهٔ مناسب‌تری به کاربر بدهد و علت را قابل پیگیری ثبت کند.
صحت نتیجه را بسنجید، نه فقط اجرای موفق را
مجموعهٔ مرجع را با تحلیلگر کسب‌وکار بسازید. برای هر سؤال، تعریف شاخص، نسخهٔ داده، دامنهٔ مجاز و نتیجهٔ مورد انتظار مشخص باشد. دو SQL متفاوت ممکن است نتیجهٔ درست یکسان بدهند و یک SQL اجرایی ممکن است به‌دلیل Join تکراری مبلغ را دو برابر کند؛ تطبیق رشتهٔ متن، معیار کافی نیست.
در آزمون پیشنهادی، برگشت از فروش، فاکتور لغوشده، مقدار خالی، مرز پایان ماه و شعبهٔ فاقد دسترسی را وارد کنید. علاوه بر نتیجهٔ عددی، رفتار سؤال روشن‌کننده و امتناع از درخواست نامجاز را بسنجید. دادهٔ مرجع را ثابت یا نسخه‌بندی کنید تا اختلاف ناشی از تغییر واقعی تراکنش‌ها با خطای مدل اشتباه نشود.
گزارش نهایی چه اطلاعاتی داشته باشد؟
خروجی مناسبِ نمونهٔ ما عدد، واحد پول، بازهٔ دقیق، تعریف فروش خالص و زمان اجرای پرس‌وجو را نشان می‌دهد. اگر بخشی از داده هنوز نرسیده یا دسترسی کاربر محدود است، این محدودیت باید دیده شود. از عددی که فقط برای یک شعبهٔ مجاز محاسبه شده، نتیجهٔ کل سازمان نسازید.
برای بازبینی، شناسهٔ اجرای پرس‌وجو، نسخهٔ تعریف شاخص و مسیر دادهٔ استفاده‌شده را نگه دارید. لازم نیست همهٔ ردیف‌های حساس در هر گزارش ثبت شوند. تفکیک گزارش مدیریتی، شواهد فنی و دادهٔ خام کمک می‌کند هم کارشناس بتواند خطا را پیگیری کند و هم اطلاعات اضافی بی‌دلیل منتشر نشود.
آغاز محدود، با مسیر توقف روشن
اولین کاربرد را با چند شاخص مصوب و خواندن محدود آغاز کنید؛ نوشتن در پایگاه داده یا تأیید مالی را به همان ابزار عمومی اضافه نکنید. این‌ها سناریوهای جدا با مرز اختیار و آزمون مستقل‌اند. پیش از توسعهٔ دامنه، روشن کنید چه کسی تغییر طرح یا تعریف شاخص را تأیید و آزمون را دوباره اجرا می‌کند.
بستهٔ تحویل شامل قرارداد معنایی، نقش اجرایی، قواعد اعتبارسنجی، بودجهٔ اجرا، پرسش‌های مرجع و نمونهٔ خطاهاست. مثال‌ها و کنترل‌های این متن پیشنهاد طراحی‌اند و ادعای قابلیت آمادهٔ یک اتصال مشخص آیوان نیستند. موفقیت Text-to-SQL زمانی معنا دارد که عدد قابل توضیح و اجرای آن قابل کنترل باشد، نه فقط وقتی درخواست به SQL تبدیل شود.
پرسش‌های متداول
آیا اجرای بدون خطای SQL یعنی پاسخ درست است؟
خیر. تعریف شاخص، Join، فیلتر تاریخ و دامنهٔ دسترسی می‌توانند نتیجه را غلط کنند. نتیجهٔ معنایی را روی دادهٔ مرجع بسنجید.
آیا حساب فقط‌خواندنی جلوی نشت داده را می‌گیرد؟
فقط‌خواندنی بودن نوشتن را محدود می‌کند، اما دسترسی به ستون‌ها، سطرها و خروجی باید جدا کنترل شود؛ نقش‌های ویژه و توابع نیز نیاز به بررسی دارند.
چه زمانی باید سؤال روشن‌کننده پرسید؟
وقتی تعریف شاخص، دورهٔ زمانی، واحد یا سطح تجمیع مبهم است و انتخاب یکی از تفسیرها می‌تواند تصمیم را عوض کند.
منابع و مطالعهٔ پژوهشی
- Google CloudGetting AI to write good SQL: Text-to-SQL techniques explainedEngineering article · 16 May 2025
- PostgreSQLRow Security PoliciesOfficial documentation · PostgreSQL 18
- PostgreSQLSET TRANSACTIONOfficial documentation · PostgreSQL 18
- PostgreSQLClient Connection DefaultsOfficial documentation · statement_timeout
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسمعماری داده برای عامل‌های هوشمند سازمانیبرای طراحی زمینهٔ معتبر، مطلب لیان نقش مالکیت، تازگی و سطح دسترسی داده را در انتخاب منابع عامل توضیح می‌دهد.