مرزهای توانایی

اولین مرز، و ضدشهودی‌ترین‌شان: روی حساب‌وکتاب دقیق نمی‌شود بی‌بررسی حساب کرد.

چرا؟ برگرد به فصل ۱.۱. مدل عدد را محاسبه نمی‌کند — محتمل‌ترین ادامه را پیش‌بینی می‌کند. و «۳۸۴۷ ضربدر ۲۹» یک الگوی کم‌تکرار است، پس عددی که می‌آید شبیه جواب است، نه لزوماً جواب.

و خطرش این است که این نوع خطا باورپذیر است: تعداد رقم‌ها درست است، بزرگی عدد منطقی است. فقط غلط است.

راه‌حل: نگذار خودش حساب کند — بگذار ابزار حساب کند. اگر بخواهی محاسبه را در یک فایل یا با یک محاسبه‌گر انجام دهد، جوابش دقیق است، چون آن‌وقت واقعاً محاسبه شده. این همان تفاوت فصل ۱.۲ است: مدل تصمیم می‌گیرد، ابزار اجرا می‌کند.

پس قاعده: هر عددی که مهم است، یا با ابزار حساب شود یا نمونه‌اش دستی چک شود.

مرز دوم از فصل ۱.۳ می‌آید: پنجره‌ی context سقف دارد، و مهم‌تر — خیلی قبل از پرشدنِ سقف، دقت افت می‌کند (همان context rot).

پس چه اتفاقی می‌افتد وقتی یک سند دویست‌صفحه‌ای می‌دهی؟ دو حالت:

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

نشانه‌ی عملی‌اش: چیزی را که در وسط سند بود نادیده می‌گیرد، درحالی‌که اول و آخر را خوب می‌بیند.

راه‌حل: بشکنش. به‌جای «این کتاب را خلاصه کن»، فصل‌به‌فصل خلاصه کن و بعد خلاصه‌ها را جمع کن. همان شکستنِ فصل ۲.۵، این بار برای صرفه‌ی context (فصل ۲.۷.۵).

مرز سوم شبیه دومی است ولی یک تفاوت مهم دارد.

اگر یک فایل با پنجاه‌هزار ردیف بدهی و بگویی «جمعش را بده»، دو راه هست و باید بدانی کدام را رفته:

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

به‌خاطر بسپار برای داده‌ی بزرگ، سؤال درست این نیست که «می‌تواند؟» — این است که «با ابزار حساب کرد یا خودش نگاه کرد؟» و راهِ فهمیدنش ساده است: بپرس. «چطور این عدد را حساب کردی؟»

ماژول ۸ کاملاً درباره‌ی همین است: ساختن ابزاری که داده را واقعاً پردازش کند.

مرز چهارم از knowledge cutoff فصل ۱.۱ می‌آید: داده‌ی آموزش یک تاریخ پایان دارد.

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

راه‌حل: اطلاعات را خودت بده، یا ابزاری که برایش جستجو کند. و اگر هیچ‌کدام نبود، آن سؤال را از او نپرس — برو سراغ منبع اصلی (درس ۲.۸).

و یک حالت خاص که در ایران زیاد پیش می‌آید: وضعیت دسترسی و قیمت سرویس‌ها. این‌ها هم فرّارند و هم محلی — دقیقاً همان چیزی که در فصل ۰.۷ گفتیم جایش یک بلوک با تاریخ است، نه حافظه‌ی مدل.

مرز پنجم از جنس دیگری است: اینجا مسئله توانایی نیست، جایگاه است.

وقتی سؤال این است که «کدام یکی مهم‌تر است»، جواب از داده درنمی‌آید — از ارزش‌ها درمی‌آید. مثلاً: به کدام مشتری اولویت بدهیم؟ این خبر را به تیم بگوییم یا نه؟ چقدر ریسک قابل‌قبول است؟

و نکته‌ی خطرناک: برای این سؤال‌ها هم جواب می‌دهد، با همان لحن مطمئن. جوابش می‌تواند مفید باشد به‌عنوان یک نظر — ولی سه چیز را ندارد که برای تصمیم لازم است:

• context سازمانی تو (فصل ۳.۲) — نمی‌داند در شرکت شما چه چیزی جواب می‌دهد.
• پیامد. اگر تصمیم غلط باشد، هزینه‌اش را تو می‌دهی.
• مسئولیت. اسم تو پای آن تصمیم است (درس ۵.۵).

پس استفاده‌ی درستش همان چیزی است که در فصل ۲.۳ ساختیم: مخالف‌خوانی، نه تصمیم‌گیری. بگذار ایده‌ات را بشکند؛ خودت تصمیم بگیر.

سه سؤال، قبل از شروع هر کار. اگر جوابِ هر سه «نه» بود، جلو برو:

1. جوابش یک عددِ دقیق است که کسی بررسی نمی‌کند؟ ← ابزار لازم دارد، نه پیش‌بینی.
2. به اطلاعاتی نیاز دارد که در دنیای بیرون است و من ندارمش؟ ← اول آن اطلاعات را تأمین کن.
3. جوابش «بستگی دارد به ارزش‌های ما» است؟ ← این کار سپردنی نیست. حداکثر مخالف‌خوانی.

و یک نکته‌ی مهم برای اینکه ناامید نشوی: این فهرست کوتاه است. بیرون این پنج مورد، طیف وسیعی از کارها هست که خوب جواب می‌دهند — و همه‌شان در ماژول ۸ ساخته می‌شوند.