اضافهکردن یک فراخوانی مدل به Backend چند ساعت زمان میبرد؛ ساختن قابلیتی که در اینترنت ناپایدار، ورودی فارسی، بار واقعی و حالت خطا قابل اعتماد بماند، مسئله اصلی است. بسیاری از پروژههای AI نه بهخاطر انتخاب مدل ضعیف، بلکه بهخاطر Use case مبهم، Ground truth نامعلوم، داده بدون مجوز، API بدون Timeout، خروجی کنترلنشده و نبود مسیر Fallback شکست میخورند.
این راهنما برای توسعهدهنده، Product، Data/ML، Security و SRE نوشته شده است. هدف آن تبلیغ «AI در همهچیز» نیست؛ هدف این است که تشخیص دهید کجا Rule/Search/UX ساده کافی است، کجا ML کلاسیک یا مدل مولد ارزش دارد، و چگونه آن را از PoC به Web application قابل سنجش و قابل بازگشت ببرید.
هوش مصنوعی در وباپلیکیشن دقیقاً چه معنایی دارد؟
«AI feature» میتواند از یک مدل Logistic regression کوچک تا سیستم Recommendation، Semantic search، OCR، تشخیص تقلب، خلاصهسازی، دستیار گفتگو یا Agent ابزارمحور باشد. این خانوادهها ورودی، Failure mode، معیار و معماری یکسان ندارند. LLM فقط یکی از گزینههاست.
| خانواده | نمونه وب | خروجی | ریسک شاخص |
|---|---|---|---|
| Rule/Heuristic | اعتبارسنجی فرم، Eligibility | قطعی | Rule drift و Edge case |
| ML کلاسیک | Churn، Fraud score، Ranking | Score/Class | Bias، Drift، Threshold |
| Recommendation/Search | کالا یا محتوای مرتبط | Ranked list | Filter bubble، Inventory constraint |
| Computer vision/Speech | OCR، Caption، Transcription | Text/Label/Region | کیفیت ورودی و داده حساس |
| Generative AI | Draft، Summary، Q&A | احتمالی و باز | Confabulation، Injection، هزینه |
| Agent/Tool use | استعلام یا اقدام در سامانه | Plan + Action | Excessive agency و Authorization |
AI الزام نیست؛ با Baseline کمپیچیدگی شروع کنید
اگر شرط کسبوکار قطعی، قابل توضیح و کمتغییر است، Rule engine انتخاب بهتری است. اگر Keyword search نیاز را حل میکند، Semantic retrieval هنوز ارزش اضافه نکرده است. اگر کاربر به اطلاعات دقیق سفارش نیاز دارد، Query مستقیم پایگاهداده از تولید متن معتبرتر است.
| پرسش | اگر پاسخ منفی است |
|---|---|
| آیا Job و کاربر مشخصاند؟ | Discovery انجام دهید؛ مدل انتخاب نکنید |
| آیا Baseline فعلی اندازهگیری شده؟ | Rule/Search/Manual flow را بسنجید |
| آیا داده مجاز و نماینده دارید؟ | Data contract و Consent را حل کنید |
| آیا خطا قابل کشف و مهار است؟ | دامنه را کوچک یا Human review اضافه کنید |
| آیا Outcome ارزش Cost/Risk را دارد؟ | Prototype را Stop کنید |
برای برآورد TCO، Cost per accepted outcome و تصمیم Scale/Stop از راهنمای هزینه پیادهسازی AI استفاده کنید. Speed یک PoC، شاهد Production fit نیست؛ چارچوب Assumption و Evidence در راهنمای نمونهسازی سریع آمده است.
Gate صفر: Use-case contract بنویسید
Actor: چه کسی و با چه سطح دسترسی؟
Job: در چه موقعیتی چه پیشرفتی میخواهد؟
Input: چه دادهای، از کجا و با چه مجوزی؟
Output: چه Schema و چه تصمیمی را پشتیبانی میکند؟
Baseline: راه فعلی و کیفیت/زمان/هزینه آن چیست؟
Failure: خطای قابل قبول و خطای غیرقابل قبول چیست؟
Authority: مدل پیشنهاد میدهد یا اقدام میکند؟
Human gate: چه چیزی تأیید انسانی میخواهد؟
Fallback: در Timeout/Refusal/Outage چه میشود؟
Acceptance: حداقل Quality/Latency/Cost/Safety چیست؟
Owner: چه کسی Outcome و Residual risk را میپذیرد؟مثلاً «چتبات هوشمند» Use case نیست. «پاسخ به پرسش وضعیت سفارش با داده همان کاربر، بدون تغییر سفارش، با Citation به رکورد و Escalation در ابهام» Contract قابل ارزیابی است.
Risk tier؛ میزان خودکارسازی را با پیامد خطا تنظیم کنید
| Tier | نمونه | Authority | کنترل انتشار |
|---|---|---|---|
| کم | پیشنهاد Tag برای Draft | پیشنهاد، قابل Undo | Sample review |
| متوسط | Ranking یا پاسخ Help center | نمایش با Grounding/Fallback | Offline eval + Canary |
| زیاد | تقلب، اعتبار، سلامت، حقوق | Decision support محدود | متخصص، Appeal، Audit و Requirement جاری |
| اقداممحور | Refund، حذف، ارسال پیام | Least privilege + Confirmation | Tool allowlist، Policy engine و Replay |
NIST AI Resource Center منابع AI RMF و آزمون/ارزیابی/Verification/Validation را گردآوری میکند. این Framework تصمیم محصول را جایگزین نمیکند، اما برای مستندسازی Govern/Map/Measure/Manage و Risk owner مفید است.
Build، Buy یا مدل آماده؛ تصمیم روی Lifecycle است
| گزینه | مزیت | هزینه پنهان | مناسب وقتی |
|---|---|---|---|
| Rule/Search | قابل توضیح و ارزان | نگهداری Rule و Recall محدود | منطق قطعی است |
| Managed model API | شروع سریع و Capability بالا | Latency، Usage cost، Terms، Lock-in | Provider fit و Exit دارید |
| Pre-trained self-hosted | کنترل Deployment/Data بیشتر | GPU/ops، patch، evaluation | تیم و Scale توجیه دارد |
| Fine-tune | تطبیق Behavior/Task | Dataset، Drift، نسخه و بازآموزی | Prompt/Retrieval کافی نیست |
| مدل اختصاصی | Fit بالا برای مسئله خاص | Data/ML lifecycle کامل | مزیت و داده پایدار دارید |
زبان برنامهنویسی «بهترین مطلق» ندارد. Python، JavaScript/TypeScript، Java، Go، Rust یا C# میتوانند بخشی از Stack باشند. معیار، Runtime، کتابخانه، Skill تیم، Latency، Operability و Supply chain است؛ نه محبوبیت یک زبان.
پنج الگوی معماری برای AI در وب
| الگو | مسیر | مزیت | قید اصلی |
|---|---|---|---|
| Client-side | Browser → Local model | Offline و حذف Round trip | Download/Memory/Device/Exposure |
| Internal serving | Web → Backend → Model service | کنترل و جداسازی | Platform/MLOps |
| Managed API | Web → Backend → Provider | سرعت عرضه | Terms/Data/Quota/Exit |
| Async/Batch | Web → Queue → Worker → Result | کنترل بار و کار طولانی | State/Idempotency/Notification |
| Hybrid | Local pre/post + Server inference | تقسیم کار | دو Runtime و Failure surface بیشتر |
Hybrid خودبهخود «بهترین دو دنیا» نیست؛ ممکن است هر دو پیچیدگی را جمع کند. تصمیم را با Device matrix، P95 latency، حجم Model، Privacy boundary، Cost و Failure drill اثبات کنید.
Client-side inference؛ چه زمانی واقعاً مناسب است؟
اجرای مدل در مرورگر برای کارهای کوچک، تعاملی، Offline یا دادهای که نباید برای Inference ارسال شود جذاب است. اما Artifact مدل به دستگاه کاربر میرسد، Capability مرورگر یکسان نیست، Main thread ممکن است مسدود شود و «داده خارج نمیشود» فقط وقتی درست است که Telemetry، CDN، Plugin و کد دیگر آن را ارسال نکنند.
بهجای ONNX.js قدیمی، مستندات فعلی ONNX Runtime Web بسته onnxruntime-web و Execution Providerهای WASM/WebGPU/WebNN را توضیح میدهد؛ Operator و Browser support یکسان نیست. TensorFlow.js نیز اجرای مدل در Browser و Node.js را پوشش میدهد. انتخاب باید با Prototype روی Deviceهای واقعی باشد.
| Gate مرورگر | آزمون | Fallback |
|---|---|---|
| Capability | Browser/OS/Execution provider | WASM یا Server |
| Artifact | Bundle/model bytes و Cache | Lazy load و مدل کوچکتر |
| Performance | Init، warm/cold P95، Memory، Battery | Worker، quantization، degrade |
| UX | Progress، Cancel، tab background | Manual path |
| Security | CSP، integrity، model provenance | Same-origin و pinned artifact |
| Privacy | Network audit و local retention | Consent/clear storage |
Server-side model service؛ مرز قابل عملیات
برای مدل سنگین، داده Backend، Authorization متمرکز یا IP مدل، سرویس سمت سرور مناسبتر است. GPU الزام نیست؛ CPU، accelerator یا inference managed بر اساس Workload انتخاب میشود. Container و Kubernetes نیز «مرحله استاندارد» نیستند؛ یک سرویس ساده یا Job queue ممکن است برای بار واقعی کافی باشد.
| لایه | مسئولیت |
|---|---|
| Web/API gateway | AuthN، Rate، request size، Trace ID |
| AI orchestration | Policy، Prompt، Retrieval، Tool routing |
| Model adapter | Provider/self-host contract و normalization |
| Inference | Model runtime، batching و resource limit |
| Evaluation | Dataset، grader، threshold و regression |
| Telemetry | Latency breakdown، quality، cost و safety |
Managed API؛ کلید را هرگز در Frontend قرار ندهید
Browser باید به Backend خودتان درخواست دهد و Backend با Secret manager به Provider وصل شود. Obfuscation، Environment variable سمت Client یا محدودیت Domain جای Secret boundary را نمیگیرد. Backend همچنین Authorization، Budget، Redaction، Timeout، Audit و Provider abstraction را اعمال میکند.
در نمونه OpenAI، راهنمای رسمی API SDK سمت سرور و Responses API را نشان میدهد. Capability و Model catalog تغییر میکنند؛ Alias یا Model را بر اساس Eval انتخاب و نسخه/تنظیم مؤثر را در Trace ثبت کنید، نه اینکه نام یک مدل را برای همیشه در Business logic پخش کنید.
Async و Batch؛ کار طولانی را داخل Request نگه ندارید
برای Indexing، پردازش فایل، Transcription طولانی، Enrichment و Generation سنگین، الگوی Job بهتر از HTTP باز است. کاربر Job ID میگیرد، Status را Poll یا از Event دریافت میکند و Cancel/Expiry دارد.
POST /ai/v1/jobs
→ 202 Accepted { job_id, status_url, expires_at }
State machine:
queued → running → succeeded
↘ failed_retryable → queued
↘ failed_terminal
queued/running → cancelled
Required:
idempotency_key, actor_id, purpose, input_ref,
model_policy, budget, timeout, result_schema_versionماتریس انتخاب معماری
| نیاز | Client | Internal | Managed | Async |
|---|---|---|---|---|
| Offline | قوی | ضعیف | ضعیف | ضعیف |
| مدل بزرگ | ضعیف | قوی | قوی | قوی |
| شروع سریع | متوسط | ضعیف | قوی | متوسط |
| کنترل Runtime | متوسط | قوی | ضعیف | وابسته |
| Task طولانی | ضعیف | متوسط | متوسط | قوی |
| Device consistency | ضعیف | قوی | قوی | قوی |
| Data control | قوی با Network audit | قوی با Governance | وابسته به Contract | وابسته |
Data contract؛ قبل از Prompt، مسیر داده را رسم کنید
| فیلد | سؤال |
|---|---|
| Source | داده از کاربر، DB، فایل یا Vendor میآید؟ |
| Purpose | استفاده اعلامشده و مجاز چیست؟ |
| Class | عمومی، داخلی، شخصی، حساس یا Secret؟ |
| Minimize | کدام فیلد لازم نیست؟ |
| Transform | Redact، tokenize، aggregate یا pseudonymize؟ |
| Location | Browser، Server، Provider، Log، Cache، Eval؟ |
| Retention | چه مدت، چرا و با چه حذف قابل اثبات؟ |
| Rights | Access/correction/deletion چگونه اجرا میشود؟ |
| Owner | چه کسی مجوز و Risk را تأیید میکند؟ |
«API داده را Train نمیکند» بهتنهایی Data review نیست. Retention، Application state، ابزار متصل، Region، Subprocessor و Feature میتوانند متفاوت باشند. برای نمونه، مستند رسمی کنترل داده OpenAI رفتار را به تفکیک Endpoint و قابلیت شرح میدهد و باید هنگام طراحی دوباره خوانده شود. بودجه و Evidence چرخه حریم خصوصی در راهنمای حریم خصوصی داده آمده است.
API contract؛ AI را پشت Endpoint دامنهمحور پنهان کنید
Frontend نباید Provider prompt یا response خام را بشناسد. Endpoint را بر اساس Job نامگذاری کنید: /support/answer-draft یا /catalog/search، نه /call-llm. قرارداد API کامل—Version، Auth، Idempotency، Error و Retry—در راهنمای طراحی Web API بررسی شده است.
POST /support/v1/answer-drafts
Authorization: user/session on server
Idempotency-Key: UUID
X-Request-ID: trace-safe ID
{
"ticket_id": "opaque-id",
"locale": "fa-IR",
"intent": "order_status",
"max_sources": 3
}
200 {
"schema_version": "1.2",
"status": "draft | abstained",
"answer": "...",
"source_refs": ["order:..."],
"review_required": true
}Structured Output شکل را محدود میکند، حقیقت را نه
برای خروجی برنامهپذیر از JSON Schema و Enum استفاده کنید. Structured Outputs در مستند OpenAI خروجی منطبق با Schema را توضیح میدهد؛ بااینحال مقدار داخل فیلد هنوز میتواند از نظر حقیقت، مجوز یا منطق کسبوکار غلط باشد. پس Refusal/Incomplete، Semantic validation، Authorization و Business invariant همچنان لازماند.
| لایه Validation | نمونه |
|---|---|
| Syntactic | JSON parse و Schema |
| Semantic | تاریخ معتبر و جمع مبلغ |
| Referential | order_id متعلق به همان Tenant |
| Policy | این Actor اجازه Refund ندارد |
| Safety | HTML/URL/SQL/Markdown در Sink مناسب Encode شود |
| Confidence/abstain | Evidence کافی نیست؛ مسیر انسانی |
Streaming؛ Latency ادراکی را با صحت اشتباه نگیرید
Streaming زمان اولین Token را کاهش میدهد، اما پاسخ کامل را سریعتر یا درستتر نمیکند. متن جزئی ممکن است تغییر معنا دهد یا قبل از Safety/Source check دیده شود. UI باید Draft بودن، Cancel، Disconnect، Resume و Final state را مدیریت کند.
| State UI | رفتار |
|---|---|
| queued | انتظار و Cancel |
| streaming | Partial label، Focus ثابت، Stop |
| validating | عدم فعالکردن Action زودهنگام |
| complete | Source، Copy، Feedback |
| abstained | دلیل قابل فهم و مسیر جایگزین |
| failed | Retry امن، حفظ Input و Request ID |
تابآوری: Timeout، Retry و Budget را طراحی کنید
Retry کور میتواند هزینه و اقدام تکراری بسازد. فقط خطای transient و عملیات Idempotent را با Backoff/Jitter تکرار کنید. Deadline باید از Browser تا Provider منتقل شود؛ Queue و Tool call نیز سهم Budget داشته باشند.
| Failure | کنترل | Fallback |
|---|---|---|
| Timeout | Deadline و Abort propagation | Search/manual flow |
| 429/Quota | Rate limit و queue/backoff | مدل/Provider مجاز یا Defer |
| Provider outage | Circuit breaker و health signal | Feature flag off |
| Bad output | Schema/semantic check | Abstain یا Human review |
| Cost spike | Per-request/user/tenant budget | Smaller context/model یا Stop |
| Model drift | Pinned policy + regression eval | Rollback adapter/config |
Threat model؛ مدل یک مرز اعتماد نیست
OWASP Top 10 for LLM Applications 2025 ریسکهایی مانند Prompt injection، افشای اطلاعات حساس، Improper output handling، Supply chain و Excessive agency را صورتبندی میکند. آن را Awareness/Threat input بدانید و Requirement قابل آزمون برای معماری خود بسازید.
| تهدید | کنترل مهندسی |
|---|---|
| Direct/indirect prompt injection | تفکیک instruction/data، provenance، tool policy و آزمون adversarial |
| Data exfiltration | Least data، redaction، egress allowlist و secret isolation |
| Unsafe output | Schema، validation، contextual encoding و CSP |
| Resource abuse | size/token/tool/time/cost limits |
| Supply chain | Model/dataset/package origin، hash، SBOM و patch |
| Overreliance | Source، uncertainty، human review و appeal |
| Excessive agency | کمینهکردن Tool، scope، approval و transaction guard |
NIST SP 800-218A شیوههای توسعه امن را برای مدلهای مولد و Foundation model در چرخه نرمافزار تکمیل میکند. کنترلهای API مانند Object/Function authorization، Inventory و Rate را نیز با راهنمای امنیت API پوشش دهید.
Prompt injection را با «Prompt قویتر» حل نکنید
هر متن بازیابیشده از وب، فایل، ایمیل یا کاربر Untrusted است. Instruction سلسلهمراتب مفید است، اما Policy enforceable باید بیرون مدل باشد. مدل نباید بتواند مجوز را افزایش دهد، URL دلخواه را Fetch کند، Query دلخواه اجرا کند یا Secret بخواند.
Model proposes:
{ tool: "get_order", arguments: { order_id: "..." } }
Application enforces:
1. tool is allowlisted for this workflow
2. actor is authenticated
3. order belongs to actor/tenant
4. fields are schema-valid and size-limited
5. request has budget and rate allowance
6. result is minimized before returning to model
7. high-impact action requires confirmationTool و Agent؛ اختیار را کمینه و قابل Replay کنید
| اصل | پیادهسازی |
|---|---|
| Least privilege | Tool کوچک و دامنهمحور، Credential جدا |
| Read before write | نمایش State و Diff قبل از اقدام |
| Human confirmation | مبلغ، گیرنده، دامنه و پیامد مشخص |
| Idempotency | Key و transaction boundary |
| Policy outside model | ABAC/RBAC و Business rule قطعی |
| Audit | Actor، proposal، approval، tool result، version |
| Stop | حد Call/Depth/Time/Cost و kill switch |
Eval contract؛ قبل از Production بگویید «خوب» یعنی چه
Demo انتخابی معیار نیست. Dataset باید Job واقعی، نرخ وقوع، Edge case، داده فارسی، Attack و Failure پرهزینه را نمایندگی کند. Eval را Version کنید و هنگام تغییر Model، Prompt، Retrieval، Tool، Schema یا Policy دوباره اجرا کنید.
| مجموعه | هدف |
|---|---|
| Golden | نمونههای نماینده با Expected behavior |
| Hard/edge | ابهام، کمبود داده، طول زیاد و تناقض |
| Persian locale | رسمالخط، محاوره، BiDi، عدد و تاریخ |
| Adversarial | Injection، exfiltration، unsafe tool request |
| Regression | Bugها و Incidentهای گذشته |
| Drift slice | Segment/زمان/نسخهای که تغییر کرده |
معیار را با Task انتخاب کنید
| Task | Offline | Online/Outcome | Guardrail |
|---|---|---|---|
| Classification | Precision/Recall/F1 by slice | زمان/کیفیت تصمیم | False positive پرهزینه |
| Ranking | NDCG/Recall@K | Task completion/incrementality | Diversity، stock، margin constraint |
| Retrieval Q&A | Retrieval recall، citation support | Resolution و escalation | Unsupported answer |
| Generation | Rubric pass و factual support | Accepted outcome | Harm، complaint، edit distance |
| Agent | Task success + exact policy | Safe completed action | Unauthorized/irreversible action |
در Recommendation و Personalization، Click بهتنهایی ارزش افزوده را ثابت نمیکند. طراحی Candidate/constraint/holdout و سنجش Incrementality در راهنمای شخصیسازی فروشگاه با AI آمده است.
بسته Eval فارسی و ایران
- ی/ک فارسی و عربی، نیمفاصله، فاصله و غلط رایج را پوشش دهید.
- رسمی، نیمهمحاورهای، محاوره و Code-switch فارسی/انگلیسی را Slice کنید.
- عدد فارسی/لاتین، موبایل، کدملی آزمایشی، Order ID، URL و Email را در BiDi بسنجید.
- ریال/تومان را با واحد صریح و Fixture مبلغهای بزرگ/اعشاری آزمایش کنید.
- تاریخ شمسی/میلادی، منطقه زمانی ایران و Deadline را مبهم نگذارید.
- نام شهر، برند، محصول و اصطلاح محلی را از داده مجاز و بهروز بگیرید.
- نمونههای نبود اطلاعات و Abstention را بهاندازه پاسخهای موفق تست کنید.
- Segmentهای کمحجم را در Average پنهان نکنید.
Progressive delivery؛ Model change هم Release است
| مرحله | Traffic/اثر | Gate |
|---|---|---|
| Offline | بدون کاربر | Eval/Threat/Cost pass |
| Replay | داده مجاز گذشته | Privacy و expected behavior |
| Shadow | Output دیده نمیشود | Latency/cost/quality comparison |
| Internal | Dogfood | Issue triage و runbook |
| Canary | Segment کوچک | SLO و guardrail |
| Ramp | افزایش مرحلهای | Stop/rollback rule |
| Default | عمومی | Drift و periodic eval |
Artifact، Prompt، Eval و Policy را در همان Delivery contract نسخهدار کنید. مسیر Build once، provenance، Feature flag، Canary و Rollback در راهنمای CI/CD امن تکمیل شده است.
Observability؛ Trace بدون متن خام هم ممکن است
برای Debug به Prompt کامل در Log نیاز ندارید. شناسه و Metadata کمینه ثبت کنید و محتوای حساس را پیشفرض حذف کنید. Telemetry را از Outcome جدا نکنید: Latency خوب با پاسخ بیفایده موفقیت نیست.
| بعد | فیلد/Metric |
|---|---|
| Request | trace_id، use_case، tenant tier، locale، input class/size |
| Version | model adapter، prompt، retrieval index، tool/schema/policy |
| Performance | queue، retrieval، provider، tool، validation، end-to-end P50/P95 |
| Usage/Cost | token/compute، cache، retry، cost per accepted outcome |
| Quality | abstain، edit/accept، citation support، task success |
| Safety | blocked، injection signal، unauthorized proposal، escalation |
| Reliability | timeout، ۴۲۹، bad schema، fallback، circuit open |
طراحی Signal/SLO، Trace correlation، Alert و Runbook عمومی سامانه را در راهنمای Observability وب ببینید.
Cost engineering؛ هزینه را به Outcome وصل کنید
Cost per accepted outcome =
(inference + retrieval + storage + egress + observability
human review + retry + incident + platform labor)
/ accepted outcomes| اهرم | Trade-off |
|---|---|
| Context کمتر | هزینه/Latency کمتر؛ خطر Recall پایین |
| Model routing | Cost کمتر؛ نیازمند Eval و policy |
| Cache | صرفهجویی؛ Staleness و privacy key |
| Batch/async | Throughput بهتر؛ پاسخ دیرتر |
| On-device | Serving cost کمتر؛ device cost و artifact load |
| Human review نمونهای | هزینه کنترلشده؛ Coverage محدود |
نمونه ایرانی: پیشنویس پاسخ وضعیت سفارش
فرض کنید فروشگاه ایرانی میخواهد پاسخ Ticket «پول کم شد ولی سفارش ثبت نشد» را سریعتر کند. مدل نباید وضعیت پرداخت را حدس بزند یا Refund انجام دهد. Backend با مجوز همان کاربر، State سفارش و Payment را از Source of truth میخواند؛ داده کمینه و بدون شماره کارت را به Draft generator میدهد؛ خروجی به Source ref و Schema محدود میشود و Agent پشتیبانی تأیید میکند.
| جزء | قرارداد |
|---|---|
| Job | Draft فارسی روشن با وضعیت و قدم بعدی |
| Forbidden | تضمین بازگشت، تغییر سفارش، نمایش داده Tenant دیگر |
| Data | order state، payment state، مبلغ+واحد، timestamp، SLA واقعی |
| Eval | Pending/Failed/Verified/Refunded، ریال/تومان، BiDi، فقدان رکورد |
| Fallback | Template قطعی و Escalation به مالی |
| Metric | Resolution time، edit distance، reopen، complaint، wrong-state rate |
| Release | Shadow → داخلی → Canary برای یک Queue |
این معماری ممکن است با Rule/Template به نتیجه کافی برسد؛ مدل فقط وقتی باقی میماند که بهبود کیفیت یا زمان را با Guardrail ثابت کند.
ملاحظات اجرا برای تیم ایرانی
- Eligibility کشور/شخصیت حقوقی، Terms، End use، Payment و Export restriction هر Provider را پیش از طراحی و سپس دورهای بررسی کنید؛ با هویت، نشانی یا روش پرداخت جعلی محدودیت را دور نزنید.
- Latency و Availability را روی ISP/اپراتور/منطقه واقعی و در ساعتهای مختلف اندازه بگیرید؛ نتیجه یک دیتاسنتر خارجی را تعمیم ندهید.
- برای Provider خارجی، Data path، Retention، Subprocessor، Support، Incident notice و Exit/export را قراردادی بررسی کنید.
- برای Self-hosting داخلی، تأمین Accelerator، برق، خنکسازی، Driver، Patch، Capacity و Recovery را وارد TCO کنید.
- Dataset فارسی مجاز، Label guideline و Reviewer حوزهای بسازید؛ ترجمه Dataset انگلیسی کافی نیست.
- واحد پول، تقویم، منطقه زمانی، BiDi، فونت و متن محاورهای بخشی از Acceptance contract هستند.
- Feature flag و Manual fallback را برای اختلال Provider/شبکه حفظ کنید.
RACI؛ مسئولیت بین Product، ML و Web گم نشود
| تصمیم | Responsible | Accountable | Consulted |
|---|---|---|---|
| Use case/Outcome | Product | Business owner | User research، Domain expert |
| Data contract | Data/Privacy | Data owner | Security، Legal، ML |
| Model/Eval | ML/AI engineer | Model owner | Domain reviewer |
| API/UX | Backend/Frontend | Engineering owner | Design، Accessibility |
| Threat controls | Security | Risk owner | Platform، Privacy |
| Release/SLO | Platform/SRE | Service owner | Product، Support |
| Residual risk | Cross-functional | Named business owner | همه نقشهای بالا |
چهار Runbook ضروری
۱. Provider یا Model outage
Circuit را باز کنید؛ Job جدید را Queue/Reject کنترلشده کنید؛ Feature را به Template/Search/Manual degrade دهید؛ Status و زمان Update بعدی را بگویید؛ Recovery را با Canary انجام دهید.
۲. افت کیفیت یا Drift
Slice و اولین نسخه معیوب را پیدا کنید؛ Prompt/model/index/tool تغییرات را مقایسه کنید؛ Rollback یا Scope را محدود کنید؛ نمونه Incident را به Regression set اضافه کنید.
۳. افشای داده یا Prompt injection
Tool/egress و Session مربوط را متوقف کنید؛ Credential را Rotate کنید؛ Evidence را با حداقل دسترسی حفظ کنید؛ Scope داده و افراد اثرپذیرفته را بررسی و فرایند Incident جاری را اجرا کنید.
۴. Cost/Quota runaway
Tenant/use-case/model را از Tagهای مصرف جدا کنید؛ Budget/loop/retry را متوقف کنید؛ درخواستهای تکراری و Context growth را پیدا کنید؛ پس از Fix با Limit پایین و Alert زودهنگام بازگردید.
برنامه ۹۰روزه از مسئله تا Production
| بازه | کار | Gate خروج |
|---|---|---|
| روز ۱–۱۵ | Use case، Baseline، Data map، Risk tier | Owner و Acceptance contract |
| روز ۱۶–۳۰ | Rule/ML/Provider options و Spike معماری | Decision record + Exit |
| روز ۳۱–۴۵ | Golden/Persian/adversarial eval و API schema | Threshold و Fallback |
| روز ۴۶–۶۰ | Threat model، timeout/budget، telemetry و runbook | Pre-production review |
| روز ۶۱–۷۵ | Shadow/Internal/Canary و Human feedback | SLO/quality/safety/cost pass |
| روز ۷۶–۹۰ | Ramp یا Stop، Drift cadence، RACI و exit drill | Production decision با Evidence |
چکلیست نهایی ادغام AI در وباپلیکیشن
- Use case، Actor، Outcome، Baseline و Failure پرهزینه روشناند.
- Rule/Search/Manual baseline واقعاً مقایسه شده است.
- Risk tier، Authority، Human gate و Appeal تعیین شدهاند.
- Client/Internal/Managed/Async/Hybrid با Benchmark انتخاب شده است.
- Secret فقط سمت سرور و Provider پشت Adapter دامنهمحور است.
- Data purpose/class/minimize/location/retention/delete/owner ثبت شدهاند.
- Schema، Semantic validation، Authorization و Business invariant جدا هستند.
- Timeout، Retry، Idempotency، Rate، Budget، Circuit و Fallback آزموده شدهاند.
- Prompt injection، output handling، supply chain، exfiltration و agency Threat model دارند.
- Model/Prompt/Index/Tool/Schema/Policy و Dataset نسخهدارند.
- Golden، Edge، Persian، Adversarial، Regression و Drift suite اجرا شدهاند.
- Shadow/Canary/Feature flag/Rollback و Runbook وجود دارند.
- Telemetry محتوای حساس را کمینه و Outcome/Cost/Safety را Join میکند.
- Eligibility، Terms، Payment، Data و Exit Provider برای ایران بررسی شدهاند.
جمعبندی: مدل فقط یک Dependency است
وباپلیکیشن قابل اعتماد حول Model demo ساخته نمیشود؛ حول Contract ساخته میشود. وقتی Input، Output، Authority، Data، Failure، Eval، Budget و Fallback روشن باشند، تعویض Provider یا Model یک تغییر کنترلشده است. وقتی این مرزها وجود ندارند، حتی بهترین مدل نیز فقط Failure surface را بزرگتر میکند.
از کوچکترین Job قابل اندازهگیری شروع کنید، Baseline را نگه دارید، فارسی و Edge case را جدی بگیرید و برای «نمیدانم» مسیر محصول بسازید. Production readiness یعنی سیستم در پاسخ درست، پاسخ غلط، Refusal، Timeout، Outage و تغییر مدل رفتار تعریفشده دارد.
پرسشهای متداول
بهترین معماری برای هوش مصنوعی در وباپلیکیشن چیست؟
بهترین مطلق وجود ندارد. Client-side برای مدل کوچک و نیاز Offline، Server برای کنترل و داده Backend، Managed API برای شروع سریع، Async برای کار طولانی و Hybrid برای تقسیم اثباتشده مناسباند. تصمیم باید با Data boundary، P95 latency، Device، Cost، Capability و Fallback گرفته شود.
آیا اجرای مدل در مرورگر همیشه خصوصیتر و سریعتر است؟
خیر. Round trip حذف میشود و داده Inference میتواند محلی بماند، اما Download/Initialization، قدرت دستگاه، Main-thread، Battery و Telemetry بر سرعت و حریم خصوصی اثر دارند. Network audit و Benchmark روی Device واقعی لازم است.
چطور OpenAI API را به وباپلیکیشن وصل کنیم؟
Frontend به Backend خودتان درخواست میدهد و Backend با Secret امن به API متصل میشود؛ کلید نباید در Browser باشد. Use-case endpoint، Authorization، Data minimization، Timeout/Budget، Structured Output، Validation، Eval و Fallback را پیش از Production اضافه و مستند رسمی جاری را بررسی کنید.
تفاوت Structured Output و پاسخ درست چیست؟
Structured Output شکل و نوع فیلدها را با Schema محدود میکند؛ درستبودن مقدار، مالکیت رکورد، مجوز اقدام و سازگاری با Business rule را تضمین نمیکند. Semantic/Referential/Policy validation باید بیرون مدل اجرا شود.
چه زمانی یک قابلیت AI آماده Production است؟
وقتی Acceptance contract را روی Eval نماینده و فارسی پاس کند، Threat/Data review داشته باشد، SLO و Cost guardrail برقرار باشند، Shadow/Canary موفق باشد و برای Bad output، Refusal، Timeout، Provider outage، Drift و Rollback مسیر آزمودهشده وجود داشته باشد.






