CodeCrafters

https://www.kdnuggets.com/top-7-python-frameworks-for-ai-agents خیلی از شرکت‌ها و سازمان‌ها و پلتفرم‌ها هوشمند متکی و وابسته به بخشی ازین فریمورک‌ها هستند @code_crafters

تکنیک‌های Prompt Engineering 1) Zero-shot Prompting تعریف به مدل دستور می‌دهیم بدون هیچ مثال قبلی کار را انجام دهد. ساختار: Instruction + Question مثال Explain Docker networking. مدل خودش از دانش قبلی استفاده می‌کند. کاربرد سؤال‌های عمومی کارهای ساده زمانی که مثال لازم نیست 2) Few-shot Prompting تعریف به مدل چند مثال می‌دهیم تا سبک، فرمت یا الگو را یاد بگیرد. ساختار: Example 1 Example 2 Example 3 New Task مثال Example: Input: Create user model. Output: class User(models.Model): ... Now: Create Product model. کاربرد تولید کد دسته‌بندی متن خروجی با فرمت خاص 3) Chain of Thought (CoT) تعریف مدل را تشویق می‌کنیم مسئله را مرحله‌ای تحلیل کند. ایده: Problem ↓ Reasoning ↓ Answer مثال Solve this problem step by step. A company has 100 servers. 20% fail. How many remain? کاربرد مسائل ریاضی تحلیل معماری تصمیم‌گیری 4) Self Consistency تعریف به جای گرفتن یک مسیر استدلال، چند پاسخ تولید می‌کنیم و بهترین را انتخاب می‌کنیم. ساختار: Prompt ↓ Answer A Answer B Answer C ↓ Vote ↓ Final Answer مثال Solve this problem using three different approaches. Compare them. Select the most reliable answer. تفاوت با CoT CoT: یک مسیر فکر Self Consistency: چند مسیر فکر + انتخاب 5) Tree of Thoughts (ToT) تعریف به جای چند جواب مستقل، یک درخت از مسیرهای حل ایجاد می‌کنیم. مثلاً برای طراحی سیستم: Solution / | \ Design A Design B Design C ↓ Evaluate ↓ Best Design مثال Design three architectures. Evaluate: - Cost - Security - Scalability Choose the best. 6) Meta Prompting تعریف به مدل دستور می‌دهیم چگونه فکر کند یا چگونه مسئله را حل کند. یعنی: پرامپت درباره روش حل است. مثال Before answering: 1. Analyze requirements. 2. Identify risks. 3. Create solution. 4. Review your answer. 7) Generated Knowledge Prompting تعریف قبل از پاسخ، مدل ابتدا دانش مرتبط تولید می‌کند. ساختار: Question ↓ Generate Knowledge ↓ Answer مثال First generate important facts about Kubernetes security. Then explain Kubernetes security. 8) Prompt Chaining تعری

چندسال پیش با یک سریالی آشنا شدم به اسم «مرگ،عشق،ربات‌ها» دوره ظهور چت‌بات‌های هوشمند بود راجب دو بخش از این سریال براتون بگم تو یکی از اپیزودهاش که یک صحنه آخرالزمانی بود انتهای داستان وقتی رییس اصلی رو نشون داد یک گربه بود که این جمله رو گفت «چیه فکر میکردی ایلان ماسکه؟؟؟» تو مقاله اخیر اکونومیست انگار هوش مصنوعی رو چسبوندن به ایلان ماسک، سرمایه گذاری بزرگی انجام داده و راجب افکار پیچیده و بزرگی صحبت کرد که گویا هوش مصنوعی و ربات‌ها به زودی قراره به شکل گسترده‌ای در زندگی ما حضور داشته باشند(در یکی از اتفاقات اخیر که یک ربات رو به صورت آزمایشی در یک کارخونه تست کردن اتفاق جالبی افتاد، قرار بود این ربات یک آزمایش هشت ساعته پشت سر بگذرونه، اما ربات به مدت ۲۰۰ ساعت بدون کوچکترین وقفه‌ای کار کرد و هیچ ضریب خطایی از خودش نشون نداد) در داخل یکی دیگه از اپیزودها رییس جمهور ایلات متحده دیگه انسان نبود، بلکه یک هسته هوش مصنوعی بود که جهان رو کنترل میکرد، عامل‌های هوشمند به زودی پیچیدگی تفکر اونها به بزرگی ذهن انسان خواهد رسید و خیلی زودتر از مغز انسان هم پیشی خواهد گرفت، این میتونه عوامل مثبت و منفی داشته باشه، در خصوص عوامل منفیش منجر به بی معنایی در انسان میشه که ممکن هست آمار جنایت افزایش پیدا کنه، دو کشور مطرح در زمینه عامل‌های هوشمند یکی آمریکا و دیگری چین هستش، آینده و کنترل جهانی در دست این دو کشور خواهد افتاد و مابقی کشورها از قدرت جهانی بعنوان رقیب حذف خواهند شد (سرمایه گذاری در زمینه هوش مصنوعی امروزه به یک الزام بزرگ تبدیل شده و هر کشوری در این زمینه کوتاهی کنه با عواقب آن روبرو خواهد شد) شرکت انودیا در یک همایش از یک ربات هوشمند رونمایی کرد که دو هسته هوشمند برای پردازش روی آن نصب بود، ربات بصورت خام فعال شد و در لحظه در حال یادگیری در محیط و ارتباط گرفتن با انسان بود، ربات در کمتر از چند دقیقه به واکنش احساسی دست پیدا کرد یک واقعیت به زودی هوش مصنوعی فراگیرتر و توانمندتر خواهد شد، شروع به یادگیری هوش مصنوعی ضروری هستش و خیلی بدبینانه بهش نگاه کنم منجر میشه کمی دیرتر بیکار بشید پیگیر اخبار هوش مصنوعی باشید @code_crafters

🧩 Kubernetes Design Patterns که باید بشناسید وقتی با Kubernetes کار می‌کنیم، فقط Deployment و Service مهم نیستند. Kubernetes یک‌سری Pattern دارد که برای حل مسائل رایج در معماری و اجرای Applicationها استفاده می‌شوند. در این پست چند Pattern مهم را با مثال مرور می‌کنیم 👇 1️⃣ Sidecar Pattern در این الگو یک Container جانبی کنار Container اصلی و در همان Pod اجرا می‌شود. Pod ┌──────────────────────────┐ │ │ │ Application │ │ │ │ │ ▼ │ │ Sidecar │ │ │ └──────────────────────────┘ مثال Application لاگ تولید می‌کند و Sidecar مسئول ارسال آن به Loki است: App │ │ logs ▼ Shared Volume │ ▼ Fluent Bit │ ▼ Loki کاربردها: Log Collection Proxy Service Mesh Monitoring Security Agent 📌 نکته: Sidecar یک Deployment Pattern است؛ یعنی می‌گوید Container جانبی کجا قرار گرفته است. 2️⃣ Adapter Pattern Adapter برای تبدیل Interface یا Format استفاده می‌شود. فرض کنید Application متریک‌ها را با فرمت اختصاصی خودش تولید می‌کند: requests=100 errors=5 ولی Monitoring شما Prometheus Format می‌خواهد. Application │ ▼ Adapter │ ▼ Prometheus Format │ ▼ Prometheus Application را تغییر نمی‌دهیم؛ Adapter خروجی آن را به چیزی که سیستم مقصد انتظار دارد تبدیل می‌کند. کاربردها: تبدیل Metrics تبدیل Logs تبدیل Protocol تبدیل API Format 📌 Adapter می‌تواند خودش به‌صورت یک Sidecar Container پیاده‌سازی شود. 3️⃣ Ambassador Pattern Ambassador به نمایندگی از Application با یک سرویس خارجی ارتباط برقرار می‌کند. مثلاً Application باید به Redis خارج از Kubernetes وصل شود: Pod ┌──────────────────────────┐ │ │ │ Application │ │ │ │ │ ▼ │ │ Ambassador │ │ │ └──────┼───────────────────┘ │ ▼ External Redis Application فقط می‌داند: localhost:6379 ولی Ambassador می‌داند Redis واقعی کجاست: 10.10.20.30:6379 Ambassador می‌تواند مسئول موا

دو موضوع مهم در طراحی Agentهای هوشمند در پست‌های قبلی تا حدودی درباره تفاوت جستجوی کلمات مشابه و جستجوی مبتنی بر مفهوم (Semantic Search) صحبت کردیم. در سیستم‌های واقعی، برای رسیدن به نتایج بهتر معمولاً از Hybrid Search استفاده می‌کنیم تا بتوانیم از قدرت و انعطاف هر دو رویکرد بهره ببریم. اما دو موضوع مهم دیگر در طراحی Agentها وجود دارد که نقش بسیار مهمی در کیفیت و امنیت سیستم دارند: --- 1️⃣ Reranking؛ پیدا کردن مرتبط‌ترین نتایج فرض کنید ۶ داکیومنت در اختیار داریم. با جستجوی کلمه‌ای (Keyword Search)، داکیومنت‌های ۱ و ۳ پیدا می‌شوند. با جستجوی مفهومی (Semantic Search)، داکیومنت‌های ۲ و ۴ به دست می‌آیند. حالا سؤال این است: در نهایت کدام داکیومنت‌ها واقعاً بهترین پاسخ را برای سؤال کاربر دارند؟ اینجاست که Reranking وارد می‌شود. در Reranking، نتایج اولیه بر اساس میزان ارتباط و کیفیت، مجدداً امتیازدهی و مرتب می‌شوند. به طور کلی دو رویکرد برای ساخت سیستم Reranking داریم: 🔹 رویکرد اول: ساخت مدل امتیازدهی داخلی می‌توان از متخصصان و افراد سازمان خواست نتایج مختلف را ارزیابی و امتیازدهی کنند. سپس با جمع‌آوری این داده‌ها می‌توان یک مدل یا سیستم امتیازدهی متناسب با نیازهای همان سازمان ایجاد کرد. 🔹 رویکرد دوم: استفاده از مدل‌های آماده می‌توان از مدل‌های آماده و Open Source موجود در اکوسیستم Hugging Face استفاده کرد، مانند: * Sentence Transformers * BGE Reranker از BAAI * و مدل‌های مشابه در نهایت Reranker مانند یک فیلتر هوشمند عمل می‌کند و از میان نتایج اولیه، مرتبط‌ترین موارد را انتخاب می‌کند. این موضوع اهمیت زیادی دارد؛ چون قرار نیست تمام اطلاعات بازیابی‌شده را به مدل اصلی منتقل کنیم. برای مثال: User Query ↓ Hybrid Search ↓ 20 Documents ↓ Reranker ↓ Top 5 Documents ↓ LLM / Agent در نتیجه، هم کیفیت Context افزایش پیدا می‌کند و هم حجم اطلاعاتی که به مدل اصلی منتقل می‌شود کاهش می‌یابد؛ موضوعی که می‌تواند روی هزینه، سرعت و کیفیت پاسخ تأثیر مستقیم داشته باشد. --- 2️⃣ Guardrail؛ کنترل رفتار و خروجی Agent موضوع مهم دوم Guardrail است. مدل‌های هوش مصنوعی عاری از خطا نیستند؛ حتی مدل‌های قدرتمند نیز ممکن است دچار Hallucination شوند یا در شرایط خ

در عمل چند نوع توهم مهم در RAG , agent داریم که هرکدام منشأ متفاوتی دارند. 1. انواع Hallucination در RAG در RAG معمولاً این زنجیره را داریم: User → Retrieval → Context → LLM → Answer بنابراین توهم می‌تواند در هر مرحله ایجاد شود. 1. Retrieval Hallucination / Retrieval Failure مدل اطلاعات غلط تولید نکرده؛ مشکل این است که اطلاعات درست را پیدا نکرده. مثلاً کاربر می‌پرسد: «شرایط مرخصی در شرکت چیست؟» اما Retriever سند مربوط به «قوانین اضافه‌کاری» را برمی‌گرداند. مدل هم بر اساس همان Context پاسخ می‌دهد. Question ↓ Retriever ↓ ❌ Wrong Documents ↓ LLM ↓ Wrong Answer این یکی از مهم‌ترین مشکلات RAG است. 2. Contextual Hallucination سند درست به مدل داده شده، اما مدل از Context برداشت اشتباه می‌کند. مثلاً سند می‌گوید: Employees receive 20 days of annual leave. اما مدل جواب می‌دهد: Employees receive 30 days. یعنی: Correct Context ↓ LLM misinterprets ↓ ❌ Wrong Answer 3. Unsupported / Faithfulness Hallucination اطلاعاتی در Context وجود ندارد، ولی مدل آن را به پاسخ اضافه می‌کند. مثلاً Context: Product X supports OAuth2. مدل: Product X supports OAuth2, SAML and LDAP. در حالی که SAML و LDAP اصلاً در Context نبوده‌اند. این مورد در RAG خیلی مهم است. 4. Source Attribution Hallucination مدل جواب نسبتاً درستی می‌دهد، اما منبع را اشتباه نسبت می‌دهد. مثلاً: Document A: OAuth2 supported Document B: LDAP supported مدل می‌گوید: According to Document A, the system supports LDAP. در حالی که LDAP در Document B بوده. 5. Citation Hallucination مدل citation تولید می‌کند، ولی citation واقعاً آن ادعا را پشتیبانی نمی‌کند. مثلاً: Answer: The system supports 10,000 users. [Source 3] اما Source 3 اصلاً درباره تعداد کاربران چیزی نگفته است. این در سیستم‌های RAG production بسیار مهم است. 6. Knowledge Cutoff / External Knowledge Hallucination مدل اطلاعاتی را از دانش خودش وارد می‌کند، در حالی که RAG قرار بوده فقط بر اساس اسناد داخلی پاسخ دهد. مثلاً: Internal company documentation ↓ RAG ↓ LLM ↓ + pretrained knowledge ↓ Answer مدل ممکن است بگوید: طبق سی