بعد از این نظرسنجی شاید بد نباشه تا با هم فکر کنیم ببینیم چه روش‌هایی می‌شه استفاده کرد تا AI به صو…

🖊 چرا سؤال نداریم؟این موضوع رو در ۳ پُست مجزا، به ظاهر طولانی ولی در قسمت‌های کوتاه که منقطع خوندنشون آسون باشه تموم کردم. توی این سه بخش سعی کردم از سه زاویه متفاوت بهش نگاه کنم:1️⃣ چرا سؤال اصلاً توی ذهن ما شکل نمی‌گیره؟از شکاف اطلاعاتی و اطمینان کاذب، تا نقش آموزش و کودکی در ساختن یا خاموش‌کردن پرسشگری.🔗 [لینک بخش اول]2️⃣ وقتی سؤال داریم، چرا نمی‌پرسیم؟از امنیت روانی و فاصله با قدرت، تا فرهنگ، و سکوتی که گاهی اصلاً نشانه رضایت نیست.🔗 [لینک بخش دوم]3️⃣وقتی سؤال می‌پرسیم، آیا واقعاً دنبال فهمیدنیم؟ و اثر هوش‌مصنوعیآیا فقط دنبال شاهدی برای تأیید جوابی هستیم که از قبل انتخاب کردیم؟ این بخش بیشتر درباره Confirmation Bias، هوش مصنوعی و خطر تازه‌ای به اسم Sycophancy است.🔗 [لینک بخش سوم]به‌نظرم در هر شغل، موقعیت و سطحی، «پرسشگر» بودن، بلد بودنِ پرسش خوب و توانایی دیدن و حل مسئله، مهارت‌های بنیادی‌ای هستن.دعوت می‌کنم بخونید و اگه براتون مفید بود، برای بقیه هم بفرستید. پی‌نوشت: معرفی موضوع، ۲۰۸۸ بار دیده شد و ۳۲ بار بازنشر! ولی قسمت اول مطلب ۵۹ بار دیده شد. نمونه بانمکی از پیشی گرفتن آگهی از آگاهی بود!

🌟 انواع حملات پرامپت اینجکشن به زبان ساده و با مثالهمون‌طور که شیوه توسعه نرم‌افزار و نحوه تعامل کاربر با نرم‌افزار، بعد از فراگیر شدن مدل‌های زبانی، تغییر کرده، نحوه تهاجم و حملات نرم‌افزاری هم تغییر کرده. یکی از موضوعاتی که باید بهش توجه مضاعفی کنیم، حملات Prompt Injection است که انواعش رو به زبان ساده و با مثال توضیح می‌دم.به زبون ساده، Prompt Injection یعنی مهاجم تلاش کنه با واردکردن دستوراتی در ورودی، رفتار مدل رو از هدف اصلی‌اش منحرف کنه، محدودیت‌ها رو دور بزنه یا مدل رو وادار کنه اطلاعات یا عملیاتی ناخواسته انجام بده. برعکس حملات سنتی نرم‌افزار، خیلی‌هاش بُعد فنی زیاد و کدنویسی عجیب نداره، و گاها با کمی زیرکی و هوش و زبون‌بازی می‌شه حمله رو درآورد!!۱۸ مدل حمله رو با مثال و به صورت خلاصه و ساده توضیح دادم، و فکر می‌کنم خوندنش خوب باشه. و دقت کنید که همین یکی دو ماه گذشته شرکت‌های بزرگ تکنولوژی و حتی توسعه‌دهنده مدل‌ها هم درگیر چنین حملاتی شدن؛ پس درک داشتن از چنین حملاتی لازمه.1. Direct Prompt Injection2. Indirect Prompt Injection3. Stored Prompt Injection4. Reflected Prompt Injection5. Cross-Context Prompt Injection6. Tool-Use Injection7. Tool Output Injection8. RAG Prompt Injection9. Multimodal Prompt Injection10. Prompt Obfuscation11. Role-Playing Injection12. Instruction Hierarchy Attack13. Context Poisoning14. Memory Poisoning15. Data Exfiltration Injection16. Goal Hijacking17. Denial-of-Service Prompt Injection18. Agent-to-Agent Prompt Injection🔗 لینک مطلب

نیل دگراس تایسون، جایی می‌گه:💡 یکی از چالش‌های بزرگ دنیا اینه که آدم‌ها درباره یک موضوع فقط اونقدری بدونن که فکر کنن حق با اون‌هاست، اما نه اونقدری که بفهمن دارن اشتباه می‌کنن.این عارضه، خیلی جاها هست، توی توسعه و معماری نرم‌افزار و AI هم هست و خیلی آزاردهنده است. اینجوری نباشیم 😅

معرفی Ontology Playgroundاصلاً Ontology یعنی چی؟به بیان ساده، Ontology یک مدل صریح از «مفاهیم یک دامنه و رابطه بین آن‌ها» است.مثلاً توی دامنه منابع‌انسانی، ممکنه داشته باشیم:EmployeeDepartmentPositionManagerLeaveRequestو روابطی مثل:Employee worksIn DepartmentEmployee hasPosition PositionEmployee reportsTo ManagerEmployee submits LeaveRequestتفاوتش با ER Diagram یا دیتابیس‌مدل اینه که هدف Ontology فقط تعریف جدول‌ها و Foreign Keyها نیست. Ontology تلاش می‌کنه معنای مفاهیم، ویژگی‌ها و روابط رو به شکل استاندارد و قابل‌فهم برای انسان و ماشین توصیف کنه.مثلا:Manager is a type of EmployeeEmployee may report to another EmployeeLeaveRequest belongs to exactly one Employeeاین مدل می‌تونه مبنای Knowledge Graph، semantic search ، reasoning و پاسخ‌گویی هوشمند روی داده‌ها باشه.حالا Ontology Playground چی کار می‌کنه؟این یه پروژه کدباز وبی است که بدون backend خاصی قابل اجراست. می‌تونید Ontologyها رو به‌صورت گراف ببینی و بسازی، و روی Nodeها کلیک کنی، Propertyها رو بررسی کنی و Entityها و Relationshipها را جست‌وجو کنی.ابزار از Import و Export فایل‌های RDF/XML و OWL پشتیبانی می‌کنه. یعنی Ontology رو می‌تونی ویژوال ترسیم کنی و بعد خرجی متنی بگیری بدی AI تا برای تولید یا ویرایش کد درک بهتری از بیزنس شما داشته باشه.توی تنظیماتش قابلیتی به اسم AI Builder وجود داره، ولی به‌صورت پیش‌فرض غیرفعاله و برای فعال‌شدن به Azure OpenAI وابسته است.لینک دمو برنامه لینک ریپازیتوری گیت‌هاب

بدون شرحالبته تشخیص صحیح top یا mid یا junior بودن خودش یکی از مراحل عرفانه 😅

داستان یک Date بد!گاهی بزرگ‌ترین باگ‌ها، اون‌هایی نیستن که همون لحظه خطا بدن یا سیستم رو متوقف کنن. بلکه گاهی باگ، ۲۰ سال، ۳۰ سال، یا حتی بیشتر کنار ما زندگی می‌کنه. همه هم می‌دونن که بده. همه هم تجربه‌اش کردن. همه هم حداقل یک بار بهش فحش و فضیحت دادن. ولی چون میلیون‌ها خط کد بهش وابسته‌ است، کسی جرأت نمی‌کنه مستقیم دست ببره و درستش کنه.شروع ماجرا: ده روز فرصت و یک تصمیم عجولانهسال ۱۹۹۵، Brendan Eich در Netscape، شرکتی که بعدها پروژه Mozilla از دلش بیرون اومد؛ فقط ده روز وقت داشت تا زبونی بسازه که بعداً اسمش شد JavaScript. دستور مدیریت هم روشن بود: «شبیه جاوا بسازش.» در چنین شرایطی، برای بخش تاریخ و زمان، ساده‌ترین راه رو رفت: Date رو مستقیم از java.util.Date کپی کرد (به بیان دقیق‌تر: در عمل Date جاوا به JavaScript منتقل شد؛ حتی Brendan بعدتر توضیح داده که این بخش، port مستقیمی از Date جاوا به C بوده. Ken Smith که یکی از توسعه‌دهنده‌های Netscape بود قبلاً از Borland اومده بود؛ java.util.Date نسخه JDK 1.0 جاوا رو port کرد. این port مستقیماً برای موتور JavaScript Netscape انجام شد، که عمدتاً به زبان C بو که بعدتر به ++C نوشته شد.)!نکته‌ی جالب اینجاست که خودِ اون پیاده‌سازی جاوا هم از اول مشکل‌دار بود؛ اونقدر افتضاح بود که فقط دو سال بعد، توی جاوا ۱.۱، تقریباً اکثر متدهاش منسوخ شدن و با یه API جدید جایگزین شدن. یعنی جاوااسکریپت یک طراحی معیوب رو از زبانی به ارث برد که خودش هم اون رو منسوخ کرد بعداً. و چون طبق اصل بنیادین TC39 یعنی «don't break the web» هیچ تغییری در Date مجاز به شکستن کدهای موجود نبود، این طراحی معیوب دقیقاً همون‌طور که بود، در استاندارد ECMAScript 1 (سال ۱۹۹۷) رسمی و منجمد شد.فهرست مشکلات هم که برای هر کسی که با جاوااسکریپت کار کرده آشناست:ماه‌ها zero-indexed هستند (0 میشه ژانویه) ولی روزها و سال‌ها نه! یک ناهماهنگی بی‌دلیل که فقط باگ تولید می‌کرد.آبجکت قابل تغییر (mutable) است؛ یعنی هر تابعی که یک Date بهش پاس بده می‌تونه بی‌سروصدا مقدارش رو عوض کنه.هیچ پشتیبانی واقعی از timezone وجود نداشت و فقط UTC و timezone محلی سیستم.رفتار parser اون‌قدر غیرقابل پیش‌بینی بود که در عمل غیرقابل‌اعتماد محسوب می‌شد.هیچ پشتیبانی از تقویم‌های غیرمیلادی (هجری و…) نداشت.برای دو دهه، راه‌حل اکوسیستم این بود که این مشکلات رو دور بزنن، و نه اینکه حل کنن. کتابخونه‌هایی مثل Moment.js (که خودش mutable بود و باندل سنگینی داشت)، بعدتر هم چندین کتابخونه دیگه که هرکدوم یک لایه‌ی محافظتی روی یه هسته‌ی خراب ساختن، از راه رسیدن. الگویی که هر مهندسی می‌شناسه: وقتی یک مشکل بنیادین رو نمی‌شه حل کرد، دورش دیوار می‌کشیم و اسمش رو می‌گذاریم best practice 😅نقطهٔ شروع واقعی: یک گفتگوی توییتریاینجا بخشی از داستانه که کمتر روایت می‌شه و برای منی که سال‌هاست دنبال «لحظه‌های شروع» می‌گردم، جالب‌ترین قسمت ماجراست. سال ۲۰۱۷، Maggie Pint که اون موقع یه مهندس نرم‌افزار توی مایکروسافت بود و هنوز لید هم نشده بود، طی یک گفتگوی توییتری با Brendan Eich (خالق جاوااسکریپت) و Matt Johnson (نگهدارندهٔ Moment.js) درباره‌ی همین ذات خراب Date صحبت می‌کردن. و همون گفتگو بود که Brendan تاریخچه‌ی تصمیم ده‌روزه‌اش رو براشون تعریف می‌کنه. از دل همین صحبت، Maggie با Brian Terlson (نمایندهٔ مایکروسافت توی TC39 و ویراستار وقت ECMA262) هم آشنا می‌شه و همون‌جا تصمیم می‌گیرن که وقتش رسیده این مشکل رو از بیخ حل کنن.نکته‌ای که باید با دقت گفت: این داستانِ «یک نفر که تنهایی یه مشکل بیست‌ساله‌ی زبان رو حل کرد» نیست؛ و اینجوری گفتنش، بی‌احترامی به شخصیت کاری این افراد، و به واقعیتِ پروژه است. اونچه واقعاً اتفاق افتاده این بوده که یک گفتگوی غیررسمی توی توییتر، نقطهٔ شروع یک تلاش چندساله و رسمی در TC39 شده؛ با آدم‌های مهمی مثل Philipp Dunkel، Maggie Pint ،Matt Johnson-Pint، و Shane F. Carr، به‌علاوه‌ی توسعه‌دهنده‌هایی مثل Bloomberg و Igalia که پروپوزال Temporal رو رسماً همون سال ۲۰۱۷ باز کردن. جالب اینجاست که این تلاش عظیم و چندساله، سرمنشأیی به این کوچکی و این غیررسمی داشته.حالا چرا این‌قدر طول کشید؟پروپوزال Temporal مسیر استاندارد TC39 رو طی کرد:سال ۲۰۱۷ — Stage 1: پذیرش پروپوزال به‌عنوان یک مسیر اکتشافی.سال ۲۰۱۹ — Stage 2: انتشار طراحی اولیه.سال ۲۰۲۱ — Stage 3: تکمیل spec و پیاده‌سازی‌های آزمایشی شروع شدن.مارس ۲۰۲۶ — Stage 4: که Temporal رسماً بخشی از ECMAScript 2026 می‌شه.عملا ۹ سال، فقط برای طی‌کردن این مراحل. چرا؟ چون این بار قرار نبود همون اشتباه تکرار بشه. طراحی Temporal باید همه‌چیز رو پوشش می‌داد: تقویم‌های قمری-شمسی چینی، تقویم اسلامی، عبری، امپراتوری ژاپن؛ دیتابیس جهانی timezone یعنی IANA TZDB با تمام گذارهای DST؛ محاسبات duration با ماه‌ها و سال‌های با طول متغیر؛ و یکپارچگی عمیق با Intl. توی این مسیر، هر ادعای «تمام شد» با یک edge case جدید (مثل رفتار مبهم wall-clock در لحظهٔ تغییر ساعت DST) نقض می‌شده و spec دوباره اصلاح می‌شده.یک تلنگر جالب هم در سال ۲۰۲۲ اتفاق افتاده: آسیب‌پذیری path traversal در Moment.js (CVE-2022-31129) نشون داد که حتی کتابخونه‌های پایه‌ای هم بخشی از سطح حمله اپلیکیشن می‌شن. این اتفاق استدلال برای وجود یک راه‌حل native رو قوی‌تر کرد.رسیدن به مقصد: Node.js 26پنجم ماه می امسال، Node.js 26 منتشر شد و برای اولین‌بار Temporal بدون هیچ flag یا پیش‌نیازی، به‌صورت پیش‌فرض فعال بود. دیگه نیازی به فلگ و کتابخونه اضافی نیست.نتیجه، چیزیه که هر کسی که این ۳۱ سال با این زبونِ پرحاشیه زندگی کرده، حسرتش رو داشته!💡 چیزی که این داستان یادم می‌اندازهمن سال‌هاست درباره‌ی فاصله‌ی بین «مهارت فنی» و «ownership» زیاد نوشتم، صحبت کردم و تلاش کردم توی مسیر رشد دیگران قرار بدم. این داستان، دقیقاً همون فاصله رو نشون می‌ده، اما در سطح یک اکوسیستم کامل. تصمیم Brendan Eich در ۱۹۹۵ نه غیرمنطقی بود و نه بی‌کفایتی؛ او ده روز وقت داشت. مشکل واقعی جای دیگه‌ای بود: این بدهی فنی برای دو دهه به رسمیت شناخته می‌شد، دورش مستندسازی و کتابخونه ساخته می‌شد، ولی هیچ گروه مشخصی مسئولیت حل ریشه‌ای‌اش رو عهده نمی‌گرفتن! تا اینکه یک گفتگوی غیررسمی، افراد درست رو در یک اتاق (یا یک رشتو توییتری) کنار هم گذاشت.نکته برای من این نیست که «یک نفر جسور مشکل بیست‌سی‌ساله‌ی یه زبون رو حل کرد». نکته اینه که حل بدهی فنی بزرگ، همیشه به یک لحظهٔ شروع کوچیک نیاز داره. یک نفر که تصمیم می‌گیره به‌جای دورزدن مشکل، درباره‌ی ریشه‌اش صحبت کنه. بعدش کار سخت، یعنی ۹ سال طراحی دقیق و صبورانه، شروع می‌شه. و اون بخش، هیچ‌وقت کار یک نفر نیست.پی‌نوشت: این بخش کوچکی از یه ارائه مفصل چند جلسه‌ای برای گروهی از تازه لیدِ فنی شده‌های یه سازمان بزرگ بود؛ گاهی برای یادگیری؛ مثال و داستان بهتر از شمردن نکته‌ها و تیترهاییه که یا سریع از خاطر می‌رن یا تبدیل می‌شن به لقلقه زبون آدم‌ها برای شوآف. اگر دوست داشتید؛ PostgreSQL یا MongoDB یا داستان Mel و Monorail و... هر کدوم مثل حکایت‌های کلیله و دمنه یا بوستان سعدی هستن (البته در مثال محل مناقشه نیست) که در قالب یه قصه میشه ده‌ها صفحه درس و نکته رو یاد گرفت. علاقه‌مند بودید لابلای وبلاگ پدیدآورنده‌ها و ردیت و توییتر، داستان‌های جذابی پیدا می‌شه. یا سری مصاحبه‌های Ryan Peterman یا داستان‌های Dave Plummerپی‌نوشت۲: احتمالا مطلب بعدی یا A2UI خواهد بود یا در مورد روش‌های ارزیابی عملکرد دوره‌ای تیم‌های فنی. اگر پیشنهاد یا نکته‌ای دارید حتمن کامنت کنید :)