نکات کلیدی

• هر مسئله در فضای هوش مصنوعی چالش‌های منحصربه‌فردی دارد. وقتی مدتی است ترافیک محیط عملیاتی (production traffic) را سرو می‌کنید، با حالت‌های لبه‌ای (edge cases) و سناریوهایی روبه‌رو می‌شوید که می‌خواهید آن‌ها را اندازه‌گیری کنید.
• مدل‌ها را به‌عنوان سیستم‌ها در نظر بگیرید: مدل‌های زبانی بزرگ (LLMها) بخشی از سیستم‌های بزرگ‌تر هستند. عملکرد و قابلیت اتکای آن‌ها نیازمند مشاهده‌پذیری (observability) دقیق، گاردریل‌ها (guardrails)، و هم‌راستاسازی با اهداف کاربر و کسب‌وکار است.
• متریک‌هایی بسازید که دربارهٔ مسائل کاربران هشدار بدهند و مطمئن شوید یک فرایند پاک‌سازی (cleanup) دارید تا متریک‌های قدیمی را از رده خارج کنید (phase out).
• روی جهت‌گیری کسب‌وکار تمرکز کنید. متریک‌هایی بسازید که با اهداف فعلی شما و درس‌هایی که در طول مسیر یاد گرفته‌اید هم‌راستا باشند.
• زیادی پیچیده‌اش نکنید. روش crawl, walk, run را اتخاذ کنید تا به‌صورت تدریجی متریک‌ها، زیرساخت، و بلوغ سیستم را توسعه دهید.

Denys Linkov سخنرانی «A Framework for Building Micro Metrics for LLM System Evaluation» را در QCon San Francisco ارائه داد. این مقاله نمایندهٔ آن سخنرانی است؛ سخنرانی‌ای که با توضیح چالش‌های دقت LLM شروع می‌کند و اینکه چگونه می‌توان میکرو‌متریک‌های LLM را ایجاد کرد، دنبال کرد (track)، و بازبینی کرد (revise) تا مدل‌های LLM بهبود پیدا کنند.

آیا تا به حال یک system prompt را تغییر داده‌اید و در نهایت باعث ایجاد مشکل در production شده‌اید؟ همهٔ تست‌ها را اجرا می‌کنید، و امیدوارید قبل از تغییر مدل‌هایتان ارزیابی‌ها را داشته باشید، و همه‌چیز پاس می‌شود. بعد اوضاع خوب پیش می‌رود تا وقتی که کسی در سرور Discord به شما ping می‌زند و می‌گوید همه‌چیز خراب است.

یک سناریوی واقعی که به ایدهٔ micrometrics منجر شد زمانی اتفاق افتاد که من system promptهای خودمان را در Voiceflow، یک پلتفرم ایجنت هوش مصنوعی (AI agent platform)، برای نحوهٔ تعامل‌مان با مدل‌ها تغییر دادم.
کسی داشت در حالی که با کاربر نهایی خودش گفتگو می‌کرد، یک مدل را به زبان آلمانی prompt می‌کرد. تا نوبت پنجم گفتگو، مدل ناگهان به زبان انگلیسی پاسخ داد. مشتری عصبانی بود و فکر می‌کرد چرا چت‌باتش بعد از اینکه تمام مدت آلمانی صحبت کرده، به انگلیسی تغییر زبان داده است. آن‌ها گیج شده بودند، و ما هم همین‌طور.

ساخت پلتفرم‌های LLM، یا هر نوع پلتفرمی، چالش‌برانگیز است.

چه چیزی یک پاسخ خوب از LLM می‌سازد؟

وقتی دارید یک اپلیکیشن LLM می‌سازید، چه چیزی یک پاسخ خوب از LLM می‌سازد؟ این یک سؤال نسبتاً فلسفی است، چون سخت است که مردم را به توافق برسانید که «خوب» یعنی چه.

LLMها جذاب‌اند اما گمراه‌کننده. حتی وقتی اشتباه می‌کنند هم قانع‌کننده به نظر می‌رسند. نه‌تنها مردم اغلب دربارهٔ اینکه چه چیزی خوب است اختلاف نظر دارند، بلکه گاهی حتی پاسخ‌ها را دقیق نمی‌خوانند. برای ارزیابی پاسخ‌ها، ممکن است از regex یا تطبیق دقیق (exact matches)، شباهت کسینوسی (cosine similarity) با golden datasetها، LLMها به‌عنوان داور (LLMs as judges)، یا متریک‌های سنتی علم داده استفاده کنید.

نقص‌های یک متریک

بیایید با چند درسی که یاد گرفته‌ام شروع کنیم. اولین مورد، نقص یک متریک واحد است. شباهت معنایی (semantic similarity) را در نظر بگیرید که با جست‌وجوی عبارت‌های مشابه، به RAG توان می‌دهد. این یک مثال است: من عبارت I like to eat potatoes را با سه عبارت و با استفاده از سه مدل مقایسه می‌کنم: جدیدترین مدل OpenAI و دو مدل متن‌بازِ با رتبهٔ بالا. می‌توانید حدس بزنید آن‌ها کدام عبارت را نزدیک‌ترین تطبیق تشخیص دادند؟

گزینه‌ها این‌ها هستند:

• I am a potato
• I am a human
• I am hungry

هر سه مدل I am a potato را انتخاب کردند. این یک پویایی عجیب ایجاد می‌کند. گفتن I like to eat potatoes و تطبیق دادنش با I am a potato نقص‌های مدل‌هایی را برجسته می‌کند که به شباهت کسینوسی یا شباهت معنایی تکیه دارند. در عمل، I am hungry یا حتی I am human منطقی‌تر است. متریک‌ها همیشه کار نمی‌کنند.

LLM به‌عنوان داور

بیایید دربارهٔ چالش‌های استفاده از LLMها به‌عنوان داور صحبت کنیم؛ یک رویهٔ رایج، به‌ویژه با GPT-4. بسیاری از افراد از LLMها برای ارزیابی پاسخ‌ها استفاده می‌کنند وقتی نمی‌خواهند آن‌ها را دستی مرور کنند. با این حال، این مدل‌ها سوگیری دارند. برای مثال، یک مقاله در سال ۲۰۲۳ نشان داد GPT-4 در promptهای کوتاه هم‌راستایی ضعیفی با قضاوت انسانی دارد، اما با promptهای طولانی بهتر عمل می‌کند. ما این سوگیری را از طریق چندین مطالعهٔ متفاوت دیده‌ایم. این مفهوم جالب است، چون این مدل‌ها به شکلی آموزش می‌بینند که برخی گرایش‌های انسانی یا برخی ترجیحات را تقلید کنند که ممکن است بعد از آموزش پدیدار شوند.

اما انسان‌ها چطور؟ آیا ما داورهای قابل اعتمادی هستیم؟ بیایید به آزمون‌های استاندارد نگاه کنیم. حدوداً نزدیک به ۲۰ سال پیش پژوهشی روی انشای SAT انجام شد که در آن پژوهشگر دریافت اگر فقط به طول انشا نگاه کنید، این معیار با نمره‌ای که ممتحن‌ها می‌دهند هم‌بستگی خیلی خوبی دارد. این یک سوگیری مشابه را در قضاوت انسانی آشکار می‌کند: ما متریک‌های سطحی مثل طول را در اولویت قرار می‌دهیم.

خوب بودن یعنی چه؟ چه کسی ترجیح می‌دهد یک ویدیوی یوتیوب دربارهٔ گربه‌ها ببیند یا دربارهٔ LLMها؟ یک مثال دیگر را در نظر بگیرید: ویدیوهای بچه‌گربه در برابر یک سخنرانی Karpathy. ویدیوهای گربه ۳۶ میلیون بازدید گرفتند در حالی که سخنرانی ۴ میلیون بازدید داشت. ما می‌گوییم: «گربه‌ها بهتر از LLMها هستند. واضح است، پس باید فقط محتوای گربه به مردم سرو کنیم». شبکه‌های اجتماعی شاید همین را فکر کنند، اما این مثال محدودیت‌های متریک‌هایی مثل بازدید یا دقت را نشان می‌دهد. این سنجه‌ها، به‌تنهایی، معیوب‌اند. احتمالاً با استدلال خودتان هم می‌توانید به این نتیجه برسید.

اگر دربارهٔ اینکه چطور به مردم دستورالعمل می‌دهیم صحبت کنیم، معمولاً برای بعضی کارها دستورالعمل‌های خیلی مشخص می‌دهیم، اما برای بعضی کارهای دیگر دستورالعمل‌های مبهم‌تر. برای مثال، وقتی من در McDonald’s کار می‌کردم (یک تجربهٔ واقعاً شخصیت‌ساز)، دستورالعمل‌های پختن chicken nuggetها فوق‌العاده دقیق بود. دفترچه دقیقاً زمان پخت را مشخص می‌کرد، و اگر nuggetها را سر وقت بالا نمی‌آوردید، بوق‌ها به صدا درمی‌آمدند. اما بعد کارهایی مثل «mop the floor» وجود داشت، که دستورالعمل‌هایش مبهم بود. اگر قبلاً تی نکشیده بودید، یا یک سؤال پیگیری می‌پرسیدید یا ریسک می‌کردید خراب‌کاری کنید. چیزهایی هم بین این دو وجود دارند.

این مثال‌ها ابهام دستورالعمل‌ها در زمینه‌های انسانی را برجسته می‌کنند. بعضی دقیق‌اند، بعضی مبهم‌اند، و بسیاری جایی بین این دو قرار می‌گیرند.

وقتی performance review انجام می‌دهیم، مهم است بازخورد مشخص بدهیم. این چیزی است که احتمالاً در بسیاری از صحبت‌های مهندسی دربارهٔ مدیریت تیم‌های خوب شنیده‌ایم. در McDonald’s، برای مثال، performance review شامل سؤال‌هایی مثل این بود: «چند تا swirl روی بستنی قیفی می‌گذاری؟» من همیشه بابت swirlهای زیاد به دردسر می‌افتادم، احتمالاً به همین خاطر بود که دستگاه مدام خراب می‌شد. همین است که هست.

بازخورد اغلب مشخص بود، اما گاهی نبود. متریک‌ها برای LLMها می‌توانند حس مشابهی داشته باشند، نه چون LLMها انسان هستند، بلکه چون چارچوب ارائهٔ بازخورد به همان شکل کار می‌کند. بازخورد مبهم مثل «تو عالی هستی» در یک performance review کمک‌کننده نیست. قرار است با آن چه کار کنید؟ برای LLMها هم همین است. اگر کسی بگوید: «یک hallucination رخ داد»، من این‌طور می‌شوم: «عالی. قرار است با این اطلاعات چه کار کنم؟»

مدل‌ها به‌عنوان سیستم‌ها

بیایید دربارهٔ مدل‌ها به‌عنوان سیستم‌ها صحبت کنیم. اگر کار مشاهده‌پذیری انجام داده باشید (مثلاً نوشتن متریک‌ها، تریس‌ها، و لاگ‌ها)، از قبل اهمیت پایش (monitoring) را می‌دانید. همین موضوع برای سیستم‌های مدل زبانی بزرگ هم صدق می‌کند. نمی‌توانید فقط یک مدل را مستقر (deploy) کنید، چشم‌هایتان را ببندید، و فرار کنید. این رویکرد تضمین می‌کند روز بدی خواهید داشت وقتی برایتان page می‌آید. مشاهده‌پذیری شامل سه نوع رویداد اصلی است: logs، metrics و traces.

• Logs: چه اتفاقی افتاد؟
• Metrics: چه مقدار از آن اتفاق افتاد؟
• Traces: چرا اتفاق افتاد؟

این‌ها از کم‌ریزترین (metrics) تا بسیار پرجزئیات (traces) طیف دارند. برای LLMها، متریک‌ها می‌توانند روی حوزه‌هایی مثل افت کیفیت مدل (model degradation) و پالایش محتوا (content moderation) تمرکز کنند. برای افت کیفیت مدل، متریک‌هایی مثل latency می‌توانند به‌سرعت مشکل را در یک ارائه‌دهنده (provider) یا نقطهٔ inference شناسایی کنند. امتیازدهی به پاسخ‌های مدل زمان بیشتری می‌برد (ثانیه‌ها یا حتی دقیقه‌ها). کارهای آفلاین مثل انتخاب بهترین مدل ممکن است هفته‌ها یا حتی ماه‌ها در یک محیط سازمانی (enterprise setting) طول بکشد.

برای پالایش محتوا، متریک‌ها باید در زمان واقعی (real time) کار کنند. اگر با یک حملهٔ اسپم روبه‌رو هستید، یک batch job در هفتهٔ بعد کمکی نمی‌کند. باید هدف متریک‌تان را مشخص کنید، اینکه چقدر latency خواهد بود، و اینکه در ادامه چگونه یک اقدام (action) را تعریف می‌کنید.

بیایید با تقسیم اپلیکیشن‌ها به دسته‌های real-time و async، عمیق‌تر وارد متریک‌ها شویم:

• متریک‌های real-time برای شناسایی مسائل فوری مثل افت کیفیت مدل، timeout شدن رویدادها، یا برگرداندن خروجی مزخرف توسط مدل حیاتی‌اند.
• متریک‌های async برای کارهایی مثل انتخاب مدل هستند، که ممکن است شامل اجرای ارزیابی‌ها یا حتی بحث‌های فلسفی شود.
• گاردریل‌ها می‌توانند هم در حالت real-time و هم در حالت async کار کنند، بسته به موقعیت.

شما می‌توانید یک میلیون متریک بسازید، و می‌توانید همهٔ آن‌ها را تعریف کنید، اما در نهایت، متریک‌های شما باید به تصمیم‌های کسب‌وکاری یا تصمیم‌های فنی برای سه ماه آینده کمک کنند. ما دربارهٔ این در یک معنای ریاضی صحبت می‌کنیم، به‌عنوان یک قیاس که متریک‌ها باید به شما اندازه (magnitude) و جهت (direction) بدهند.

متریک‌هایی بسازید که دربارهٔ مشکلات کاربران هشدار بدهند

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

برگردیم به مثال قبلی دربارهٔ پاسخ دادن LLM من به زبان اشتباه. یک کاربر مشکل را علامت زد (flagged)، و ما آن را قبل از اینکه روی مشتریان سازمانی اثر بگذارد تأیید کردیم. در حالی که بازتولید مشکل واقعاً سخت بود، یک مورد در لاگ‌ها پیدا کردیم که پاسخ اشتباه را نشان می‌داد. برای رسیدگی، یک گاردریل اضافه کردیم، یک مانیتور که زبان پاسخ را در حد میلی‌ثانیه بررسی می‌کرد و اگر عدم تطابق را تشخیص می‌داد، دوباره تلاش می‌کرد (retry). این رویکرد آنلاین بهتر از این بود که مشکل را برای اقدام بعدی ذخیره کنیم.

وقتی تصمیم می‌گیرید متریک‌ها را آنلاین یا آفلاین مدیریت کنید (همگام در برابر ناهمگام)، بستگی به use case دارد. برای مثال، در پالایش محتوا، ممکن است ورودی نامناسب را در زمان واقعی علامت بزنید یا نادیده بگیرید. همیشه ارزیابی کنید که یک متریک چگونه روی کسب‌وکار شما اثر می‌گذارد، با فکر کردن به سناریو و سنجیدن پیامدها.

وقتی محصول می‌سازید، چه داخلی چه خارجی، می‌خواهید اعتماد مشتریان‌تان را به دست آورید. اول، به محصولی نیاز دارید که کار کند، دست‌کم گاهی. بعد، می‌خواهید مشتریان‌تان را خوشحال کنید، کلاسیکِ sales 101. اعتماد مشتری مثل یک جزیره است. تا وقتی محصول شما کار می‌کند و مردم دارند می‌خرند، روی زمین محکم هستید.

وقتی چیزها خراب می‌شوند، مثل پاسخ دادن مدل به زبان اشتباه، اعتماد را از دست می‌دهید. مشتریان شما عصبانی‌اند چون مشتریانِ آن‌ها دارند شکایت می‌کنند. قدم‌هایی هست که می‌توانید بردارید: refund ارائه کنید تا ناراحتی را جبران کنید، یک اصلاح (fix) مثل auto-retry پیاده‌سازی کنید، و یک تحلیل علت ریشه‌ای (root cause analysis یا RCA) بنویسید تا توضیح دهید چه چیزی اشتباه شد و چگونه حل شده است. اینکه آیا این شما را به جزیرهٔ اعتماد مشتری برمی‌گرداند یا نه به مشتری شما بستگی دارد، اما هدف همیشه بازسازی اعتماد با اطمینان از این است که محصول شما طبق انتظار کار می‌کند.

هرچه سامانه‌هایی که می‌سازید پیچیده‌تر باشند، مشاهده‌پذیری هم پیچیده‌تر است. یک پایپ‌لاین LLM بسیار پیچیده با همهٔ تکنیک‌های جدید، مثل RAG، سخت‌تر برای دیباگ و پایش است. شکستن RAG به دو مؤلفه (retrieval و generation) می‌تواند کار را ساده کند. برای retrieval، روی ارائهٔ context درست تمرکز کنید: مطمئن شوید اطلاعات مرتبط است و از جزئیات غیرضروری که می‌تواند به فرایند generation آسیب بزند اجتناب می‌کند، و اگر rankingها مشخص‌اند، بین precision و recall تعادل برقرار کنید. برای generation، متریک‌ها ممکن است شامل فرمت درست، پاسخ‌های دقیق، و جلوگیری از اطلاعات اضافه باشند. همچنین می‌توانید این را با سنجه‌هایی مثل دقت، طول مناسب، persona درست، یا حتی قوانین مشخص مثل اینکه مطمئن شوید LLM کلمهٔ “delve” را نگوید دقیق‌تر کنید. مؤلفه‌های متعدد RAG یعنی متریک‌های متفاوت برای بخش‌های متفاوت.

روی متریک‌های کسب‌وکار تمرکز کنید

تا الآن احتمالاً به چند متریک برای use case خودتان فکر کرده‌اید، اما در نهایت، آن‌ها باید ارزش کسب‌وکاری ایجاد کنند. برای مثال، هزینهٔ یک پاسخ not-safe-for-work از LLM شما چقدر است؟ کسب‌وکار هر کسی متفاوت است. بسته به اینکه به چه کسی می‌فروشید، بسته به context، همه‌چیز متفاوت خواهد بود. تیم کسب‌وکار شما باید این هزینه‌ها را تعیین کند. به همین شکل، اگر دارید یک LLM حقوقی می‌سازید و آن توصیهٔ بد می‌دهد (مثل پیشنهاد اینکه کسی «برود از همسایه‌اش شکایت کند»)، این یک مسئلهٔ جدی است. باید این اشتباه‌ها را به زبان دلار محاسبه کنید و تصمیم بگیرید چقدر روی متریک‌ها سرمایه‌گذاری کنید، چقدر بیشتر برای safeguardها پول بدهید، یا چقدر latency را برای بررسی‌های آنلاین تحمل کنید. برای مثال، هزینهٔ یک ترجمهٔ بد در سناریوی قبلی ما چقدر است؟

دلیل اینکه در نهایت متریک می‌سازیم و از LLM استفاده می‌کنیم این است که زمان انسان را ذخیره کنیم. تمام اتوماسیون و تمام اپلیکیشن‌های شیک و جدید دربارهٔ ذخیره کردن زمان است. مگر اینکه دارید یک اپ شبکهٔ اجتماعی می‌سازید، که هدفش این است مردم را تا جای ممکن درگیر نگه دارد. ممکن است فکر کنید: «من کسب‌وکار را کامل نمی‌دانم. این کار من نیست. من یک توسعه‌دهنده‌ام. من کد می‌نویسم». اول، نه. کسب‌وکار را بفهمید. بدانید چه می‌سازید و چه مسئله‌ای را حل می‌کنید. دوم، منصفانه است که انتظار داشته باشید تیم کسب‌وکار اینجا بیشتر کار را انجام دهد، بالاخره این شغل آن‌هاست.

تیم کسب‌وکار باید use caseها را تعریف کند، توضیح دهد ویژگی‌ها چگونه با محصول یکپارچه می‌شوند، ROI را اندازه بگیرد، و مدل درست را انتخاب کند. در حالی که شما باید بخشی از این گفتگوها باشید، متریک‌ها فقط یک مسئولیت فنی نیستند. در دنیای LLMها، جایی که این مدل‌ها در محصولات متنوعی جاسازی شده‌اند، تیم کسب‌وکار باید وقت بگذارد تا تعریف کند چه متریک‌هایی برای محصول شما معنا دارند.

مطمئن شوید متریک‌های شما با اهداف فعلی‌تان و درس‌هایی که در مسیر یاد گرفته‌اید هم‌راستا هستند. هنگام لانچ یک اپلیکیشن LLM، شما به‌ناچار چیزهای زیادی یاد می‌گیرید. مطمئن شوید یک فرایند پاک‌سازی دارید تا متریک‌های منسوخ را از رده خارج کنید.

Crawl, Walk, Run

در نهایت، چند نکتهٔ عملی‌تر اینجا هست. همین اول کار داخل قسمت عمیق نپرید. با یک رویکرد crawl, walk, run شروع کنید. این دربارهٔ متریک‌ها هم صدق می‌کند. با درک کامل use caseها شروع کنید و مطمئن شوید تیم‌های فنی شما هم‌راستا هستند. این به‌طور کلی روشی است که من برای اندازه‌گیری هر نوع بلوغ LLM و بلوغ متریک‌های LLM به آن فکر می‌کنم.

با شروع از مرحلهٔ crawl، پیش‌نیازهای متفاوتی قبل از پیاده‌سازی این متریک‌ها وجود دارد. باید بدانید چه می‌سازید و چرا می‌سازید. می‌خواهید datasetهایی برای ارزیابی‌ها داشته باشید. اگر ندارید، وقت بگذارید و چندتا بسازید. همچنین به معیارهای امتیازدهی پایه و logging نیاز دارید. این اجازه می‌دهد سامانه‌تان را دنبال کنید، بفهمید چه رخ می‌دهد، و تعیین کنید چه چیزی عموماً درست یا غلط است. چند متریک نمونه برای شروع می‌تواند moderation یا یک متریک دقت مبتنی بر datasetهای ارزیابی باشد. باز هم، این متریک‌ها ممکن است کامل نباشند، اما جای شروع خوبی هستند.

در مرحلهٔ walk، باید درک محکمی از چالش‌های سامانه‌تان داشته باشید، از جمله اینکه ضعف‌ها کجا هستند، چه چیزی کار می‌کند، و چه چیزی کار نمی‌کند. تا اینجا باید یک فرضیهٔ روشن داشته باشید دربارهٔ اینکه چطور این مشکلات را حل کنید یا دست‌کم چطور بیشتر بررسی‌شان کنید. باید یک حلقهٔ بازخورد (feedback loop) وجود داشته باشد تا فرضیه را تست کنید، بازخورد جمع کنید (چه از طریق logها چه دادهٔ کاربران)، و به این نگرانی‌ها بپردازید. ایده‌آل این است که قبلاً تلاش‌هایی با متریک‌های پایه کرده‌اید، و حالا وقت دقیق‌تر شدن است. برای نمونه، ممکن است متریک‌های recall مثل net discounted cumulative gain را اضافه کنید، یا answer consistency برای بهینه‌سازی تنظیماتی مثل temperature و سنجش tradeoffها، یا می‌توانید language detection انجام دهید. این متریک‌های دقیق‌تر کمی زیرساخت بیشتر می‌خواهند تا مؤثر پیاده‌سازی شوند.

در مرحلهٔ run، باید روی صحنه باشید و دربارهٔ کارهای خفنی که می‌کنید صحبت کنید. مقدار زیادی اتوماسیون خوب برای چیزهایی که in-house ساخته‌اید دارید، مثل auto prompt tuning، و متریک‌های شما با اهداف مشخص هم‌راستا هستند. احتمالاً دادهٔ باکیفیت زیادی دارید که می‌تواند برای fine-tuning استفاده شود، هرچند همچنان یک تصمیم کسب‌وکاری است. در این سطح، متریک‌های شما هر چیزی هستند که می‌خواهید باشند. شما سامانه و محصول‌تان را می‌فهمید، و می‌توانید بفهمید micro metrics چه هستند.

خلاصه

ما پنج درس کلیدی را پوشش دادیم. متریک‌های تکی می‌توانند معیوب باشند. امیدوارم مثال‌های سیب‌زمینی من این را روشن کرده باشد. مدل‌ها فقط LLMهای مستقل نیستند؛ آن‌ها بخشی از سیستم‌های گسترده‌تر هستند، به‌خصوص وقتی پیچیدگی با ویژگی‌هایی مثل RAG، استفاده از ابزار (tool use)، یا یکپارچه‌سازی‌های دیگر رشد می‌کند. مهم است متریک‌هایی بسازید که دربارهٔ مشکلات کاربران به شما هشدار دهند، با تمرکز روی چیزی که روی محصول شما اثر می‌گذارد و با اهداف کسب‌وکاری شما هم‌راستا است.

وقتی محصولات را با LLMها بهبود می‌دهید، ساده نگهش دارید. روش crawl, walk, run را دنبال کنید. بدترین کاری که می‌توانید بکنید این است که خودتان را با داشبوردهایی پر از ۲۰ متریک که هیچ اقدامی را جلو نمی‌برند overload کنید. زیادی پیچیده‌اش نکنید: روش crawl, walk, run را طی کنید.