چرا اپ‌ساز هوش مصنوعی‌تان اول داده‌های قلابی نشانتان می‌دهد (و چرا این حرکت درستی است)

اگر اپ‌ساز هوش مصنوعی‌تان پیش از دست زدن به پایگاه داده، صفحه‌هایتان را با کاربرهای ساختگی و سفارش‌های نمونه پر می‌کند، این یک میان‌بُر نیست — این روش درستِ ساختن است. این‌جا می‌گوییم چرا.

اپی را برای اپ‌ساز هوش مصنوعی‌تان توصیف می‌کنید. یک دقیقه بعد به یک رابط کاربریِ کارآمد نگاه می‌کنید — صفحه‌ها، دکمه‌ها، جدولی از کاربرها با نام‌هایی مثل «Alex Rivera» و «Priya Shah»، قیمت‌هایی که جور درنمی‌آیند، یک «پلن حرفه‌ای» که درخواستش نکرده بودید. هیچ چیز ذخیره نمی‌شود. اگر صفحه را تازه کنید، داده‌ها هنوز آن‌جا هستند. اگر کاربر جدیدی اضافه کنید، ناپدید می‌شود.

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

«اول داده‌های قلابی» واقعاً یعنی چه

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

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

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

چرا این ترتیب با هوش مصنوعی بهتر جواب می‌دهد

ما ساختن پایگاه داده و صفحه‌ها را هم‌زمان امتحان کردیم. جواب نداد. این نسخهٔ کوتاهِ چرایی‌اش است.

وقتی دو عامل هوش مصنوعی روی بخش‌های مختلف یک اپ کار می‌کنند بدون اینکه خروجی هم را ببینند، حدس‌های ناسازگار می‌زنند. عامل رابط کاربری تصمیم می‌گیرد کاربرها فیلدی به نام «name» دارند. عامل پایگاه داده تصمیم می‌گیرد کاربرها فیلدی به نام «fullName» دارند. هر دو درست به نظر می‌رسند. کنار هم، هیچ چیز کار نمی‌کند. عامل سومی آورده می‌شود تا ناسازگاری را وصله کند. آن هم حدس می‌زند. حالا سه حدسِ ول روی دست است، و اپی که پیش‌نمایشش می‌کنید نوعی هیولای فرانکنشتاینی از همهٔ آن‌هاست.

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

به همین دلیل است که اپ‌ساز هوش مصنوعی‌تان می‌تواند در یک دقیقه اپی با ظاهر کامل‌شده نشانتان دهد. ساخت را قلابی نکرده. یک‌چهارمِ ساخت را انجام داده — همان بخشی که بقیه را تعیین می‌کند — و پایگاه داده، کارِ ده ثانیهٔ بعد است، نه ده ساعت بعد.

وقتی داده‌های قلابی روی صفحه‌اند به دنبال چه باشید

این همان لحظه‌ای است که بیشتر مردم ازش رد می‌شوند. داده‌های جانگهدار را می‌بینند و شروع به درخواست تغییر رنگ می‌کنند. اما داده‌های جانگهدار پرسشی است که از شما پرسیده می‌شود. بخوانیدش.

چند نمونه از آنچه باید مراقبش باشید:

  • واژگانِ اشتباه. اپی که می‌خواستید «مرسوله‌ها» را ردگیری می‌کند. داده‌های جانگهدار آن‌ها را «سفارش» می‌نامد. به اپ‌ساز بگویید. اگر حالا از کنارش رد شوید، هر صفحه، هر فیلد پایگاه داده، هر گزارش از واژهٔ اشتباه استفاده می‌کند — و تغییر نام بعداً در هیچ ابزاری یک عملیات تک‌کلیکی نیست، هر چه بازاریابی بگوید.
  • فیلدهای گمشده. صورت‌حساب قلابی یک جمع کل و یک تاریخ دارد. شما به یک شمارهٔ سفارش خرید (PO) هم نیاز دارید. بهتر است حالا اضافه‌اش کنید، وقتی پنج صورت‌حساب قلابی روی صفحه است، تا بعد از اینکه پایگاه داده ساخته و با داده‌های واقعی مشتری پر شده.
  • شکل‌های اشتباه. داده‌های قلابی «۱ مشتری، ۱ آدرس» را نشان می‌دهد. مشتری‌های واقعی شما چند آدرس دارند. اپ‌ساز نمی‌تواند این را از توصیف شما استنباط کند. حالا بگویید، در حالی که تغییر شکل هیچ هزینه‌ای ندارد.
  • موجودیت‌های غافلگیرکننده. اپ‌ساز یک مفهوم «تیم» را که درخواستش نکرده بودید اختراع کرده، چون فرض کرده اپی چندکاربره است. شاید می‌خواستیدش. شاید نمی‌خواستید. در هر صورت، پیش از آنکه پایگاه داده دور آن ساخته شود تصمیم بگیرید.

یک قاعدهٔ مفید: اگر اپ شما اسمی دارد که در داده‌های جانگهدارِ روی صفحه بازنمایی نشده، اپ‌ساز هنوز از آن خبر ندارد. پیش از کلیک روی «ذخیره» در اولین پیش‌نمایش، به آن اشاره کنید.

چرا ترتیب برای آنچه بعد می‌آید مهم است

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

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

دلیل اینکه این اصلاً جواب می‌دهد این است که هر چه پایین‌دست هست — طراحی پایگاه داده، کوئری‌ها، حالت‌های بارگذاری، حالت‌های خالی — با آنچه شما در مرحلهٔ جانگهدار روی صفحه دیدید تصمیم گرفته شد. اگر سه ستون را تأیید کردید، سه ستون می‌گیرید. اگر فیلد «وضعیت» با مقادیر «پیش‌نویس» و «ارسال‌شده» را تأیید کردید، دقیقاً همان چیزی است که پایگاه داده می‌پذیرد. هیچ گام ترجمهٔ دومی نیست که در آن یک تحویل از طراح به برنامه‌نویس چیزها را خراب کند.

یک آزمون کوچک که می‌توانید اجرا کنید

دفعهٔ بعد که چیزی می‌سازید، این را امتحان کنید: وقتی داده‌های جانگهدار ظاهر شد، پیش از درخواست هر چیز دیگری، یک چیزش را تغییر دهید. یک فیلد را تغییر نام دهید. یک ستون اضافه کنید. «users» را با «members» جایگزین کنید. بعد ببینید وقتی پایگاه داده ساخته می‌شود چه می‌شود.

تغییر را همه‌جا خواهید دید — در طراحی پایگاه داده، در کوئری‌ها، در داده‌های اولیه‌ای که اپ‌ساز هنگام تمام شدن اپ درون آن می‌گذارد. یک کلمه در مرحلهٔ جانگهدار در کل اپ موج انداخت. این همان اهرمی است که در این مرحله دارید، و دلیلی است که «اول داده‌های قلابی» یک ترفندِ گوشه‌گیرانه نیست. این جایی است که اپ واقعاً تصمیم‌گیری می‌شود.

اگر می‌خواهید عمیق‌تر بروید، آخرین مطلب ما دربارهٔ اینکه واقعاً درون یک اپ ساخته‌شده با هوش مصنوعی چه چیزی هست دیگر اجزای متحرکی را که در نگاه اول نمی‌بینید مرور می‌کند. الگو همان است: بیشترِ اهرم در بخش‌هایی است که به نظر می‌رسد اهمیتی ندارند.