CodeCrafters

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

کاش داخل یوتیوب یه فیلتر داشت که هندی‌هارو نبینی و داخل لینکدین هم یه فیلتر داشت که ایرانی‌هارو نمیدیدی 😅😅😅

وضعیت آگهی‌های استخدامی عجیب شده یه سرکت هر چند وقت یبار آگهی میزنه برای فول‌استک، و هنوز به این باور نرسیده که فول استک کار درک عمیقی از سیستم و ابزارهاش نداره و نمیتونه یه تنه یه سیستم رو کد بزنه، در نهایت فقط میتونه mvp تحویل بده یا شرکت آگهی زده مدیرفنی میخواد و ازش انتظار داره کد بزنه، یعنی شرکت انقدر اوضاعش داغونه که از مدیر ارشدش بجای بهره وری در جلسات فنی با ذی نفعان و مشتریانش، مدیر ارشدش رو‌ میزاره پای کد زدن و بالا آوردن سیستم بیکار بودن بهتر از کار کردن تو همچین شرکت‌هایی هستش که رفتارهای فرسایشی دارن و با روح و روانتون بازی میکنن #موقت

اینترنت کشور توسط جنگنده‌های اسراییلی و متخاصم کنترل میشه هرچی خبر بدن که دارن نزدیک کشور میشن، نت ضعیف تر میشه بعد اسم این رو گذاشتن اقتدار 😐😐😐 #موقت

حمید رسایی طبق گفته سخنگوی قوه قضایی ۶۰ پرونده مجرمیت داره به طول ۱۵ سال، که در چند پرونده هم محکوم شده یعنی طرف یک مجرم اصلاح ناپذیر هستش که جالبه آخوند هم هستش و خلع لباس هم نشده بعنوان یک مجرم اول اینکه داخل سیستم این نظام و حکومت چطور یک مجرم تونسته تو انتخابات نمایندگی مجلس شرکت کنه و قانون وضع کنه؟؟؟ شما فکر کنید یک مجرم میخواد قانون وضع کنه، چه قانونی قراره وضع کنه؟؟؟ جالبتر اینکه این جانی از طرفداران قطع اینترنت بوده ، نمیدونم متوجه شدین یا بیشتر بگم که چرا یه جانی دنبال قطع اینترنت بوده؟؟؟ حالا کی باید جوابگوی این باشه که یک مجرم میتونه نماینده باشه، قانون وضع کنه و راجب شبکه ملی ارتباطات کارگروه داشته باشه و بعنوان یک راحب دینی هم فعالیت کنه #موقت

270 هزار تومن امیدوارم ۲۷۰ هزار راس آخوند تا فردا سقط بشن #موقت

اسکات بسنت گفته تا دو هفته دیگه اقتصاد ایران نابود میشه خب بزارید قابل درکتر براتون بگم این یعنی موج اول ابر تورم، یعنی آغاز از بین رفتن تمام سرمایه‌ای که نسل به نسل جمع کردین #موقت

محاصره دریایی تکمیل شده محاصره هوایی تکمیل شده محاصره اقتصادی تکمیل شده محاصره زمینی در حال تکمیل شدن ولی همچنان عن زاده‌های سران نظام در اروپا و آمریکا ته مانده‌ی دلارهای این کشور رو که حق مردم هست رو دارن خرج تفریحات خودشون میکنن #موقت

دوستان عزیزم سلام 👋 مقاله‌ی جدید منتشر شد؛ این بار درباره‌ی Cloudflare Workers. این هفته روی تسکی کار می‌کردم که برای انجامش لازم شد زمان زیادی را صرف مطالعه و تست Workers، routing، migration و ساختار Cloudflare کنم. در ابتدا هدف فقط حل همان مسئله بود، اما هرچه بیشتر جلو رفتم، متوجه شدم Workers خیلی فراتر از چیزی است که قبلاً از آن استفاده می‌کردم؛ مخصوصاً زمانی که بخواهیم بخشی از یک سیستم قدیمی را به‌صورت تدریجی به معماری جدید منتقل کنیم، بدون اینکه همه‌چیز را یک‌باره جابه‌جا کنیم. چند موضوع اصلی مقاله: • تفاوت Routes و Custom Domains • اینکه چطور می‌شود migration را route به route انجام داد • کلیت Bindings و Service Bindings کجا کاربرد دارند • چه زمان‌هایی Workers انتخاب مناسبی است و چه زمان‌هایی نه • و اینکه edge بودن همیشه به معنی performance بهتر نیست بخشی که برای خودم جالب‌تر بود، مدل migration بود. لازم نیست همیشه کل سیستم را در یک مرحله جایگزین کنیم و ریسک یک deployment بزرگ را بپذیریم. می‌شود چند route را به سیستم جدید منتقل کرد، رفتارشان را بررسی کرد و بعد به‌تدریج باقی مسیرها را جابه‌جا کرد. در مجموع، نگاه من به Cloudflare Workers از یک ابزار ساده برای redirect و rewrite، به یک لایه‌ی جدی‌تر در معماری تغییر کرد. خوشحال می‌شوم بخوانید و اگر تجربه‌ای با Workers، routing یا migration داشته‌اید، نظرتان را با من به اشتراک بگذارید 🙌 نکته: متن مقاله از نظر نگارشی با کمک AI بهبود داده شده، اما محتوای فنی بر اساس مطالعه، تست و مستندات Cloudflare تهیه شده. 🔗 مقاله: https://medium.com/@el_mohamad/stop-treating-cloudflare-workers-as-cdn-scripts-the-network-is-now-programmable-fe52fd14ed22 ✍️ @tech_negaasht

عروس معصومه ابتکار گوندی‌فاند گذاشته با این متن (ما برای زندگی و آینده بهتر فرزندمون اومدیم آمریکا، لطفا نزارید ما رو اخراج کنند) چهل هزار دلار هم بهش کمک شده که معلومه این پول از کجا و توسط کی بهش پرداخت شده فقط برام سواله چرا هیچ یک از سران نظام این خانواده هرزه رو پاسخگو نمیکنه #موقت

نه واقعا برام سواله تو کشوری که ۷۰ درصدش بیابونه و تولید برق یکی از بدیهی‌ترین تکنولوژی‌های دنیاست، نمیتونید برای ۳۰ درصد بقیه‌ش برق تولید کنید میخواید ما باور کنیم که موشک و پهپادهای مدرن ساختین؟؟؟ بعد میان میگن انسجام اجتماعی دقیقا از چی؟؟؟ از برقی که نداریم از آب، شغل، پول، خونه، ماشین، بنزین، آینده، رفاه، تورم کثافتای ملعون اگه باباهاتون اینارو نداشتن، مادراتون باهاشون انسجام نمیکردن که حاصلش بشه شما تخمه حرومیا

خب ترکیه هم مرزها رو بست الان فقط دو مرز باز داریم، یکی ارمنستان و دیگری پاکستان (برای تردد در پاکستان باید دو میلیارد پرداخت کنید)

از زمان ظهور عامل‌های مبتنی بر llm بازدید سایت over stack flow کاهش پیدا کرد و در سال ۲۰۲۶ تقریبا استفاده از این سایت به صفر رسیده بنظرتون تا چندساله دیگه نیروی انسان غیرقابل استفاده میشه؟؟؟ #موقت

بنابراین:

RAG hallucination بیشتر حول Knowledge + Retrieval + Grounding است.

ولی:

Agent hallucination علاوه بر Knowledge، حول Planning + Tools + State + Memory + Actions هم اتفاق می‌افتد.

4. یک مدل ذهنی خیلی خوب برای RAG:

┌── Retrieval Error
             │
Question ────┼── Context Error
             │
             ├── Generation Error
             │
             └── Citation Error

برای Agent:

┌── Planning
                │
                ├── Tool Selection
                │
                ├── Tool Arguments
User → Agent ───┼── Tool Result
                │
                ├── Memory
                │
                ├── State
                │
                └── Final Answer

پس در Agentic RAG حتی ترکیب این دو را داریم:

User
 ↓
Agent
 ↓
Query Generation
 ↓
Retriever
 ↓
Documents
 ↓
LLM
 ↓
Tool
 ↓
Observation
 ↓
Agent
 ↓
Final Answer

و در نتیجه ممکن است چند hallucination پشت سر هم رخ دهد. مثلاً:

Bad Query
   ↓
Wrong Retrieval
   ↓
Wrong Interpretation
   ↓
Wrong Tool
   ↓
Wrong Tool Arguments
   ↓
Wrong Observation
   ↓
Confident Wrong Answer

این دقیقاً دلیل اهمیت evaluation و hallucination mitigation در Agentic RAG است.

در عمل چند نوع توهم مهم در 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

مدل ممکن است بگوید:

طبق سیاست شرکت، X مجاز است.

در حالی که این اطلاعات از knowledge خودش آمده، نه مستندات شرکت. 2. انواع Hallucination در Agent در Agent قضیه پیچیده‌تر می‌شود. Agent فقط جواب تولید نمی‌کند؛ معمولاً:

Think
 ↓
Plan
 ↓
Tool
 ↓
Observe
 ↓
Think
 ↓
Tool
 ↓
Answer

بنابراین نقاط بیشتری برای hallucination داریم. 1. Planning Hallucination Agent یک برنامه یا step اشتباه ایجاد می‌کند. مثلاً کاربر:

«قیمت دلار را بررسی کن و اگر کمتر از X بود خرید انجام بده.»

Agent تصمیم می‌گیرد:

1. Search exchange rate
2. Buy immediately

در حالی که باید ابتدا:

1. Get exchange rate
2. Verify rate
3. Compare with threshold
4. Ask/execute according to authorization

باشد. 2. Tool Selection Hallucination Agent ابزار اشتباهی انتخاب می‌کند. مثلاً:

Question:
"What is the current weather?"

Agent:
→ calls database_search

در حالی که باید weather API را صدا بزند. 3. Tool Argument Hallucination ابزار درست انتخاب شده، ولی Agent پارامتر اشتباه می‌دهد. مثلاً:

{
  "user_id": 12345,
  "amount": 100000
}

در حالی که مقدار صحیح باید چیز دیگری باشد. یا حتی پارامتری را حدس می‌زند که اصلاً از کاربر دریافت نکرده است. 4. Tool Result Hallucination Tool نتیجه‌ای نداده یا نتیجه ambiguous بوده، ولی Agent فرض می‌کند موفق شده است. مثلاً:

Tool:
ERROR: timeout

Agent:

Payment successfully completed.

این یکی از خطرناک‌ترین hallucinationها در Agent است. 5. Observation Hallucination Agent خروجی ابزار را اشتباه تفسیر می‌کند. مثلاً API:

{
  "status": "pending"
}

Agent می‌گوید:

Transaction completed.

در حالی که:

pending ≠ completed

6. Memory Hallucination Agent چیزی را به memory نسبت می‌دهد که واقعاً در memory وجود ندارد. مثلاً:

User never said:
"I prefer PostgreSQL"

Agent:
"You previously told me that you prefer PostgreSQL."

7. State Hallucination Agent وضعیت فعلی workflow را اشتباه تصور می‌کند. مثلاً workflow:

Order Created
      ↓
Payment Pending
      ↓
Payment Confirmed

ولی Agent تصور می‌کند:

Payment Confirmed

در حالی که state هنوز:

Payment Pending

است. 3. یک تفاوت خیلی مهم می‌توانیم Hallucination را بر اساس محل وقوع هم دسته‌بندی کنیم:

User
                     │
                     ▼
               Input Guardrail
                     │
                     ▼
                Hybrid Search
                     │
                     ▼
                  Retrieval
                     │
                     ▼
                  Reranker
                     │
                     ▼
              Relevant Context
                     │
                     ▼
                    LLM
                     │
                     ▼
              Output Guardrail
                     │
                     ▼
                   User

در واقع: Hybrid Search → پیدا کردن اطلاعات Reranker → انتخاب بهترین اطلاعات LLM → تولید پاسخ Guardrail → کنترل ایمنی و کیفیت پاسخ این چهار لایه در کنار هم می‌توانند پایه یک RAG/Agent Architecture قابل اتکا و Production-Ready را تشکیل دهند. @code_crafters

حتماً. متن را با حفظ مفهوم اصلی، از نظر نگارشی و ساختاری مرتب کردم تا برای انتشار در لینکدین، تلگرام یا شبکه‌های اجتماعی حرفه‌ای‌تر و روان‌تر باشد. ### دو موضوع مهم در طراحی 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 شوند یا در شرایط خاص، خروجی نامناسب، تبعیض‌آمیز یا قابل سوءاستفاده تولید کنند. بنابراین در معماری Agent باید لایه‌هایی برای کنترل ورودی و خروجی در نظر بگیریم. یک رویکرد این است که از خود یک LLM به عنوان ناظر استفاده کنیم. برای مثال، یک Prompt به مدل می‌دهیم که: > پاسخ را بررسی کن، فقط بر اساس داده‌های دریافت‌شده قضاوت کن و اگر پاسخ نامناسب بود، آن را رد کن. در این حالت یک مدل بزرگ مانند GPT می‌تواند نقش Evaluator / Guardrail را داشته باشد. اما راهکار دیگر استفاده از مدل‌های تخصصی Safety Classifier است. یکی از نمونه‌های معروف: ### 🛡️ ShieldGemma ShieldGemma محصول Google و خانواده Gemma است که برای Safety Classification طراحی شده است. می‌توان از آن برای بررسی ورودی کاربر و همچنین بررسی خروجی Agent یا LLM استفاده کرد. برای مثال:

User Input
    ↓
ShieldGemma
    ↓
Safe?
    ├── No → Block
    │
    └── Yes
          ↓
        Agent
          ↓
        LLM
          ↓
    ShieldGemma
          ↓
      Safe Output?
       ├── No → Block
       └── Yes → User

در نتیجه می‌توان Guardrail را هم قبل از اجرای Agent و هم بعد از تولید پاسخ قرار داد. ShieldGemma در نسخه‌های متنی خود روی دسته‌هایی مانند Harassment، Hate، Dangerous Content و Sexually Explicit Content تمرکز دارد. --- ### 🛡️ Llama Guard گزینه شناخته‌شده دیگر Llama Guard از Meta است. Llama Guard نیز برای Safety Classification طراحی شده و می‌تواند در سناریوهای مختلف برای کنترل محتوای ورودی و خروجی مورد استفاده قرار گیرد. یکی از مزیت‌های مهم این خانواده، امکان استفاده و شخصی‌سازی متناسب با نیازهای سیستم است. --- ### جمع‌بندی در یک Agent یا RAG System حرفه‌ای، فقط پیدا کردن اطلاعات کافی نیست. ما باید دو سؤال مهم را پاسخ دهیم: 1. آیا اطلاعاتی که پیدا کرده‌ایم واقعاً مرتبط و باکیفیت هستند؟ ⬅️ Reranking 2. آیا ورودی و خروجی سیستم امن، مناسب و مطابق Policy ما هستند؟ ⬅️ Guardrails بنابراین یک معماری ساده می‌تواند چیزی شبیه این باشد:

ترکیب هوش مصنوعی و رباتیک واقعا داره به جاهای جالبی میرسه در کشورهای توسعه یافته بنا به فشار نهادهای دولتی برای رعایت خیلی از اصول و استاداردهای محیطی در تمام اماکن، رباتیک از تصرف شغل‌های خدماتی شروع میکنه و در کشورهایی که مسئولان دزدی میکنن تا فرزندانشون تو غرب زندگی کنن و بابت این دزدی منجر به عدم رعایت استانداردهای جهانی در اماکن شده، رباتیک در کشور رانت زده (جنگ زده) از بالاترین اماکن استاندار مانند بیمارستان‌ها و مراکز خصوصی شروع به جانشینی انسانی خواهد شد #موقت

Python ai tools @code_crafters

شهرهای مرزی و مناطق بالاشهر استان‌ها واحد مبادله کالا و ملک رو با دلار انجام میدن به زودی واحد شمارش پول کشور در سطح جامعه از ریال به دلار تغییر خواهد کرد خودم شخصا به این فکر میکنم که از این ببعد قرارداد به دلار ببندم #موقت