🔵 عنوان مقاله
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Understanding Playwright Agents
🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمونهای مرورگری است: بهجای نوشتن تکتک گامها، هدف را توصیف میکنید و عاملها با برنامهریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا میکنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخابگرهای پایدار—زمان ساخت تست را کاهش میدهد و نگهداری را آسانتر میکند. معماری هسته شامل سه بخش برنامهریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدلمحور تلاش میکند هم انعطافپذیر باشد و هم قابلیت بازپخش و مشاهدهپذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عاملها، الگوی حلقه تصمیمگیری، ساخت مدل از DOM و مثالهای عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح میدهد و در کنار آن، محدودیتها و بهترینروشها را نیز بیان میکند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پینکردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تستهای اولیه و سپس تثبیت آنها به اسکریپتهای قطعی Playwright است.
#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools
🟣لینک مقاله:
https://cur.at/NqUSz5D?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Awesome Testing
Understanding Playwright Agents
A deep dive into Playwright Agents and the Model Context Protocol (MCP) — how Microsoft’s latest AI-powered Playwright release automates test planning, script generation, and self-healing browser tests across Chrome, Firefox, and WebKit.
Forwarded from Gopher Job
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
🔵 عنوان مقاله
Improved BRICKSTORM YARA Rules (GitHub Repo)
🟢 خلاصه مقاله:
بهروزرسانی تازهای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub بهطور شفافتر، سریعتر و قابل اتکاتر میکند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفافسازی encoding رشتهها و توالیهای بایتی، از رفتار یکسان قوانین در حالتهای مختلف اطمینان داده است. همچنین با سادهسازی و یکپارچهسازی قواعد، نگهداشت و فهم آنها آسانتر شده است. افزودهشدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش میدهد و استقرار و بهبود مستمر قوانین را برای تیمهای دفاعی سادهتر میکند.
#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub
🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Improved BRICKSTORM YARA Rules (GitHub Repo)
🟢 خلاصه مقاله:
بهروزرسانی تازهای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub بهطور شفافتر، سریعتر و قابل اتکاتر میکند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفافسازی encoding رشتهها و توالیهای بایتی، از رفتار یکسان قوانین در حالتهای مختلف اطمینان داده است. همچنین با سادهسازی و یکپارچهسازی قواعد، نگهداشت و فهم آنها آسانتر شده است. افزودهشدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش میدهد و استقرار و بهبود مستمر قوانین را برای تیمهای دفاعی سادهتر میکند.
#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub
🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
signature-base/yara/apt_cn_brickstorm_sep25.yar at master · Neo23x0/signature-base
YARA signature and IOC database for my scanners and tools - Neo23x0/signature-base
🔵 عنوان مقاله
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger
🟢 خلاصه مقاله:
بهگفتهی Nishant Bhandari، دیباگ اپلیکیشنهای وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمیدهند. او برای سادهسازی این روند، ابزار متنباز interactive-logger را معرفی میکند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگها و خطاها را همانجا روی دستگاه و بهصورت لحظهای نمایش میدهد تا بازتولید و اشتراکگذاری باگها سریعتر و دقیقتر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریمورک است.
#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend
🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger
🟢 خلاصه مقاله:
بهگفتهی Nishant Bhandari، دیباگ اپلیکیشنهای وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمیدهند. او برای سادهسازی این روند، ابزار متنباز interactive-logger را معرفی میکند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگها و خطاها را همانجا روی دستگاه و بهصورت لحظهای نمایش میدهد تا بازتولید و اشتراکگذاری باگها سریعتر و دقیقتر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریمورک است.
#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend
🟣لینک مقاله:
https://cur.at/vp45Wp0?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Debugging Mobile Web Apps Shouldn’t Be This Hard — So I Built a Logger
The Nightmare Scenario
🔵 عنوان مقاله
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)
🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامکهای جعلی به نام USPS، اپراتورهای عوارض جادهای، پلتفرمهای تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وبسایتهای موبایلی جعلی، دادههای کارت پرداخت را جمعآوری میکند و سپس با سوءاستفاده از فرایندهای ثبتنام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارتهای سرقتشده را به کیفپولهای موبایلی متصل میسازد. هدف شکایت، مختلکردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.
#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud
🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)
🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامکهای جعلی به نام USPS، اپراتورهای عوارض جادهای، پلتفرمهای تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وبسایتهای موبایلی جعلی، دادههای کارت پرداخت را جمعآوری میکند و سپس با سوءاستفاده از فرایندهای ثبتنام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارتهای سرقتشده را به کیفپولهای موبایلی متصل میسازد. هدف شکایت، مختلکردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.
#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud
🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Krebs on Security
Google Sues to Disrupt Chinese SMS Phishing Triad
Google is suing more than two dozen unnamed individuals allegedly involved in peddling a popular China-based mobile phishing service that helps scammers impersonate hundreds of trusted brands, blast out text message lures, and convert phished payment card…
🔵 عنوان مقاله
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیبپذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کردهاند؛ مولفهای که در Android برای decode کردن محلی تمام پیامها و پیوستهای صوتی بهکار میرود. این نقص میتواند به remote code execution منجر شود و بهدلیل اجرای خودکار فرآیند decode در مسیر رسانهای سیستم، امکان حملات zero-click را فراهم میکند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپها در Android برای پردازشهای پسزمینه (مثل پیشنمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه میکنند، سطح حمله گسترده است. توصیه میشود بهمحض انتشار، بهروزرسانیهای امنیتی Android و سازندگان دستگاه اعمال شود و از سختسازی مسیرهای رسانهای، sandboxing و شیوههای ایمن حافظه استفاده شود.
#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity
🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیبپذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کردهاند؛ مولفهای که در Android برای decode کردن محلی تمام پیامها و پیوستهای صوتی بهکار میرود. این نقص میتواند به remote code execution منجر شود و بهدلیل اجرای خودکار فرآیند decode در مسیر رسانهای سیستم، امکان حملات zero-click را فراهم میکند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپها در Android برای پردازشهای پسزمینه (مثل پیشنمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه میکنند، سطح حمله گسترده است. توصیه میشود بهمحض انتشار، بهروزرسانیهای امنیتی Android و سازندگان دستگاه اعمال شود و از سختسازی مسیرهای رسانهای، sandboxing و شیوههای ایمن حافظه استفاده شود.
#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity
🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
SecurityWeek
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks
On Android, the out-of-bounds write issue can be triggered during the processing of media files without user interaction.
👍1
🔵 عنوان مقاله
How I Automated Test Scope Analysis with a CLI Tool
🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح میدهد که با استفاده از GitHub API تغییرات کد را بهسرعت تحلیل میکند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه میدهد. این ابزار با دریافت اطلاعات PR و commitها، فایلهای تغییرکرده را بررسی و وابستگیها را تحلیل میکند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویتدار (از واحد تا یکپارچه) پیشنهاد میدهد. خروجی میتواند در ترمینال، بهصورت Markdown/JSON، یا بهعنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کشکردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاهکردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.
#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality
🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How I Automated Test Scope Analysis with a CLI Tool
🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح میدهد که با استفاده از GitHub API تغییرات کد را بهسرعت تحلیل میکند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه میدهد. این ابزار با دریافت اطلاعات PR و commitها، فایلهای تغییرکرده را بررسی و وابستگیها را تحلیل میکند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویتدار (از واحد تا یکپارچه) پیشنهاد میدهد. خروجی میتواند در ترمینال، بهصورت Markdown/JSON، یا بهعنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کشکردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاهکردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.
#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality
🟣لینک مقاله:
https://cur.at/SDG4cgz?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How I Automated Test Scope Analysis with a CLI Tool
A Node.js tool that uses GitHub APIs to instantly analyze code changes, and generate AI-powered test recommendations
Forwarded from Linux Labdon
کاهش هزینه سیستمهای هوش مصنوعی با Semantic Caching
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤2
🔵 عنوان مقاله
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این میپردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعهای از آزمایشها، نشان میدهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر میکند. James Bach در این مسیر روش LARC را معرفی میکند؛ رویکردی ساختیافته و اکتشافی برای برنامهریزی، اجرای آزمونها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظاممند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیتهای قابلیت اعتماد آشکار شوند. مقاله توضیح میدهد که چرا آزمون جامع دشوار و پرهزینه است: خروجیهای غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، بهروزرسانیهای مدل که بازتولیدپذیری را میشکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد میشود آزمون LLM را یک کار تحقیقاتی-حرفهای ببینیم: اهداف و ریسکها را روشن کنیم، دادههای متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیمگیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Seriously Testing LLMs
🟢 خلاصه مقاله:
این مقاله به این میپردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعهای از آزمایشها، نشان میدهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر میکند. James Bach در این مسیر روش LARC را معرفی میکند؛ رویکردی ساختیافته و اکتشافی برای برنامهریزی، اجرای آزمونها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظاممند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیتهای قابلیت اعتماد آشکار شوند. مقاله توضیح میدهد که چرا آزمون جامع دشوار و پرهزینه است: خروجیهای غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، بهروزرسانیهای مدل که بازتولیدپذیری را میشکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد میشود آزمون LLM را یک کار تحقیقاتی-حرفهای ببینیم: اهداف و ریسکها را روشن کنیم، دادههای متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیمگیری کنیم.
#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning
🟣لینک مقاله:
https://cur.at/OfLtyHW?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Satisfice, Inc.
Seriously Testing LLMs - Satisfice, Inc.
Michael and I are getting a lot of interest about how we apply Rapid Software Testing methodology both to test AI and to use AI in testing. We've developed various answers to such questions in recent years. But now that the book is done (and almost out!)…
👍1
🔵 عنوان مقاله
Spotter (GitHub Repo)
🟢 خلاصه مقاله:
Spotter یک اسکنر امنیتی متنباز در GitHub است که با تکیه بر قوانین مبتنی بر CEL، تنظیمات ناایمن و خطاهای پیکربندی را در خوشههای Kubernetes شناسایی میکند. این ابزار میتواند انواع منابع Kubernetes را بررسی کند، قواعد سفارشیسازیشده را برای استانداردهای داخلی پشتیبانی کند و هم روی خوشههای اجراشده و هم پیش از استقرار (در CI/CD یا GitOps) به کار رود. رویکرد policy-as-code آن، کشف سریع و قابلاقدام مسائل امنیتی و اجرای یکپارچه سیاستها را ممکن میسازد؛ هرچند جایگزین لایههای دیگر مانند پایش در زمان اجرا یا اسکن تصاویر نیست و مکمل آنهاست.
#Kubernetes #Security #CEL #DevSecOps #CloudNative #OpenSource #PolicyAsCode #SecurityScanning
🟣لینک مقاله:
https://github.com/madhuakula/spotter?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Spotter (GitHub Repo)
🟢 خلاصه مقاله:
Spotter یک اسکنر امنیتی متنباز در GitHub است که با تکیه بر قوانین مبتنی بر CEL، تنظیمات ناایمن و خطاهای پیکربندی را در خوشههای Kubernetes شناسایی میکند. این ابزار میتواند انواع منابع Kubernetes را بررسی کند، قواعد سفارشیسازیشده را برای استانداردهای داخلی پشتیبانی کند و هم روی خوشههای اجراشده و هم پیش از استقرار (در CI/CD یا GitOps) به کار رود. رویکرد policy-as-code آن، کشف سریع و قابلاقدام مسائل امنیتی و اجرای یکپارچه سیاستها را ممکن میسازد؛ هرچند جایگزین لایههای دیگر مانند پایش در زمان اجرا یا اسکن تصاویر نیست و مکمل آنهاست.
#Kubernetes #Security #CEL #DevSecOps #CloudNative #OpenSource #PolicyAsCode #SecurityScanning
🟣لینک مقاله:
https://github.com/madhuakula/spotter?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - madhuakula/spotter: Spotter is a comprehensive Kubernetes security scanner that uses CEL-based rules to identify security…
Spotter is a comprehensive Kubernetes security scanner that uses CEL-based rules to identify security vulnerabilities, misconfigurations, and compliance violations across your Kubernetes clusters, ...
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عملگرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرمافزار شرح میدهد: او نشان میدهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق میشود. بهگفته او، AI در تولید اولیه تستها از نیازمندیها، پیشنهاد موارد مرزی، کاهش شکنندگی تستهای UI، شناسایی تستهای flaky، خوشهبندی خطاها، اولویتبندی ریسکمحور و ساخت دادههای آزمایشی مفید است؛ همچنین در بررسیهای بصری و دسترسپذیری میتواند رگرسیونهای ظریف را آشکار کند.
در مقابل، خطاهای مدلهای زبانی، عدم درک عمیق دامنه، محدودیتهای امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تستهای تولیدی، مانع اعتماد کامل میشوند. «عاملهای» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمیشود.
جمعبندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریانهای human-in-the-loop، میتوان از AI در حوزههایی با سیگنال قوی—مثل نگهداشت و تریاژ شکستها—بهره برد؛ AI باید مکمل مهارت تیمهای QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI in Testing: Hype or Real Progress?
🟢 خلاصه مقاله:
این یادداشت با نگاهی عملگرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرمافزار شرح میدهد: او نشان میدهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق میشود. بهگفته او، AI در تولید اولیه تستها از نیازمندیها، پیشنهاد موارد مرزی، کاهش شکنندگی تستهای UI، شناسایی تستهای flaky، خوشهبندی خطاها، اولویتبندی ریسکمحور و ساخت دادههای آزمایشی مفید است؛ همچنین در بررسیهای بصری و دسترسپذیری میتواند رگرسیونهای ظریف را آشکار کند.
در مقابل، خطاهای مدلهای زبانی، عدم درک عمیق دامنه، محدودیتهای امنیت و حریم خصوصی، و دشواری ارزیابی کیفیت تستهای تولیدی، مانع اعتماد کامل میشوند. «عاملهای» خودمختار تست بدون نظارت انسانی هنوز پایدار نیستند و AI جایگزین طراحی آگاه از معماری، تحلیل ریسک و تأیید انسانی نمیشود.
جمعبندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریانهای human-in-the-loop، میتوان از AI در حوزههایی با سیگنال قوی—مثل نگهداشت و تریاژ شکستها—بهره برد؛ AI باید مکمل مهارت تیمهای QA و مهندسی باشد، نه جایگزین آن.
#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy
🟣لینک مقاله:
https://cur.at/6kIevSo?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Software Test Management | Testuff | SaaS Test Management
AI in Testing: Hype or Real Progress? | Software Test Management | Testuff
Discover how AI is reshaping software testing, from self-healing automation to predictive quality insights, and what it means for the future of QA.