TECHNICAL & OPERATIONS BRIEF · نسخهٔ زندهٔ راهنما
سامانه را مانند
یک خط کنترل کیفیت داده ببینید.
این صفحه برای تصمیمگیر، کارشناس پایش، متخصص استانداردسازی و فناوری اطلاعات طراحی شده است: چه چیزی اکنون کار میکند، چه چیزی هنوز مجاز به ادعا نیست و برای تبدیل پایلوت به خدمت سازمانی چه اندازهگیری و اقدامی لازم است.
DOCS 14050603-005159 · RUNTIME 14050602-214203
کد خودرویی مستقر است؛ دامنه هنوز در مرحلهٔ پذیرش GS1 است
این snapshot مستندات در bundle مستقل 14050603-005159 منتشر شده و رفتار runtime را تغییر نمیدهد. خط پایهٔ عملیاتی از منبع d93bdda با رسید RELEASE_OK=14050602-214203 از مسیر backup-first عبور کرده و کنترل سلامت عمومی/مبدأ و ایمنی سرویس legacy را گذرانده است. T‑18 و T‑19 اکنون قابلیتهای مستقرِ PILOT هستند، نه ROADMAP؛ این وضعیت به معنی تأیید رسمی mapping یا دقت عمومی نیست.
شاهد زندهٔ عبارت کارشناسی
هر دو عبارت «سپر جلو مشکی ال نود» و «مشکی، ال۹۰ / جلو / سپر» در runtime زنده به دامنهٔ خودرو و دقیقاً چهار فیلدِ نام پایه=سپر، محل قرارگیری=جلو، رنگ=مشکی و نام و مدل خودرو=ال نود تفکیک شدند؛ leftover خالی است، اما بهدلیل نامزد 6074 همچنان needs_review:true میمانند.
| کنترل تولید | وضعیت نصبشده | مرز ادعا |
|---|---|---|
| AI / RAG | false / false · deterministic_only | هیچ پیشنهاد ابری یا RAG تولیدی فعال نیست |
| سقف تلاشهای خروجی provider | ۴۰۰ تلاش HTTP تجمعی شامل generation، embedding و retry | گارد هزینه است؛ نشانهٔ فعالبودن مدل نیست |
| 6074 و alias خودرو | candidate_pending_expert | تصویب canonical با GS1 ایران |
| پذیرش کیفیت | باز | gold set واقعی و batch حداقل ۵۰۰ ردیفی لازم است |
یک صفحه، چهار زاویهٔ خواندن
آنچه برای نقش شما مهمتر است
اطلس دانش سامانه
از آشنایی پایه تا تصمیم معماری
هر فصل یک مسیر مستقل و قابل ارجاع دارد. مدیر میتواند از حکمرانی و KPI شروع کند؛ کارشناس از عملیات و داده؛ و تیم IT از معماری، امنیت و API.
مبانی و واژهنامه
از دادهٔ محصول و قاعدهٔ قطعی تا مدل، RAG، اطمینان و بازبینی انسانی.
شروع برای همه ← ۰۲ · مهندسیمعماری سامانه
اجزا، مرزها، جریان درخواست، state machine و تفاوت وضعیت فعلی با معماری هدف.
نقشهٔ فنی ← ۰۳ · موتوراستانداردسازی داده
نرمالسازی فارسی، واحد، نام پایه، خروجی اتمی، ambiguity و بازبینی.
قواعد و مثالها ← ۰۴ · دانشداده، حافظه و RAG
طبقهبندی داده، حقوق منبع، corpus، retrieval، استناد و یادگیری کنترلشده.
چرخهٔ دانش ← ۰۵ · سنجشارزیابی و KPI
F1، ECE، PSI، latency، بار بازبینی و ماشینحساب طراحی پایلوت.
آزمایشگاه شاخصها ← ۰۶ · اعتمادامنیت و عملیات زیرساخت
هویت، mTLS، egress، اسرار، محدودیت هزینه، audit، backup و rollback.
مرزهای حفاظتی ← ۰۷ · یکپارچهسازیراهنمای API برای IT
workflowها، احراز هویت، قرارداد خطا، نمونه درخواست و چکلیست onboarding.
قرارداد اتصال ← ۰۸ · اجراعملیات و سناریوهای نقشمحور
شرکت، نماینده استانی، کارشناس سازمان، صف بازبینی و روال روزانه پایش.
راهنمای عملیات ← ۰۹ · تصمیمحکمرانی و مسیر توسعه
نقشهای سازمان، RACI، دروازههای پذیرش و برنامهٔ تبدیل پایلوت به خدمت.
بستهٔ تصمیمگیری ← ۱۰ · مهندسی تصمیمPrompt و Context Harness
ساخت کانتکست محدود، حافظههای جدا، پیشنهاد ساختیافته، پساعتبارسنجی و بازخورد کنترلشده.
کالبدشکافی میز تصمیم ← ۱۱ · درسآموختهدفتر D‑01 تا D‑13
مسئلههای واقعی پایش، از خروجی اتمی تا نشت بیندامنهای و تفکیک batch، همراه علت فنی و معیار پذیرش.
مشاهدهٔ دفتر کیفیت ← ۱۲ · آموزش نقشمحورآکادمی پایه تا حرفهای
چهار مسیر یادگیری، تمرینهای SYNTHETIC، چک فهم و پروژهٔ پایانی برای نقشهای سازمانی.
ورود به آکادمی ← ۱۳ · مرجعوضعیت، شواهد و اصطلاحات
رجیستر وضعیت قابلیتها، سلسلهمراتب منابع حقیقت، مرز ادعا و نقشهٔ ارجاع سریع.
بازکردن مرجع ← ۱۴ · نقشهٔ تعاملیاطلس جریانهای زنده
پنج مدل تعاملی برای مسیریابی دامنه، بازیابی نوعدار، RAG/Harness، batch و حافظه/audit.
بازکردن نقشهٔ سیگنال ← ۱۵ · پایلوت دامنهقطعات و مدل خودرو
تفکیک «سپر جلو مشکی ال نود»، حفاظت نخود/نخودی، شواهد داده و مسئولیت GS1.
قرارداد خودرویی ← ۱۶ · گزارش مجمعگزارش مجمع ۱۴۰۵
مرور مالی منبعمحور، کنترل تطبیق، سناریوهای کیفی و خروجیهای قابل دریافت.
بازکردن گزارش ← ۱۷ · اتاق تصمیمگزارش تعاملی مجمع ۱۴۰۵
محاسبهگر زنده، سناریوهای ۱۴۰۵–۱۴۰۹، حساسیت، شواهد و نقشهٔ راه RAG و صوت.
ورود به اتاق تصمیم ←01 · معماری تصمیم
هر تصمیم از چهار دروازه عبور میکند
ترتیب عمداً محافظهکارانه است: قاعده، تطبیق دقیق، بازیابی مستند و در انتها پیشنهاد مدل. هیچ خروجی مبهمی نباید بیصدا وارد دادهٔ مرجع شود.
نرمالسازی و قواعد
یکسانسازی فارسی، واحدها، ساختار محصول، اسم پایه و قواعد ابهام.
زندهتطبیق دقیق و حافظهٔ کارشناسی
واژهنامه، فرهنگ نامها و تصمیمهای بازبینیشده با کنترل نسخه.
زندهبازیابی مستندات (RAG)
فقط از corpus رسمیِ نسخهدار با حقوق، منبع و استناد روشن.
اکنون غیرفعالپیشنهاد مدل و بازرتبهبندی
پیشنهاد قابل توضیح؛ نه تصمیم نهایی و نه ثبت خودکار.
اکنون غیرفعالشرکت محصولی با نام «ظرف یکبارمصرف مشکی» وارد میکند.
سامانه ابتدا عبارت را تمیز و اجزای آن را جدا میکند. اگر قواعد قطعی پاسخ کافی بدهند، نتیجه با دلیل نشان داده میشود. اگر ویژگی کالا مبهم باشد، سامانه آن را برای بازبینی میفرستد؛ خودش حدس را به دادهٔ مرجع تبدیل نمیکند.
مشاهده در میز عملیات ←کارشناس استانی با یک پیشنهاد نامطمئن روبهرو است.
اکنون: onboarding هویتهای scoped استانی هنوز پذیرفته نشده است و هر بازخورد صرفاً candidate-only ثبت میشود؛ رأی کاربر قاعده یا حافظهٔ مرجع را تغییر نمیدهد. هدف: پس از اتصال هویت سازمانی، رأی مستند وارد صف داوری شود و فقط یک تصویب جداگانهٔ کارشناس/کمیته بتواند نسخهٔ canonical را تغییر دهد.
مسیر کنترل انسانی ←واحد IT باید هزینه و ریسک را کنترل کند.
در runtime تولید، گارد تجمعی ۴۰۰ درخواست خروجی نصب شده است؛ همزمان AI و RAG همچنان خاموشاند. بنابراین سقف، کنترل آمادهبهکار هزینه است و به معنی مصرف سهمیه یا فعالبودن مدل ابری نیست.
کنترلهای فنی ←02 · حلقهٔ بهبود هدف
حافظه یعنی دانشِ تأییدشده، نه انباشتن پاسخها
اکنون: قرارداد PILOT بازخورد را candidate-only نگه میدارد و promotion خودکار ندارد. هدف/ROADMAP: پس از تعریف داوری، holdout و گیت انتشار، هر بازخورد به نمونه، قاعده، مالک، تاریخ، نسخه و نتیجهٔ ارزیابی متصل شود.
چرخهٔ حکمرانی، نه یادگیری خودکار جاری
مسیر بازبینی تا حافظهٔ نسخهدار و ارزیابی، الگوی عملیاتی پیشنهادی است و هنوز بهعنوان چرخهٔ کامل سازمانی پذیرفته نشده است.
- ۱ · ورودیشرکت، استان، کارشناس
- ۲ · قواعد قطعینرمالسازی و کنترل
- ۳ · بازبینیتأیید، رد، دلیل
- ۴ · حافظه نسخهدارفقط پس از تصویب جداگانه
- ۵ · ارزیابیgolden set و پایش drift
03 · داشبورد برنامهریزی KPI
با اعداد نمونه، ظرفیت و کیفیت را قبل از اجرا ببینید
این ماشینحساب اطلاعات را ذخیره یا ارسال نمیکند. «ارجاعشده» برای ظرفیتسنجی و «داوریشده/بستهشده» برای محاسبهٔ نرخ خطای تأییدشده دو مخرج متفاوتاند. برای KPI رسمی، اعداد را از لاگ و پروندهٔ بازبینی مصوب وارد کنید.
اعداد نمونه هستند و برای تصمیم تولیدی اعتبارسنجی نشدهاند.
| KPI | تعریف قابل اندازهگیری | مالک | تناوب و واکنش |
|---|---|---|---|
| دقت توافقشده | F1 و exact match روی holdout واقعی و داوری دوکارشناس | استانداردسازی | هر نسخه؛ توقف promotion در افت معنادار |
| کالیبراسیون | ECE بر حسب سطح اطمینان؛ آیا اطمینان با واقعیت همخوان است؟ | داده + AI | ماهانه؛ بازتنظیم آستانهٔ ارجاع |
| پایداری داده | PSI/drift ویژگیها، دامنهها و الگوی ابهام | پایش داده | هفتگی؛ نمونهگیری و بازبینی فرهنگ |
| کیفیت عملیات | P50/P95 زمان پاسخ، نرخ خطا، نرخ پروندهٔ حلنشده | IT + عملیات | روزانه؛ بررسی رخداد و SLA |
| پاسخگویی | درصد خروجیهای دارای دلیل، نسخه و audit trail | مالک خدمت | هر انتشار؛ عدم عبور بدون evidence |
04 · مرزهای فنی و علمی
چیزهایی که باید قبل از توسعهٔ گسترده درست شوند
هویت و دسترسی
OIDC برای انتساب به انسان واقعی، mTLS برای اتصال سامانهها، کلیدهای محدود و قابل چرخش برای هر کانال.
وضعیت: نیازمند اجرا و پذیرش سازمانیداده و حقوق استفاده
طبقهبندی، حداقلسازی، retention، pseudonymization و corpus رسمی با مالک، مجوز و provenance روشن.
وضعیت: پیشنیاز دادهٔ واقعیاستقرار و بازیابی
انتشار مرحلهای، backup، rollback، آزمون سلامت و حفظ همسایههای میزبان مشترک.
وضعیت: کنترل استقرار برقرارکنترل هزینه و خروج داده
رلهٔ مصوب، خاموشبودن پیشفرض، سقف تجمعی candidate و توقف پیش از egress در صورت اتمام سهم.
وضعیت: candidate؛ مسیر ابری غیرفعال05 · مسیر بلوغ
از پایلوت قابل مشاهده تا خدمت قابل اتکا
- اکنون
خط پایهٔ قابل اندازهگیری بسازید
نمونهٔ واقعیِ ناشناسشده، فرهنگ واژگان، موارد اختلاف و KPI baseline را جمع کنید. synthetic فقط برای wiring است، نه اثبات دقت تولید.
- پیش از فعالسازی AI/RAG
مرجع، امنیت و پذیرش را تصویب کنید
corpus رسمی نسخهدار، حقوق استفاده، holdout کور، داوری دوکارشناس، OIDC/mTLS، budget و canary باید evidence قابل ارائه داشته باشند.
- پس از پایلوت
تغییر را قابل بازگشت و قابل حسابرسی نگه دارید
هر prompt، context، قانون و snapshot باید owner، version، ارزیابی و امکان rollback داشته باشد. write-back خودکار فقط با مجوز مستقل.
06 · نقش GS1 ایران
این فهرست، کارِ سامانه نیست؛ کارِ سازمان است
برای هر مورد، مالک و موعد تعیین کنید. تیکها فقط روی همین مرورگر و برای پیگیری جلسهاند؛ به سامانه ارسال نمیشوند.
07 · بهروزرسانی کیفیت دامنهای
قطعات خودرو: از تطبیق واژه به تفکیک قابل داوری
بازخورد «سپر جلو مشکی ال نود» به یک پایلوت deterministic و domain-scoped تبدیل شده است: مسیر خودرو پیش از واژگان بستهبندی تشخیص داده میشود، facetها نوعدار و شاهددارند، و حفاظت exact مانع تبدیل «نخود» به رنگ «نخودی» میشود. وضعیت PILOT است؛ پذیرش کیفیت روی دادهٔ واقعی و تأیید ساختار 6074 همچنان با GS1 ایران است.
سازمان rule برای هر رشته نمینویسد؛ ontology و نمونهٔ طلایی را تصویب میکند.
کارشناسان استانداردسازی نام و aliasهای مصوب را مالک میشوند؛ پایش داده نمونههای واقعی و موارد مبهم را تحویل میدهد؛ و سامانه فقط بر اساس همین منبع نسخهدار پیشنهاد میدهد. فعالبودن کد جای پذیرش دامنهای را نمیگیرد.
مشاهدهٔ شواهد داده، قرارداد خروجی، KPIها و اقدامهای GS1 ←