مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی
Software Engineer, AI Observability & Evals
«مهندس مشاهده‌پذیری هوش مصنوعی» (AI Observability Engineer) عنوان شغلی نیست: در بررسی ما در ۲۲ اکتبر ۲۰۲۶ روی ۳۷٬۹۱۸ آگهی باز در تابلوی استخدام ۴۲۹ شرکت، هیچ آگهی‌ای این عنوان را نداشت، و سه آگهی هم‌نامی که در سایت‌های کاریابی پیدا کردیم همه بسته شده بودند. خودِ کار اما واقعی است و کارفرماها آن را با عنوان‌هایی مثل Software Engineer, AI Observability & Evals Platform (در LangChain، سازندهٔ LangSmith)، Senior Software Engineer - Agent Observability (در Honeycomb)، Staff AI Engineer - Agent Observability (در Datadog)، Manager, Software Engineering - AI Observability (در Figma) و Software Engineer, Evals (در Glean و xAI) آگهی می‌کنند. این مهندس سیستمی می‌سازد که نشان می‌دهد یک محصول مبتنی بر LLM یا ایجنت در پروداکشن واقعاً چه می‌کند: trace هر فراخوانی مدل و ابزار، مصرف توکن و هزینه، خطاها، و ارزیابی خودکار (eval) کیفیت پاسخ پیش و پس از هر تغییر. هستهٔ کار مهندسی نرم‌افزار backend و داده است، نه نوشتن prompt.
مقدمه و تعریف شغل
این مهندس سیستم‌هایی می‌سازد که رفتار برنامه‌های مبتنی بر LLM و ایجنت را قابل دیدن و قابل اندازه‌گیری می‌کنند. دو نیمهٔ کار به هم وصل‌اند. نیمهٔ اول observability است: ثبت trace هر فراخوانی مدل، ابزار و بازیابی، و نشان دادن هزینه، مصرف توکن، تأخیر و خطا. نیمهٔ دوم ارزیابی است؛ به تعریف Anthropic، «eval آزمونی برای یک سیستم AI است»: کارهایی با ورودی و معیار موفقیت مشخص، و یک grader که بخشی از عملکرد را نمره می‌دهد. تیم Evals & Observability در Glean هر دو را با هم دارد: pipeline ارزیابی، evalset های کیفیت، داوری با LLM و observability ایجنت. کار این مهندس هم می‌تواند ساختن همین ابزارها به‌عنوان محصول باشد (LangChain، Honeycomb، Datadog) و هم ساختنشان برای محصول AI خود شرکت (Glean، Figma، Reddit).
observability پیش از LLM ها رشته‌ای جاافتاده بود؛ طبق ویکی‌پدیا، Honeycomb در ۲۰۱۶ برای debug نرم‌افزار در حال اجرا ساخته شد، و OpenTelemetry چارچوبی متن‌باز و مستقل از فروشنده برای تولید و ارسال traces، metrics و logs است. LLM ها دو مسئلهٔ تازه آوردند: خروجی قطعی نیست، و درست بودن پاسخ را با CPU و تأخیر نمی‌شود سنجید. برای همین ابزارهایی مثل LangSmith، Langfuse و Arize Phoenix ساخته شدند و فروشندگان قدیمی‌تر هم تیم جدا راه انداختند: Datadog و Honeycomb هر دو تیم Agent Observability دارند. در شرکت‌هایی که از این ابزارها استفاده می‌کنند، کار تازه در حال شکل‌گیری است؛ Figma در آگهی‌اش می‌نویسد observability تا همین اواخر در این شرکت «مالک نداشت». در بیشتر شرکت‌ها هم این کار عنوان جدا ندارد و جزو وظایف AI Engineer یا ML Engineer است: در بررسی ما، LangSmith بیرون از خود LangChain در ۲۶ آگهی از ۱۸ شرکت نام برده شده بود، با عنوان‌هایی مثل AI Engineer، Machine Learning Engineer و Software Engineer.
چه چیزی می‌سازید؟
مثال‌های واقعی از خروجی کار یک مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی
pipeline تلمتری برای ویژگی‌های AI
Figma تیمی دارد که pipeline تلمتری «با حفظ حریم خصوصی» می‌سازد: trace، گفتگو و دادهٔ مدل را جمع می‌کند، دسته‌بندی می‌کند و به تیم‌ها اجازه می‌دهد با eval کیفیت ویژگی‌های AI را بسنجند و بهتر کنند.
pipeline ارزیابی در مقیاس
Glean pipeline هایی می‌خواهد که کیفیت دستیار و ایجنت‌هایش را روی هزاران کار واقعی و مصنوعی بسنجند و نسخه‌های تازهٔ مدل‌های پیشرو و متن‌باز را پیش از رسیدن به مشتری ارزیابی کنند.
نمای هزینه، توکن و خطای ایجنت
تیم Agent Observability در Honeycomb سیستم‌هایی می‌سازد که سیگنال‌های مخصوص AI مثل هزینه، مصرف توکن، خطا و ناهنجاری را تحلیل و نمایش می‌دهند و گفتگوی تک‌تک کاربران را برای debug باز می‌کنند.
harness ارزیابی و بهینه‌سازی ایجنت
Reddit برای ایجنت‌های کدنویسی داخلی‌اش سیستمی می‌خواهد با replay آفلاین، ارزیابی خودکار، تولید کار مصنوعی، تشخیص regression و بازخورد انسانی، و مسیریابی مدل بر اساس کیفیت، تأخیر و هزینه.
gate انتشار
در Mercor این نقش مالک gate هایی است که تصمیم می‌گیرند یک تغییر ایجنت منتشر شود یا نه، و Perplexity gate های regression و سیگنال آمادگی انتشار را برای تغییر مدل، ابزار و harness می‌خواهد.
backend یک پلتفرم observability
مهندس backend در LangChain سرویس‌ها و API های tracing، پایش و ارزیابی LangSmith را می‌سازد و ذخیره و پرس‌وجوی حجم بالای دادهٔ observability و eval را بهینه می‌کند.
تخصص‌های مختلف مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی
این شغل یک عنوان واحد نیست — مسیرهای تخصصی متعددی دارد
مهندس محصول در شرکت‌های observability
AI Observability Product Engineer
ساختن خودِ ابزار برای مشتری: ingestion، مدل داده، نمایش trace و گفتگو و ویژگی‌های ارزیابی. LangChain (LangSmith)، Honeycomb و Datadog نمونه‌های این مسیرند و معمولاً مهارت full-stack می‌خواهند.
پلتفرم داخلی eval و observability
In-house Evals & Observability Platform
ساختن ابزار اندازه‌گیری برای تیم‌های محصول همان شرکت: pipeline ارزیابی، evalset، داور LLM و observability ایجنت، مثل Glean و Figma.
ارزیابی و بهینه‌سازی ایجنت
Agent Evaluation & Optimization
ساختن محیط ارزیابی، verifier و grader روی مسیر اجرای ایجنت و مسیریابی مدل بر اساس کیفیت و هزینه؛ مثل Reddit، Perplexity و Mercor.
زیرساخت ارزیابی مدل در آزمایشگاه‌های AI
Model Evaluation Infrastructure
پلتفرم ساختن، اجرا و تحلیل eval برای پژوهشگرانی که مدل آموزش می‌دهند، با نسخه‌بندی و تکرارپذیری نتایج؛ مثل Thinking Machines Lab و تیم evals در xAI. به پژوهش نزدیک‌تر است.
کیفیت AI و پایش مدل
AI Quality & Model Monitoring
سنجیدن کیفیت خروجی مدل‌ها و drift در طول زمان، اغلب برای مدل‌های اختصاصی خود شرکت؛ مثل تیم AI Quality در WHOOP. ابزارهایی مثل Evidently در این بخش رایج‌اند.
تفاوت با شغل‌های مشابه
کجا این شغل تمام می‌شود و شغل دیگری شروع می‌شود؟
نزدیک‌ترین نقش است و هم‌پوشانی زیاد دارد. آگهی LLMops Engineer در Coursera پایش تأخیر، مصرف توکن، هزینهٔ هر درخواست، کیفیت خروجی و drift، و ارزیابی خودکار را هم جزو کار آورده، اما در کنارش نسخه‌بندی prompt و pipeline، CI/CD، نگهداری RAG و مدیریت هزینه با caching و مسیریابی مدل را. مهندس LLMOps کل عملیات را اداره می‌کند؛ مهندس observability و eval روی لایهٔ اندازه‌گیری عمیق می‌شود، یا در شرکتی مثل LangChain و Honeycomb خودِ ابزار اندازه‌گیری را به‌عنوان محصول می‌سازد. در تیم‌های کوچک یک نفر هر دو کار را می‌کند.
SRE می‌پرسد سرویس در دسترس و سریع است یا نه: SLO، تأخیر، ظرفیت GPU، on-call و حادثه. مهندس observability و eval می‌پرسد پاسخ درست و ارزان بوده یا نه: کیفیت، هزینهٔ هر گفتگو، انتخاب ابزار و regression پس از تغییر مدل. ابزارهای پایه مشترک‌اند و مرز نرم است: تیم Figma هم مالک stack کلاسیک metrics، logs و traces شرکت است و هم pipeline observability هوش مصنوعی. observability خوشه‌های GPU، مثل آگهی‌های CoreWeave و Firmus، به صفحهٔ AI SRE نزدیک‌تر است.
MLOps چرخهٔ عمر مدل‌هایی را اداره می‌کند که خود شرکت آموزش می‌دهد: داده، آموزش، رجیستری، استقرار و پایش drift. پایش کیفیت مدل در هر دو نقش هست؛ تیم AI Quality در WHOOP چارچوب تست برای drift و عملکرد مدل می‌خواهد و تیم Datadog هم drift detection را کنار ارزیابی مدل آورده است. فرق در موضوع اندازه‌گیری است: در برنامه‌های LLM بیشتر با مدلی کار می‌کنید که خودتان آموزش نداده‌اید، و آنچه باید سنجیده شود گفتگو، مسیر اجرای ایجنت و کیفیت پاسخ است.
مهندس هوش مصنوعی ویژگی و ایجنت محصول را می‌سازد و در بیشتر شرکت‌ها eval و tracing همان ویژگی را هم خودش می‌نویسد؛ SoFi از مهندس AI ارشدش طراحی راهکارهای observability با ابزارهایی مثل LangSmith و Arize را می‌خواهد. وقتی محصول بزرگ می‌شود، این کار به تیم جدا می‌رود که برای همهٔ تیم‌ها ابزار و استاندارد می‌سازد، مثل تیم Evals & Observability در Glean. برای خیلی‌ها مسیر ورود به این شغل همین است.
تأثیر در صنایع مختلف
مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی در همه صنایع مشغول به کار است — نه فقط شرکت‌های فناوری
مالی و بانکداری
SoFi از مهندس AI ارشدش راهکارهای observability و چارچوب‌های tracing و تست می‌خواهد که کیفیت، انطباق با مقررات و قابلیت اطمینان در پروداکشن را تضمین کنند.
حقوقی
تیم AI Platform در Harvey سیستم‌های ارزیابی، تست و پایش می‌سازد تا تیم‌ها کیفیت را بسنجند، regression را بگیرند و ویژگی‌های AI را با اطمینان منتشر کنند.
رستوران و پرداخت
تیم پلتفرم داخلی AI در Toast، کنار LLM Proxy و مدیریت کلید، pipeline های observability می‌سازد و آشنایی با Langfuse یا Datadog را می‌خواهد.
بازاریابی و پشتیبانی مشتری
تیم Customer Agent در Klaviyo، که ایجنت گفتگو برای پاسخ به مشتریان برندها می‌سازد، سابقه با سیستم‌های ارزیابی پروداکشن و observability هوش مصنوعی را می‌خواهد.
جستجو و دستیار سازمانی
Glean تیم جدا برای eval و observability دارد که تصمیم می‌گیرد مدل، prompt، روش بازیابی یا workflow تازهٔ ایجنت آمادهٔ انتشار برای مشتری سازمانی هست یا نه.
ابزار طراحی
Figma pipeline observability هوش مصنوعی را برای بهتر کردن قابل‌اندازه‌گیری ویژگی‌های AI خود می‌سازد و همان تیم مالک observability کل شرکت است.
داده و ابر
تیم Cortex Quality در Snowflake برای ایجنت‌های کدنویسی داده harness ارزیابی می‌سازد و از مسیر اجرای واقعی ایجنت‌ها خطا پیدا می‌کند.
سلامت و ابزار پوشیدنی
تیم AI Quality در WHOOP مسئول قابلیت اطمینان و عملکرد مدل‌هایی است که تحلیل‌های سلامت کاربران را می‌سازند و برای drift و عملکرد مدل چارچوب تست می‌خواهد.
تصورات غلط رایج
قبل از تصمیم‌گیری، این باورهای اشتباه را بشناسید
observability یعنی ساختن داشبورد
داشبورد آخرین لایه است. Honeycomb کار را «از ingestion تا نمایش در محصول» تعریف می‌کند و Glean از این نقش می‌خواهد نگران باشد که معیارها «تجربهٔ واقعی کاربر را نشان دهند، نه اینکه فقط داشبورد خوب به نظر برسد». بیشتر وقت صرف مدل داده، pipeline و درست بودن معیارها می‌شود.
ارزیابی کار پژوهشگران است
بخش بزرگی از آگهی‌های eval در شرکت‌های محصول است، نه آزمایشگاه پژوهشی: Glean، Reddit، Perplexity و Snowflake. Hamel Husain می‌نویسد محصولات ناموفق AI تقریباً همیشه یک ریشهٔ مشترک دارند: نساختن سیستم ارزیابی محکم.
یک LLM-as-a-Judge مسئلهٔ ارزیابی را حل می‌کند
به نوشتهٔ Anthropic، grader مبتنی بر مدل غیرقطعی است و برای دقت باید با grader انسانی کالیبره شود. راهنمای Hamel Husain هم داور LLM را فقط پس از سنجیدن با برچسب انسانی معتبر می‌داند، و Perplexity grader هایش را «کالیبره‌شده با قضاوت انسانی» می‌خواهد.
این همان SRE با اسم جدید است
ابزارها مشترک‌اند، سؤال فرق دارد. SRE دسترس‌پذیری و تأخیر را می‌سنجد؛ این نقش درست بودن پاسخ، هزینهٔ هر گفتگو و regression پس از تغییر مدل را. به همین دلیل Datadog از این نقش تجربهٔ ساختن برنامهٔ LLM و فهم روش‌های ارزیابی را می‌خواهد.
برای ورود باید متخصص یادگیری ماشین بود
بستگی به نقش دارد. Honeycomb و LangChain اول مهندس نرم‌افزار full-stack می‌خواهند و تجربهٔ LLM را امتیاز می‌دانند، نه شرط. در مقابل Datadog برای Staff فهم درونی مدل و pipeline استنتاج را می‌خواهد و نقش‌های eval در آزمایشگاه‌ها به پژوهش نزدیک‌ترند.
یک روز کاری واقعی
در هر سطح روز کاری چه شکلی است؟
جونیور (۰–۲ سال)
در آگهی‌هایی که دیدیم موقعیت مخصوص تازه‌کار برای این کار کم بود؛ پس جونیور در عمل یعنی مهندس نرم‌افزاری در تیم محصول AI که کم‌کم مسئول tracing و eval همان محصول می‌شود.
- ◆اضافه کردن trace به یک endpoint تازهٔ LLM و بررسی اینکه توکن و هزینهٔ هر درخواست درست ثبت می‌شود
- ◆خواندن چند ده transcript از گفتگوهای واقعی و یادداشت کردن خطاهای تکراری
- ◆نوشتن assertion های ساده برای یک ویژگی، مثلاً اینکه پاسخ شناسهٔ داخلی را لو ندهد، و اجرای آن‌ها در CI
- ◆رفع یک باگ در API یا داشبورد داخلی observability همراه با یک مهندس ارشد
- ◆اضافه کردن نمونه‌هایی که کاربران واقعی شکسته‌اند به evalset
میانی (۲–۵ سال)
مالک یک بخش مشخص هستید، مثلاً ingestion و مدل دادهٔ trace یا اجرای eval در CI، و با PM و طراح روی اینکه کاربر چه چیزی باید ببیند کار می‌کنید. در Honeycomb این سطح پس از حدود ۹۰ روز وارد چرخهٔ on-call هم می‌شود.
- ◆طراحی جدول و پرس‌وجوی تازه برای نمایش هزینه و خطا به تفکیک گفتگو
- ◆ساختن یک داور LLM و مقایسهٔ نمره‌هایش با برچسب‌های انسانی پیش از استفاده
- ◆بررسی افت کیفیت پس از تعویض نسخهٔ مدل و پیدا کردن دسته‌ای از کارها که خراب شده
- ◆جلسه با PM و طراح دربارهٔ اینکه در صفحهٔ trace چه چیزی اول دیده شود
- ◆شیفت on-call و رسیدگی به کند شدن ingestion
ارشد (۵+ سال)
سیستم را از سند معماری تا پروداکشن طراحی می‌کنید، دربارهٔ اینکه چه تغییری اجازهٔ انتشار دارد تصمیم می‌گیرید و به بقیه یاد می‌دهید. Glean از این سطح می‌خواهد eval را بخش ثابت روش انتشار ویژگی‌های AI کند و مهندسان دیگر را راهنمایی کند.
- ◆نوشتن سند طراحی برای pipeline تلمتری که دادهٔ حساس را پیش از ذخیره حذف کند
- ◆تعریف gate انتشار: کدام eval های regression باید تقریباً همیشه قبول شوند تا تغییر مدل یا prompt منتشر شود
- ◆سنجیدن نسخهٔ تازهٔ یک مدل پیش از رسیدن به کاربران و گزارش مصالحهٔ کیفیت، هزینه و تأخیر
- ◆بهینه‌سازی ذخیره و پرس‌وجوی دادهٔ پرحجم trace و eval
- ◆مرور طراحی و منتورینگ مهندسان میانی
مسئولیت‌ها و وظایف
مسئولیت‌های اصلی
وظایف روزانه و مهارت‌های مورد نیاز در این شغل
- ◈ساختن pipeline های ارزیابی که کیفیت دستیار و ایجنت را روی هزاران کار واقعی و مصنوعی می‌سنجند (Glean)
- ◈ساختن زیرساخت observability ایجنت: غنی کردن trace، pipeline پایدار تلمتری، داشبورد و روند debug (Glean)
- ◈تحلیل و نمایش سیگنال‌های مخصوص AI مثل هزینه، مصرف توکن، خطا و ناهنجاری (Honeycomb)
- ◈طراحی سرویس‌ها و API هایی که tracing، پایش و ارزیابی را پشتیبانی می‌کنند و بهینه کردن ذخیره و پرس‌وجوی دادهٔ پرحجم (LangChain)
- ◈سنجیدن نسخه‌های تازهٔ مدل پیش از انتشار و ساختن gate های regression و آمادگی انتشار برای تغییر مدل، ابزار و prompt (Glean، Perplexity، Mercor)
- ◈تحلیل مسیر اجرای ایجنت‌ها و خطاهای پروداکشن و تبدیل الگوهای خطا به تست regression (Mercor، Perplexity)
- ◈همکاری با PM، طراح و مهندسان ML و زیرساخت تا eval بخش ثابت روش انتشار ویژگی‌های AI شود (Glean، Honeycomb)
- ◈تعیین استاندارد instrumentation برای کل شرکت و راهنمایی مهندسان دیگر (Figma، Glean)
مهارت‌های مورد نیاز
مهارت‌های فنی، نرم و حوزه‌ای که یک مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی موفق به آن‌ها نیاز دارد
مهارت‌های فنی هسته
زبان backend رایج در آگهی‌های Honeycomb، LangChain و Glean؛ Thinking Machines هم Python و Rust
سرویس‌های قابل اتکا برای دریافت trace و اجرای eval؛ LangChain طراحی API و سرویس دادهٔ قابل اتکا را شرط گذاشته است
دادهٔ trace پرحجم است و باید سریع پرس‌وجو شود؛ LangChain هر سه را نام برده است
instrument کردن کد، فهم span و trace و قراردادهای GenAI
ساختن کار، معیار موفقیت و grader کدی، مدلی یا انسانی، به تفکیک Anthropic
Glean راحتی کار با pipeline های دادهٔ توزیع‌شده و سرویس‌های پروداکشن را می‌خواهد
برای نقش‌های full-stack در شرکت‌های سازندهٔ ابزار، مثل Honeycomb و LangChain
LLM، ایجنت و اندازه‌گیری
Datadog تجربهٔ عملی ساختن و انتشار برنامهٔ مبتنی بر LLM را شرط گذاشته است
ساختن داور با LLM و سنجیدن آن با برچسب انسانی
پیدا کردن جای خطا در trajectory و تبدیل آن به تست regression؛ Mercor و Perplexity هر دو می‌خواهند
انتخاب کارهای نماینده، تعریف معیار موفقیت و جدا کردن بهبود واقعی از نویز (Perplexity)
مقایسهٔ مدل‌ها بر اساس کیفیت، تأخیر و هزینه؛ Reddit و Perplexity این را جزو کار آورده‌اند
سنجیدن بازیابی و پاسخ با ابزارهایی مثل Ragas؛ Cloudflare و Pinterest نامش را آورده‌اند
برای مدل‌های اختصاصی؛ WHOOP و Datadog هر دو drift را نام برده‌اند
مهارت‌های نرم و سازمانی
xAI می‌خواهد مفاهیم مبهمی مثل کمک‌کننده بودن، راستی و ایمنی را به معیار مشخص و قابل اندازه‌گیری تبدیل کنید
Anthropic: بدون خواندن transcript ها و نمره‌های بسیاری از اجراها نمی‌دانید grader ها درست کار می‌کنند
Honeycomb سابقهٔ کار با PM و طراح را شرط گذاشته است، چون خروجی کار را کاربر می‌بیند
در Honeycomb پس از حدود ۹۰ روز؛ LangChain هم رفع مشکل پروداکشن و تحلیل ریشه را می‌خواهد
trace ها گفتگوی واقعی کاربران را دارند؛ Figma pipeline را «با حفظ حریم خصوصی» می‌خواهد
Honeycomb از سطح ارشد آموزش روش‌های درست بررسی رفتار AI را می‌خواهد
نقشه راه و مسیر آموزشی
نقشه راه تبدیل شدن به مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی
این مسیر گام به گام شما را از صفر تا حرفه‌ای هدایت می‌کند.
پایه: مهندسی نرم‌افزار backend و داده
همهٔ آگهی‌های این کار پیش از هر چیز مهندس نرم‌افزار می‌خواهند. Honeycomb سه سال سابقه و تسلط بر Go یا Python در backend و TypeScript و React در frontend را شرط گذاشته است، LangChain برای نقش FullStack دو سال سابقه و فهم درست Postgres و Redis، و Glean راحتی کار با pipeline های دادهٔ توزیع‌شده. اول یک زبان سرور را جدی یاد بگیرید، SQL و طراحی API را تمرین کنید و یک سرویس واقعی را با تست خودکار و CI بالا بیاورید.
Observability کلاسیک: metrics، logs، traces و SLO
observability برای LLM روی همان پایهٔ قدیمی ساخته می‌شود. Figma از مدیر این تیم آشنایی با Datadog، OpenTelemetry و Prometheus می‌خواهد و همان تیم مالک metrics، logs و trace های کل شرکت هم هست؛ Honeycomb تجربهٔ OpenTelemetry را امتیاز می‌داند. یاد بگیرید trace و span چیست، چطور یک سرویس را با OpenTelemetry instrument کنید و SLO چطور تعریف می‌شود.
LLM و ایجنت از نگاه اندازه‌گیری
نمی‌توانید چیزی را بسنجید که نمی‌شناسید. Datadog برای این نقش تجربهٔ عملی ساختن و انتشار برنامهٔ مبتنی بر LLM، و فهم درونی مدل، pipeline استنتاج، روش‌های ارزیابی و prompt engineering را می‌خواهد. یک چت‌بات و یک ایجنت کوچک با tool calling بسازید و ببینید کجا خراب می‌شوند. به تعریف Anthropic، transcript یا trace «سابقهٔ کامل یک اجرا» است؛ باید بدانید داخل آن چه چیزی ثبت می‌شود.
Tracing برای LLM و ایجنت، و دادهٔ trace در مقیاس
اینجا کار اختصاصی شروع می‌شود. تیم Honeycomb به مشتری نشان می‌دهد ایجنت‌ها چه می‌کنند، چقدر هزینه دارند و کجا خطا می‌دهند، و گفتگوی تک‌تک کاربران را برای debug باز می‌کند. OpenTelemetry برای این کار قراردادهای جدا دارد (GenAI semantic conventions) که span، metric و event فراخوانی مدل و MCP را تعریف می‌کند. یکی از ابزارهای LangSmith، Langfuse یا Phoenix را عمیق یاد بگیرید. بعد سراغ داده بروید: LangChain از مهندس backend بهینه کردن ذخیره و پرس‌وجوی حجم بالای دادهٔ observability و eval را می‌خواهد، و Langfuse به نوشتهٔ خودش لایهٔ دادهٔ اصلی را از Postgres به ClickHouse برد چون Postgres گلوگاه شده بود.
Evals: از assertion ساده تا LLM-as-a-Judge و gate انتشار
Hamel Husain ارزیابی را سه سطح می‌داند: unit test (assertion های سریع و ارزان)، ارزیابی انسانی و مدلی، و A/B test، و سطح اول را در هر تغییر کد اجرا می‌کند. Anthropic دو نوع eval را جدا می‌کند: eval توانایی که با نرخ قبولی پایین شروع می‌شود، و eval regression که باید تقریباً ۱۰۰٪ قبول شود. LLM-as-a-Judge را فقط وقتی به کار ببرید که با برچسب انسانی سنجیده باشید؛ Perplexity هم grader های خودکارش را «کالیبره‌شده با قضاوت انسانی» می‌خواهد. هدف آخر gate انتشار است: Mercor صریحاً می‌نویسد این نقش مالک gate هایی است که تصمیم می‌گیرند یک تغییر ایجنت منتشر شود یا نه.
ابزارها و استک فنی
ابزارهایی که هر مهندس AI باید بشناسد، دسته‌بندی‌شده بر اساس اولویت
پلتفرم‌های tracing و ارزیابی LLM
پلتفرم LangChain برای tracing، پایش و ارزیابی برنامه‌های LLM. در بررسی ما بیرون از خود LangChain در ۲۶ آگهی از ۱۸ شرکت نام برده شده بود، از جمله Coinbase و SoFi
پلتفرم متن‌باز (MIT) و سازگار با OpenTelemetry برای tracing، مدیریت prompt و ارزیابی با LLM-as-a-Judge یا بازبینی انسانی. ClickHouse آن را خریده و به اعلام Langfuse متن‌باز می‌ماند. Toast و Coursera در آگهی‌هایشان نامش را آورده‌اند
ابزار متن‌باز Arize برای observability و ارزیابی AI، با tracing و eval در همان رابط. SoFi نام Arize را در آگهی مهندس AI آورده است
پلتفرم trace، eval و آزمایش برای برنامه‌های AI؛ Drata و Suno آن را در آگهی‌هایشان کنار ابزارهای eval آورده‌اند
چارچوب‌های ارزیابی (evals)
چارچوب ارزیابی برنامه‌های AI، به‌خصوص RAG؛ Cloudflare و Pinterest آن را در آگهی‌هایشان نام برده‌اند
تست خودکار، red teaming و مقایسهٔ خروجی برنامه‌های LLM از خط فرمان یا CI، با پشتیبانی بیش از ۵۰ ارائه‌دهنده
Observability پایه و استانداردها
چارچوب متن‌باز و مستقل از فروشنده برای تولید، جمع‌آوری و ارسال traces، metrics و logs؛ برای GenAI هم قراردادهای جدا دارد. Figma و Honeycomb در آگهی‌هایشان نامش را آورده‌اند
داشبورد، بررسی metrics و logs و تعریف هشدار؛ دورهٔ Grafana fundamentals همین‌ها را قدم‌به‌قدم آموزش می‌دهد
داده، پایش مدل و پلتفرم‌های متن‌باز دیگر
پایگاه دادهٔ تحلیلی (OLAP)؛ LangChain آن را در شرط‌های مهندس backend آورده و Langfuse لایهٔ دادهٔ اصلی‌اش را روی آن ساخته است
چارچوب متن‌باز observability برای ML و LLM با بیش از ۱۰۰ معیار، از دادهٔ جدولی تا GenAI؛ برای پایش drift هم به کار می‌رود
مسیر پیشرفت شغلی
از جونیور تا Staff Engineer — چه مهارت‌هایی نیاز دارید و چه درآمدی انتظار داشته باشید
ورود: مهندس نرم‌افزار در تیم محصول AI
۰ تا ۲ سال
در آگهی‌هایی که دیدیم موقعیت مخصوص تازه‌کار برای این کار کم بود. پایین‌ترین شرط‌ها: Mercor یک تا پنج سال، LangChain برای FullStack دو سال، و xAI که می‌نویسد از تازه‌فارغ‌التحصیل تا ارشد را بررسی می‌کند. مسیر معمول این است که مهندس backend یا AI Engineer باشید و tracing و eval محصول خودتان را بنویسید.
Software Engineer, AI Observability / Evals
۲ تا ۵ سال
~$170K
میانگین سالانه (آمریکا)
مالک یک بخش از سیستم: ingestion و مدل دادهٔ trace، نمایش هزینه و مصرف توکن، یا اجرای eval در CI. نمونه: Senior Software Engineer I در Honeycomb با سه سال سابقه.
Senior Software Engineer
۵+ سال
~$210K
میانگین سالانه (آمریکا)
مالک سیستم backend از سند طراحی تا پروداکشن، بهینه‌سازی ذخیره و پرس‌وجوی دادهٔ پرحجم trace و eval، و تعریف gate انتشار؛ مثل LangChain (پنج سال به بالا) و Glean (شش سال به بالا).
Staff Engineer / Engineering Manager
۵+ سال و سابقهٔ رهبری فنی
تعیین جهت محصول یا پلتفرم observability و eval در چند تیم. Datadog برای Staff AI Engineer شکل دادن به جهت محصول LLM Observability را می‌خواهد و Figma برای مدیر تیم شش‌نفرهٔ AI Observability چهار سال سابقهٔ رهبری تیم.
چالش‌ها و جنبه‌های منفی
واقعیت‌هایی که کمتر در آگهی‌های شغلی می‌بینید — قبل از ورود بدانید
خروجی غیرقطعی
عمومیهمان ورودی می‌تواند پاسخ‌های متفاوت بدهد و خود grader مبتنی بر مدل هم، به نوشتهٔ Anthropic، غیرقطعی است. پس هشدار و gate را باید روی آمار چند اجرا ساخت، نه یک اجرا، و eval های regression را از eval های توانایی جدا نگه داشت.
evalای که شما را فریب می‌دهد
عمومیSnowflake از این نقش می‌خواهد evalای طراحی کند «که شما را فریب ندهد» و منبع خطا را نام می‌برد: نمونه‌گیری، کیفیت داده‌ای که پاسخ درست فرض شده، نشت داده و نویز. Mercor هم verifier هایی می‌خواهد که «دور زدنشان سخت باشد» و از benchmark هایی می‌گوید که دور زده می‌شوند.
حجم دادهٔ trace
شرکت بزرگهر فراخوانی مدل ورودی و خروجی طولانی دارد. Langfuse می‌نویسد با رشد استفاده Postgres برای دریافت پرحجم و خواندن تحلیلی سریع گلوگاه شد و لایهٔ داده را به ClickHouse برد؛ LangChain هم بهینه کردن ذخیره و پرس‌وجوی همین داده را از مهندس backend می‌خواهد.
حریم خصوصی در برابر دیده شدن
شرکت بزرگبرای debug باید گفتگوی واقعی را دید، اما همان گفتگو ممکن است اطلاعات شخصی داشته باشد. Figma pipeline تلمتری AI را صریحاً «با حفظ حریم خصوصی» می‌خواهد؛ حذف اطلاعات حساس، دسترسی محدود و مدت نگهداری را باید از ابتدا طراحی کرد.
ابزارهایی که زیر پایتان عوض می‌شوند
استارتاپاین بازار تازه است و سریع جابه‌جا می‌شود. WhyLabs، که خود را از پایه‌گذاران دستهٔ AI Observability می‌دانست، فعالیتش را متوقف کرد و پلتفرمش را متن‌باز کرد؛ ClickHouse شرکت Langfuse را خرید؛ و قراردادهای GenAI در OpenTelemetry به مخزن جدا منتقل شد. مفاهیم پایه (trace، grader، gate) را محکم یاد بگیرید تا با عوض شدن ابزار آسیب نبینید.
عنوان پراکنده و سطح ورود بالا
عمومیاین کار زیر عنوان‌های مختلف آگهی می‌شود (AI Observability، Agent Observability، Evals، AI Quality) و در بیشتر شرکت‌ها جزو وظایف AI Engineer است، پس جستجو با یک عنوان کافی نیست. سابقهٔ خواسته‌شده هم بالاست: Glean شش سال، Perplexity پنج سال، Reddit پنج تا دوازده سال.
حقوق و بازار کار جهانی
حقوق جهانی مهندس نرم‌افزار مشاهده‌پذیری و ارزیابی هوش مصنوعی
حقوق سالانه در کشورهای مختلف بر اساس داده‌های منتشرشده؛ منبع هر ردیف با آیکون کنار نام کشور باز می‌شود.
* ارقام سالانه‌اند. منبع هر رقم:
- Honeycomb posting, Senior Software Engineer I - Agent Observability (Remote US, 3+ years), posted Oct 15, 2026: base range; median = midpoint
- LangChain posting, Senior Backend Software Engineer, AI Observability & Evals Platform (San Francisco, 5+ years), posted Jan 8, 2026, open Oct 2026: annual salary range; median = midpoint
- Honeycomb posting, Senior Software Engineer I - Agent Observability (Remote Canada, 3+ years), posted Oct 15, 2026: base range in CAD; median = midpoint
- Honeycomb posting, Senior Software Engineer II - Agent Observability (Remote Canada; 'significant' experience, no years stated), posted Oct 15, 2026: base range in CAD; median = midpoint
- ITJobsWatch, 6 months to 22 Oct 2026: UK permanent ads citing LangSmith (proxy: skill, not job title); 25th–75th pct, median (18 salaries)
چگونه از صفر شروع کنیم
برنامه گام‌به‌گام برای ورود به مهندسی هوش مصنوعی
ماه ۱: observability کلاسیک
مفاهیم metrics، logs و traces را یاد بگیرید و یک سرویس موجود را با OpenTelemetry instrument کنید.
ماه ۲: tracing برای LLM
یک چت‌بات کوچک بسازید و trace آن را به Langfuse یا Phoenix بفرستید؛ توکن و هزینهٔ هر درخواست را ببینید.
ماه ۳: اولین eval ها
سطح اول ارزیابی را بسازید: assertion های سریع که در هر commit اجرا می‌شوند. transcript ها را بخوانید و خطاهای تکراری را دسته‌بندی کنید.
ماه ۴: LLM-as-a-Judge
یک داور LLM بسازید و با برچسب‌های خودتان بسنجید. بعد آن را برای پاسخ‌هایی به کار ببرید که با assertion قابل سنجش نیستند.
ماه ۵: ایجنت و gate انتشار
eval ایجنت را روی مسیر اجرا یاد بگیرید و یک gate در CI بسازید که تغییر مدل یا prompt را با افت regression متوقف کند.
ماه ۶: پورتفولیو و درخواست کار
دو پروژه از بخش پورتفولیو را با README روشن و نتیجهٔ eval منتشر کنید. علاوه بر عنوان‌های AI Observability و Evals، آگهی‌های AI Engineer و AI Platform را هم بخوانید؛ این کار اغلب جزو همان‌هاست.
پروژه‌های پیشنهادی برای رزومه
trace کامل یک چت‌بات با OpenTelemetry
مبتدییک چت‌بات ساده با FastAPI روی API یک مدل بسازید و آن را با OpenTelemetry instrument کنید، با رعایت قراردادهای GenAI. trace ها را به Langfuse یا Phoenix (هر دو متن‌باز و قابل نصب روی سیستم خودتان) بفرستید و برای هر درخواست تأخیر، توکن و هزینه را نشان دهید.
eval سه‌سطحی برای یک دستیار
متوسطبه روش Hamel Husain: برای هر ویژگی چند assertion ساده بنویسید (مثلاً اینکه پاسخ شناسهٔ داخلی را لو ندهد) و آن‌ها را در هر commit با GitHub Actions اجرا کنید. بعد ۵۰ تا ۱۰۰ پاسخ واقعی را خودتان برچسب بزنید، یک LLM judge بسازید و نشان دهید نمره‌هایش چقدر با برچسب شما می‌خواند.
داشبورد هزینه، توکن و خطای یک ایجنت
متوسطیک ایجنت کوچک با چند ابزار بسازید و نمایی شبیه آنچه Honeycomb توصیف می‌کند پیاده کنید: هزینه و مصرف توکن هر گفتگو، خطاها و ناهنجاری‌ها، و امکان باز کردن یک گفتگو برای debug. داده را در ClickHouse یا Postgres نگه دارید و چند پرس‌وجوی تحلیلی بنویسید.
gate انتشار برای تعویض مدل یا prompt
پیشرفتهیک eval regression بسازید که باید تقریباً همیشه قبول شود و یک eval توانایی برای کارهای سخت‌تر، به تفکیکی که Anthropic پیشنهاد می‌کند. در CI هر تغییر مدل یا prompt را روی هر دو اجرا کنید و اگر regression افت کرد، merge را ببندید. گزارشی بنویسید که دو مدل را از نظر کیفیت، هزینه و تأخیر مقایسه کند.
pipeline تلمتری با حذف اطلاعات حساس
پیشرفتهبا الهام از توصیف Figma («pipeline تلمتری با حفظ حریم خصوصی» که trace، گفتگو و دادهٔ مدل را جمع و دسته‌بندی می‌کند): trace ها را از OpenTelemetry Collector بگیرید، ایمیل و شماره و نام را پیش از ذخیره حذف کنید، گفتگوها را با یک مدل دسته‌بندی کنید و روی هر دسته eval اجرا کنید. مستند کنید چه چیزی ذخیره نمی‌شود و چرا.
مثال‌های واقعی و Case Studies
داستان‌های واقعی از مهندسانی که در این حوزه تأثیرگذار بوده‌اند
طبق معرفی نویسندگان در صفحهٔ کتاب در سایت Honeycomb، پیش از Honeycomb سال‌ها سیستم‌های توزیع‌شدهٔ بزرگ را در Parse، Facebook و Linden Lab ساخته و اداره کرده است.
هم‌بنیان‌گذار و CTO شرکت Honeycomb است و هم‌نویسندهٔ کتاب‌های Observability Engineering و Database Reliability Engineering. ویرایش دوم Observability Engineering به گفتهٔ Honeycomb تقریباً از نو نوشته شده، دو برابر ویرایش اول است و ساختن و فهمیدن کد با observability، با AI و بدون آن، را پوشش می‌دهد. همان سایت امروز Agent Observability و LLM Cost Tracking را جزو محصولات Honeycomb فهرست می‌کند.
مسیر او نشان می‌دهد observability هوش مصنوعی از صفر شروع نمی‌شود؛ ادامهٔ همان فکری است که برای debug سیستم‌های توزیع‌شده ساخته شد. کسی که این پایه را دارد، در این شغل از جای محکمی شروع می‌کند.
طبق معرفی Arize، کارشناسی EECS را از Berkeley گرفته، با گروه پژوهشی AI این دانشگاه مقاله منتشر کرده و از دکترای بینایی ماشین در Cornell مرخصی گرفته است. پیش از Arize مهندس و مدیر ML در Uber، Apple و TubeMogul بود و در Uber چند پلتفرم اصلی زیرساخت ML، از جمله Michelangelo، را ساخت.
هم‌بنیان‌گذار و مدیر ارشد محصول (CPO) Arize AI است، شرکتی که در همان صفحه از پیشگامان observability و ارزیابی AI و ایجنت معرفی می‌شود. طبق همان صفحه، سخنران کنفرانس‌های این حوزه است و نامش در فهرست Forbes 30 Under 30 آمده است.
او از ساختن زیرساخت ML به ساختن ابزار پایش آن رسید. به نظر می‌رسد تجربهٔ کار با مدل در پروداکشن، و دیدن اینکه کجا بی‌صدا خراب می‌شود، یکی از بهترین راه‌های ورود به این حوزه است.
به گفتهٔ خودش در سایت شخصی‌اش، مهندس یادگیری ماشین با بیش از ۲۰ سال سابقه است و در Airbnb و GitHub کار کرده، از جمله روی پژوهش‌های اولیهٔ LLM که OpenAI برای فهم کد از آن استفاده کرد.
اکنون به تیم‌ها کمک می‌کند سیستم‌های AI خود را debug، تحلیل و اندازه‌گیری کنند و این کار را «evals» می‌نامد؛ نوشته‌ها و تدریسش روی همین موضوع است. به گفتهٔ خودش، دورهٔ AI Evals for Engineers and PMs که هم‌مدرس آن است بیش از ۵٬۰۰۰ دانشجو از بیش از ۵۰۰ شرکت، از جمله OpenAI، Anthropic و Google، داشته است.
او از «برگرداندن علم داده به AI» حرف می‌زند. برداشت ما این است که در این شغل، پیش از انتخاب هر ابزاری، باید دادهٔ واقعی را خواند و خطاها را شمرد؛ ابزار بعد می‌آید.
نمونه آگهی استخدام واقعی + تحلیل
یک آگهی واقعی از شرکت فعال در حال استخدام، با تحلیل هر بخش
Software Engineer, Evals
تحلیل نیازمندی‌ها
You have 6+ years of software engineering experience building backend systems, infrastructure, distributed systems, or data platforms.
این سابقه از جنس مهندسی سیستم است، نه AI. شش سال بالاتر از بیشتر آگهی‌هایی است که دیدیم؛ Honeycomb و xAI سه سال و LangChain برای FullStack دو سال می‌خواهند.
ضروریYou have strong coding skills in Go, Python, Java, C++, or similar languages, with an emphasis on reliability, scale, and well-tested components.
زبان خاصی شرط نیست. آنچه سنجیده می‌شود کد قابل اتکا و تست‌شده است، چون pipeline ارزیابی خودش باید درست کار کند تا نتیجه‌اش قابل اعتماد باشد.
ضروریYou are comfortable working with distributed data pipelines, production services, observability systems, or cloud-native infrastructure.
کار روزانه جابه‌جا کردن و پردازش حجم زیادی trace و نتیجهٔ eval است. تجربهٔ مهندسی داده یا DevOps اینجا مستقیم به کار می‌آید.
ضروریYou are analytically rigorous and care about whether metrics reflect real user experience, not just whether dashboards look good.
مهم‌ترین جملهٔ آگهی برای فهم این شغل. معیاری که بالا می‌رود ولی تجربهٔ کاربر را بهتر نمی‌کند بی‌فایده است؛ باید بتوانید درستی خود معیار را زیر سؤال ببرید.
مهمYou care deeply about quality, both in the systems you build and in the AI product you help measure and improve.
این تیم دو مشتری دارد: مهندسانی که از ابزارش استفاده می‌کنند و کاربرانی که کیفیت دستیار را حس می‌کنند.
مهمExperience with LLM applications, evals, tracing, data warehouses, workflow orchestration, or ML infrastructure is a strong plus.
تجربهٔ LLM «امتیاز قوی» است، نه شرط. یعنی یک مهندس backend یا داده‌ی قوی می‌تواند بقیه را در همین کار یاد بگیرد.
مهمYou enjoy customer-focused, cross-functional environments and are willing to take on whatever is most impactful for the company.
یعنی گاهی کارتان ساختن زیرساخت است و گاهی نشستن کنار تیم محصول برای فهم اینکه یک افت کیفیت از کجا آمده.
مفیدتحلیل مسئولیت‌ها
Design and build large-scale evaluation pipelines that measure assistant and agent quality across thousands of real user and synthetic workflows.
ترکیب دو نوع داده: کارهای واقعی کاربران که نشان می‌دهد محصول در عمل چطور است، و کارهای مصنوعی که حالت‌های نادر را پوشش می‌دهند.
Evaluate frontier model releases and the latest OSS model drops, building the infrastructure and quality signals that help Glean understand regressions, tradeoffs, and launch readiness.
هر بار که مدل تازه‌ای می‌آید، این تیم باید سریع بگوید عوض کردنش چه چیزی را بهتر و چه چیزی را بدتر می‌کند. این همان eval regression و eval توانایی است که Anthropic از هم جدا می‌کند.
Build agent observability infrastructure, including trace enrichment, durable telemetry pipelines, dashboards, and debugging workflows that make AI behavior inspectable.
«غنی کردن trace» یعنی افزودن اطلاعات لازم برای debug به هر trace، مثل نوع کار یا نسخهٔ مدل. «پایدار» یعنی دادهٔ تلمتری در خرابی‌ها گم نشود.
Own backend systems from architecture and design docs through production rollout, reliability, monitoring, and iteration.
مالکیت کامل: از نوشتن سند طراحی تا نگه داشتن سیستم در پروداکشن. این همان چیزی است که شش سال سابقه را توجیه می‌کند.
Partner with product, ML, and infrastructure engineers to make evals a first-class part of how Glean ships AI features.
هدف این است که eval گام ثابت انتشار باشد، نه کاری که بعد از انتشار یادش می‌افتند. بخشی از کار متقاعد کردن تیم‌های دیگر است.
Improve the quality loop by connecting eval results, customer feedback, regression analysis, and engineering workflows into concrete product improvements.
نتیجهٔ eval به‌تنهایی ارزشی ندارد؛ باید به تغییر مشخصی در محصول برسد. این حلقه همان چیزی است که Hamel Husain «چرخهٔ بهبود» می‌نامد.
نتیجه‌گیری کلی
این آگهی خلاصهٔ خوبی از این شغل است: eval و observability در یک تیم، روی محصول AI واقعی، با شرط‌هایی که بیشترشان مهارت مهندسی سیستم و داده‌اند. تجربهٔ LLM و eval امتیاز است، نه شرط ورود. چیزی که این نقش را از مهندسی backend معمولی جدا می‌کند دقت دربارهٔ خود معیارهاست: آیا عددی که می‌سنجید واقعاً تجربهٔ کاربر را نشان می‌دهد؟
آینده و روندها
پیش‌بینی ۵–۱۰ ساله و مهارت‌هایی که باید یاد بگیرید
طبق ITJobsWatch، آگهی‌های دائم بریتانیا که LangSmith را خواسته‌اند در شش ماه منتهی به ۲۲ اکتبر ۲۰۲۶ به ۴۴ رسید، در برابر ۶ در همین بازهٔ ۲۰۲۵ و صفر در ۲۰۲۴؛ برای Langfuse همین عدد ۴۲ در برابر ۶ بود. این آمار یک مهارت است، نه عنوان شغلی، و پایه‌اش کوچک است.
منبع: ITJobsWatch — LangSmith (UK, 6 months to 22 Oct 2026)
مهارت‌های نوظهور که باید یاد بگیرید
پیش‌بینی‌های آینده
به گزارش IT Brief UK، Gartner پیش‌بینی می‌کند تا ۲۰۲۸ هوش مصنوعی توضیح‌پذیر (XAI) سرمایه‌گذاری در LLM observability را به ۵۰٪ استقرارهای GenAI برساند، از ۱۵٪ امروز. Gartner در همان گزارش پلتفرم‌هایی را توصیه می‌کند که تأخیر، drift، مصرف توکن، هزینه، نرخ خطا و کیفیت خروجی را پایش کنند.
در گزارش Future of Jobs ۲۰۲۵ مجمع جهانی اقتصاد (WEF)، کارفرمایان شرکت‌کننده «AI and big data» را در صدر سریع‌ترین مهارت‌های در حال رشد تا ۲۰۳۰ گذاشته‌اند و «AI and Machine Learning Specialists» و «Software and Application Developers» را از سریع‌ترین شغل‌های در حال رشد (از نظر درصد).
سه ریسک دیده می‌شود. اول، این کار در بیشتر شرکت‌ها عنوان جدا ندارد و جزو وظایف AI Engineer یا ML Engineer است؛ تیم جدا معمولاً وقتی شکل می‌گیرد که محصول AI بزرگ شده باشد، مثل Glean و Figma. دوم، ابزارها و شرکت‌های این بازار سریع جابه‌جا می‌شوند: WhyLabs تعطیل شد و Langfuse به ClickHouse فروخته شد. سوم، دربارهٔ حقوق: سایت‌های حقوق برای عنوان دقیق این شغل داده ندارند (Glassdoor برای «AI Observability Engineer» هیچ حقوقی ثبت نکرده) و رقم Glassdoor برای عنوان عمومی Observability Engineer در آمریکا (بازهٔ پایهٔ ۱۰۰ تا ۱۳۶ هزار دلار و میانگین ۱۱۷ هزار دلار از ۲۷ حقوق، برآورد به‌روزشده در آوریل ۲۰۲۵) حتی از کف بازهٔ آگهی‌های سطح میانی LangChain و Honeycomb (۱۴۵ و ۱۶۰ هزار دلار) پایین‌تر است، پس احتمالاً شغل گسترده‌تر و عملیاتی‌تری را می‌سنجد. به همین دلیل جدول حقوق این صفحه از بازهٔ پایهٔ آگهی‌ها و آمار مهارت LangSmith در بریتانیا ساخته شده است.
منابع
اطلاعات این صفحه در تاریخ ۳۰ مهر ۱۴۰۵ از این ۵۱ منبع بررسی شده است.
- Software Engineer, Evals — Glean (job posting)
- Software Engineer, Evals — Glean (archived copy)
- Tech Lead Manager, AI Evaluations — Glean (job posting)
- Senior Software Engineer I - Agent Observability, Remote US — Honeycomb (job posting)
- Senior Software Engineer I - Agent Observability, Remote Canada — Honeycomb (job posting)
- Senior Software Engineer II - Agent Observability, Remote Canada — Honeycomb (job posting)
- FullStack Engineer, AI Observability & Evals Platform (LangSmith) — LangChain (job posting)
- Senior Backend Software Engineer, AI Observability & Evals Platform (SF) — LangChain (job posting)
- Senior Backend Software Engineer, AI Observability & Evals Platform (LangSmith), Boston — LangChain (job posting)
- Staff AI Engineer - Agent Observability — Datadog (job posting)
- Manager, Software Engineering - AI Observability — Figma (job posting)
- Software Engineer, Agent Optimization & Evaluation — Reddit (job posting)
- Member of Technical Staff (Software Engineer, Enterprise Agent Evals & Efficiency) — Perplexity (job posting)
- Member of Technical Staff, Enterprise Evals Platform — Mercor (job posting)
- Software Engineer - Evals — SpaceXSI / xAI (job posting)
- Software Engineer, Evaluation Platform / Infra — Thinking Machines Lab (job posting)
- Software Engineering Manager (AI Quality) — WHOOP (job posting)
- LLMops Engineer — Coursera (job posting)
- Senior Staff AI Engineer — SoFi (job posting)
- Senior Software Engineer, AI Agent & Experience Team — Toast (job posting)
- Lead Engineer, Applied AI (Customer Agent) — Klaviyo (job posting)
- Engineering Manager, AI Platform — Harvey (job posting)
- Senior Software Engineer, Cortex Quality — Snowflake (job posting)
- Senior Machine Learning Engineer, CX — Coinbase (job posting)
- Senior Product Engineer 2, Audit — Drata (job posting)
- Senior / Staff Software Engineer, AI Leverage — Suno (job posting)
- Senior Machine Learning Engineer — Cloudflare (job posting)
- Sr. Staff Software Engineer, AI Platform — Pinterest (job posting)
- Senior Software Engineer - AI Infrastructure Performance Insights & Observability — CoreWeave (job posting)
- Senior AI Infrastructure Engineer, Observability — Firmus (job posting)
- ITJobsWatch — LangSmith job trends and salaries (UK)
- ITJobsWatch — Langfuse job trends and salaries (UK)
- ITJobsWatch — OpenTelemetry job trends and salaries (UK)
- ITJobsWatch — Observability job trends and salaries (UK)
- Glassdoor — Observability Engineer salaries (United States)
- IT Brief UK — Gartner sees explainable AI boosting model oversight
- World Economic Forum — The Future of Jobs Report 2025 (PDF)
- Anthropic — Demystifying evals for AI agents
- Hamel Husain — homepage
- Hamel Husain — Your AI Product Needs Evals
- Hamel Husain — Using LLM-as-a-Judge For Evaluation
- Arize — Aparna Dhinakaran (author bio)
- Honeycomb — Observability Engineering, 2nd Edition (book page and author bios)
- Honeycomb (company) — Wikipedia
- Langfuse — Langfuse joins ClickHouse
- WhyLabs — company closure notice
- OpenTelemetry — Documentation (What is OpenTelemetry?)
- OpenTelemetry GenAI Semantic Conventions (GitHub)
- Datadog — Agent Observability / LLM Observability
- Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs (arXiv)
- Inspect — UK AI Security Institute