<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:media="http://search.yahoo.com/mrss/"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Towards AI</title>
	<atom:link href="https://towardsai.net/feed" rel="self" type="application/rss+xml" />
	<link>https://towardsai.net</link>
	<description>Making AI accessible to all</description>
	<lastBuildDate>Thu, 30 Apr 2026 01:35:21 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.4</generator>

<image>
	<url>https://towardsai.net/wp-content/uploads/2019/05/cropped-towards-ai-square-circle-png-32x32.png</url>
	<title>Towards AI</title>
	<link>https://towardsai.net</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Crack ML Interviews with Confidence: K-Nearest Neighbors (KNN 20 Q&#038;A)</title>
		<link>https://towardsai.net/p/machine-learning/crack-ml-interviews-with-confidence-k-nearest-neighbors-knn-20-qa</link>
		
		<dc:creator><![CDATA[Shahidullah Kawsar]]></dc:creator>
		<pubDate>Wed, 29 Apr 2026 17:01:03 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/crack-ml-interviews-with-confidence-k-nearest-neighbors-knn-20-qa</guid>

					<description><![CDATA[Last Updated on April 29, 2026 by Editorial Team Author(s): Shahidullah Kawsar Originally published on Towards AI. Data Scientist &#38; Machine Learning Interview Preparation How to train a ML model using KNN in 5 steps: Source: This image is generated by ChatGPTThe article provides a comprehensive overview of K-Nearest Neighbors (KNN), a popular machine learning algorithm, detailing its fundamental concepts such as similarity-based learning, distance calculations, prediction rules, and the importance of selecting an appropriate value for K. It explores key considerations like feature scaling, the implications of the lazy learning approach, and practical applications, reinforced by a series of interview questions and answers that assess knowledge of KNN, its advantages, and its challenges in high-dimensional spaces. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/0*Ev0TiIsYPgeT_F3s.png" medium="image"></media:content>
            	</item>
		<item>
		<title>The Event-Driven Blueprint: How I Scaled a Spring Boot System to 10 Million Kafka Messages/Day</title>
		<link>https://towardsai.net/p/machine-learning/the-event-driven-blueprint-how-i-scaled-a-spring-boot-system-to-10-million-kafka-messages-day</link>
		
		<dc:creator><![CDATA[FutureLens]]></dc:creator>
		<pubDate>Wed, 29 Apr 2026 07:30:05 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/the-event-driven-blueprint-how-i-scaled-a-spring-boot-system-to-10-million-kafka-messages-day</guid>

					<description><![CDATA[Last Updated on April 29, 2026 by Editorial Team Author(s): FutureLens Originally published on Towards AI. The Event-Driven Blueprint: How I Scaled a Spring Boot System to 10 Million Kafka Messages/Day Modern applications rarely fail because of lack of features; they fail when they can’t keep up with scale. As systems grow, tightly coupled architectures start to crack under pressure, leading to slow processing, poor resilience, and operational headaches. That’s exactly the problem I ran into while scaling a Spring Boot service that needed to process millions of events daily. Traditional request-response patterns weren’t enough anymore. “Image created by ChatGPT”The article discusses the challenges of scaling a Spring Boot service to process 10 million Kafka messages per day. It emphasizes the transition from tightly coupled architectures to an event-driven model using Kafka for asynchronous communication. The author shares insights on the necessity of effective topic design, parallel consumer processing, handling failures gracefully with retry mechanisms and Dead Letter Queues, and the importance of monitoring and observability to maintain system reliability. Key strategies include optimizing throughput and performance by tuning configurations and embracing best practices for maintaining a scalable architecture. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*XwOMbq4dO78-oPIEFutIoQ.jpeg" medium="image"></media:content>
            	</item>
		<item>
		<title>Building Vector Search? Why FAISS Alone Isn’t Enough</title>
		<link>https://towardsai.net/p/machine-learning/building-vector-search-why-faiss-alone-isnt-enough</link>
		
		<dc:creator><![CDATA[Tina Sharma]]></dc:creator>
		<pubDate>Wed, 29 Apr 2026 02:31:01 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Data Science]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/building-vector-search-why-faiss-alone-isnt-enough</guid>

					<description><![CDATA[Last Updated on April 29, 2026 by Editorial Team Author(s): Tina Sharma Originally published on Towards AI. What FAISS Does Well, Where It Stops, and When to Use a Vector Database Instead FAISS is a fast vector search library, not a database. Learn what it does well, where it fails in production, and when to use a vector database instead. How semantic search works with FAISS — from raw text to nearest-neighbor results. Image created using Nano BananaThe article discusses the capabilities and limitations of FAISS, a vector search library developed by Meta AI Research, emphasizing its strengths in efficient similarity searches and hardware acceleration while highlighting its shortcomings, such as lack of metadata handling, persistence, and concurrent access control. It also compares FAISS to production vector databases, explaining scenarios where each is more suitable, and provides practical insights into the implementation and maintenance considerations when utilizing FAISS in real-world applications. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:1000/1*DeFbzo_kACublYlFv2sRew.jpeg" medium="image"></media:content>
            	</item>
		<item>
		<title>TAI #202: GPT-5.5 Moves Codex Into Real Work</title>
		<link>https://towardsai.net/p/machine-learning/tai-202-gpt-5-5-moves-codex-into-real-work</link>
		
		<dc:creator><![CDATA[Towards AI Editorial Team]]></dc:creator>
		<pubDate>Tue, 28 Apr 2026 19:01:03 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/tai-202-gpt-5-5-moves-codex-into-real-work</guid>

					<description><![CDATA[Last Updated on April 29, 2026 by Editorial Team Author(s): Towards AI Editorial Team Originally published on Towards AI. What happened this week in AI by Louie OpenAI released GPT-5.5 on April 23. In the same week, they launched workspace agents in ChatGPT and released Privacy Filter for PII redaction; Google pushed Deep Research Max and its enterprise agent platform; and DeepSeek released V4-Pro and V4-Flash with 1M-token context. The thread connecting these releases is clear: frontier labs are turning models into work systems, with tools, memory, permissions, pricing, and verification becoming as important as the base model. The useful read on GPT-5.5 is Codex. OpenAI is aiming the model at complex computer work: writing and debugging code, researching online, analyzing documents and spreadsheets, operating software, and moving across tools until a task is finished. This is the same direction Anthropic has been pushing with Opus, Claude Code, Cowork, Skills, and Claude Design. The competition is increasingly about which lab can package intelligence into a reliable worker. Codex is still less welcoming than Claude Cowork for non-technical and non-coding work. The interface can feel like a developer tool because, well, it is one. But it is now set up to be extremely valuable for white-collar work far beyond software engineering. You can create reusable skills in a similar spirit to Claude Skills or Cowork workflows, move them between projects, and build task-specific playbooks for research, reporting, data cleanup, document review, financial analysis, or internal operations. I especially like using Codex subagents. For deep research or parallel workstreams, I often run up to 20 in parallel, with some exploring sources, some checking facts, some criticizing the draft, some testing assumptions, and others running iteration loops before anything comes back to me. This is a very different way to use AI: less single-threaded prompting, more managing a small team of specialized workers. If the Codex UI feels overwhelming and you are not a developer, the non-coder view option in advanced settings is worth turning on. It makes the product feel less like a terminal-adjacent engineering cockpit and more like a general work surface. Codex also works extremely well with OpenAI’s new GPT Images 2.0 model, which is actually beating Gemini’s Nano Banana for some very complex graphics in my tests, and comes with the added advantage of integration into Codex, where sub-agents can bulk generate 10–20 images in parallel. The coding numbers support a real Codex upgrade, with a few caveats. OpenAI reports GPT-5.5 at 82.7% on Terminal-Bench 2.0, up from 75.1% for GPT-5.4, 69.4% for Claude Opus 4.7, and 68.5% for Gemini 3.1 Pro. On its internal Expert-SWE eval for long-horizon coding tasks with a median estimated human completion time of 20 hours, GPT-5.5 scores 73.1% versus 68.5% for GPT-5.4. SWE-Bench Pro is the less flattering number: GPT-5.5 reaches 58.6%, only slightly above GPT-5.4 at 57.7% and behind Opus 4.7 at 64.3%. That benchmark split is the whole point. GPT-5.5 looks strongest when the task requires terminal work, repo navigation, tool use, long context, and persistence. I would call it a meaningful improvement in the agent loop. For real software work, that is the part that matters. A useful coding agent has to inspect the repo, understand the architecture, run commands, debug failures, preserve user work, and explain the diff. The productivity gain comes from fewer correction loops, less babysitting, and more tasks that reach a reviewable state without the developer restating the obvious five times. This is also why I would measure these tools by accepted PRs, review time, defect rate, and retry count, instead of judging a single impressive answer in chat. The broader work benchmarks point in the same direction. GPT-5.5 scores 84.9% wins or ties on GDPval, 78.7% on OSWorld-Verified, 84.4% on BrowseComp, 75.3% on MCP Atlas, and 54.1% on OfficeQA Pro. It has a 400K context window in Codex and a 1,050,000-token context window in the API docs. OpenAI’s long-context results are especially strong on MRCR v2 at 512K to 1M tokens, where GPT-5.5 scores 74.0%, compared with 36.6% for GPT-5.4 and 32.2% for Opus 4.7. The cost story is more complicated than the launch framing. GPT-5.5 costs $5 per million input tokens, $0.50 per million cached input tokens, and $30 per million output tokens in the API, exactly twice GPT-5.4’s standard token price. GPT-5.5 Pro is listed in the launch post at $30 per million input tokens and $180 per million output tokens. Prompts above 272K input tokens are priced at 2x input, and 1.5x output for the full session, and Codex Fast mode generates tokens 1.5x faster for 2.5x the cost. OpenAI argues GPT-5.5 uses fewer tokens on Codex tasks, and third-party testing broadly supports partial efficiency gains. Artificial Analysis found that GPT-5.5 used about 40% fewer output tokens than GPT-5.4 on its Intelligence Index, making the full run about 20% more expensive rather than 2x as expensive. Teams should test cost per completed workflow (post-human iteration), not cost per token. A GPT-5.5 run that fixes the bug once can be cheaper than four cheap but failed attempts. OpenAI says more than 85% of its employees now use Codex weekly across engineering, finance, communications, marketing, data science, and product. The Finance team used Codex to review 24,771 K-1 tax forms totaling 71,637 pages, accelerating the task by two weeks. The go-to-market team automated weekly business reports, saving 5–10 hours per week. OpenAI also said Codex grew from more than 3 million weekly developers in early April to more than 4 million two weeks later. They also launched Codex Labs and partnerships with Accenture, Capgemini, CGI, Cognizant, Infosys, PwC, and TCS. NVIDIA gives the clearest enterprise rollout pattern. More than 10,000 employees across engineering, product, legal, marketing, finance, sales, HR, operations, and developer programs have used GPT-5.5-powered Codex. NVIDIA reports debugging cycles moving from days to hours and experimentation moving from weeks to overnight progress. The setup is more important than the quote: dedicated cloud virtual machines, auditability, zero-data retention, read-only production access, command-line [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*FibWwzazipi67VL9ZIISMg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Machine Learning System Design -The Model Serving Triangle, With One Forward Pass Flowing Through Every Trade-off (Part3)</title>
		<link>https://towardsai.net/p/machine-learning/machine-learning-system-design-the-model-serving-triangle-with-one-forward-pass-flowing-through-every-trade-off-part3</link>
		
		<dc:creator><![CDATA[Utkarsh Mittal]]></dc:creator>
		<pubDate>Tue, 28 Apr 2026 08:49:39 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/machine-learning-system-design-the-model-serving-triangle-with-one-forward-pass-flowing-through-every-trade-off-part3</guid>

					<description><![CDATA[Last Updated on April 29, 2026 by Editorial Team Author(s): Utkarsh Mittal Originally published on Towards AI. The Model Serving Triangle, With One Forward Pass Flowing Through Every Trade-off (Part3) Part 1-p https://pub.towardsai.net/the-ml-system-design-interview-with-numbers-flowing-through-every-stage-part-1-a77888339297?source=friends_link&#38;sk=9064640f37c84a131ef24b1126bc0cf9 Three pieces of memory math that every candidate must have memorizedThis article discusses the complexities and trade-offs of machine learning model serving, detailing how decisions revolve around three sources: latency, throughput, and cost. It emphasizes the importance of understanding these factors when deploying models in production and features practical examples and strategies to maintain efficiency, including latency requirements and architectural choices. It provides insights into challenges such as cold starts and the significance of training-serving skew, supporting these topics with numerous examples, analogies, and recommendations for best practices in model deployment and monitoring. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*F2wZPQkhB3fDd5s1cS6ljQ.gif" medium="image"></media:content>
            	</item>
		<item>
		<title>AI Orchestration in Action: How MuleSoft and LLMs Fuel the Future of Enterprise AI</title>
		<link>https://towardsai.net/p/machine-learning/ai-orchestration-in-action-how-mulesoft-and-llms-fuel-the-future-of-enterprise-ai</link>
		
		<dc:creator><![CDATA[CapeStart]]></dc:creator>
		<pubDate>Thu, 23 Apr 2026 06:25:32 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/ai-orchestration-in-action-how-mulesoft-and-llms-fuel-the-future-of-enterprise-ai</guid>

					<description><![CDATA[Last Updated on April 23, 2026 by Editorial Team Author(s): CapeStart Originally published on Towards AI. Nowadays, in the enterprise environment, information is dispersed across CRMs, ERPs, databases, and millions of APIs, resulting in an intricate web of disconnected data. At the same time, the realm of Artificial Intelligence is exploding with advanced tools such as LLMs for natural language processing and Image GPT for amazing image creation. The major challenge for today’s business is unifying these two worlds. How do you seamlessly and securely integrate your business core systems with advanced AI models? The solution is AI Orchestration. What is AI Orchestration? The Control Tower for Enterprise AI Imagine an AI orchestrator as the master control tower for your intelligence and data. Its role is to orchestrate a complex sequence of actions with accuracy and effectiveness. Fundamentally, the orchestrator: Integrates with Enterprise Data: It integrates directly into your core systems, whether it’s an ERP, CRM, or a custom database. Chooses the Optimal AI Model: It routes requests to the most appropriate model for the task, whether an LLM, an image model, or an analytics tool. Delivers Clean, Secure APIs: It bundles the final, AI-fueled results into secure and well-structured APIs that can be consumed by any app. The orchestrator is at the center of the action, determining what data to retrieve, which AI model to apply, and how to merge and serve up the final output. Where MuleSoft Excels in the AI-Powered Enterprise This is where a tool such as MuleSoft, the robust integration engine of Salesforce, comes into play. Previously renowned for its API-led strategy for integrating applications, MuleSoft is becoming the preferred platform for AI orchestration in enterprises. Here’s how it plays into the new AI stack: As an API Gateway &#38; Renderer: MuleSoft is good at securing, managing, and exposing AI-powered APIs, making them robust and scalable. As an Enterprise Connector: With a comprehensive set of out-of-the-box connectors for Salesforce, SAP, Oracle, and many others, MuleSoft can draw data from nearly any system. As a Governance Layer: It offers a solid foundation for implementing authentication, controlling access, tracking usage, and maintaining compliance. As a Lightweight Orchestrator: It can create straightforward yet strong flows, like retrieving data from a database, passing it to an LLM for processing, and returning a formatted result. But MuleSoft is not used for sophisticated AI-native operations such as chaining prompts, multi-step reasoning, or conversational memory. Although you can create a prompt template and fill it up with information, an actual sophisticated orchestration demands a hybrid solution. This is where LangChain or LlamaIndex frameworks come into play to complement MuleSoft’s capabilities by processing the sophisticated AI logic and leaving MuleSoft to do enterprise integration. A Real-World Example: AI-Orchestrated Sales Intelligence Assistant Let’s consider a multinational company that wants to empower its sales and customer success teams with real-time data from all data sources they have, like CRM and external Databases. The goal: Build a Sales Intelligence Assistant that can understand natural language questions like: “Show me which enterprise customers in EMEA are at risk of churn this quarter and draft a personalized retention email for each.” This requires pulling together fragmented enterprise data, running intelligent analysis, and returning results in CRM’s secure flow. Here’s how the end-to-end flow would be realized via AI orchestration: 1. User Inquiry: A sales manager types the question directly into Salesforce’s Service Console. This request is sent as an API call to MuleSoft. 2. API Gateway &#38; Security Layer (MuleSoft): MuleSoft acts as the entry point and authenticates the Salesforce user via OAuth, logs the request, and enforces governance rules (data masking, rate limits, and compliance). 3. Data Retrieval: MuleSoft orchestrates multiple data calls (All following data will be aggregated in MuleSoft into a unified payload): a. Fetches customer data, renewal dates, and support ticket sentiment from Salesforce. b. Pulls usage metrics from an external analytics database. c. Queries contract and billing history from the external billing database linked with the payment service. 4. AI Orchestrator (MuleSoft + LangChain): MuleSoft passes the consolidated data to a LangChain-based microservice (hosted in AWS or Salesforce Data Cloud), follows: a. The LLM analyzes churn risk by combining usage data, support sentiment, and renewal timelines. b. It generates personalized retention messages for each high-risk customer based on the data fetched against them. 5. Response Packaging (MuleSoft): MuleSoft receives the AI results and formats them into a unified response. This is exposed back to Salesforce’s Service Console through a secure API without exposing any personal data of the customer. 6. Salesforce Experience Layer: The results appear as a dynamic dashboard in Salesforce, showing: a. At-risk customers with churn probability scores b. Auto-generated email drafts for approval to reach out to the customer c. Suggested next steps based on the reasoning Why This is a Breakthrough for Business This choreographed strategy brings together the following transformative value: Unified Data Access: Silos are eliminated, presenting a single, integrated view of enterprise data. Intrinsic Governance: Security and compliance are part of the architecture, not bolted on afterward. AI-Native Intelligence: The platform is capable of sophisticated reasoning, linking together disparate AI functions, and enabling multimodal outputs (text, images, etc.). Reusable API-led Architecture: The same composed pipeline can drive not only chatbots, but internal analytics dashboards, marketing bots, and other applications. More Than Chatbots: The Future of AI in Enterprises The use cases go well beyond customer service. Consider these examples: Analytics Dashboards: “Summarize the sales trends of last quarter in the EMEA region and create a corresponding chart.” Automation Bots: “Create a personalized follow-up mail to our top 10 customers, including product images they have looked at and warranty information.” E-commerce Assistants: “Create personalized product descriptions and lifestyle images for our new summer collection without exposing the entire database to an external AI model.” The future of enterprise AI is not merely a matter of building more intelligent models. It’s building a smarter, more secure, and deeply integrated fabric that brings your enterprise data, your APIs, [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*bpXO-dVCgeDwNXTSiJK0cQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>GPT-4 Has 1.8 Trillion Parameters. It Uses 2% of Them Per Token.</title>
		<link>https://towardsai.net/p/machine-learning/gpt-4-has-1-8-trillion-parameters-it-uses-2-of-them-per-token</link>
		
		<dc:creator><![CDATA[DrSwarnenduAI]]></dc:creator>
		<pubDate>Wed, 22 Apr 2026 08:07:27 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/gpt-4-has-1-8-trillion-parameters-it-uses-2-of-them-per-token</guid>

					<description><![CDATA[Last Updated on April 23, 2026 by Editorial Team Author(s): DrSwarnenduAI Originally published on Towards AI. GPT-4 Has 1.8 Trillion Parameters. It Uses 2% of Them Per Token. DeepSeek-R1: 671 billion parameters. 37 billion active per token. DeepSeek-R1: 671 billion parameters. 37 billion active per token.The article discusses various machine learning models, focusing on their parameter count and operational efficiencies. It delves into the architecture of the Mixture of Experts (MoE), detailing how different models utilize parameters per token and how routing affects performance, emphasizing the benefits of utilizing multiple experts for token processing to improve training stability and efficiency. Additionally, it explores specific implementations, such as the DeepSeek model, and compares it with existing architectures to elucidate advantages in computation and memory usage. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*lil0U9xeTUQ_RmSP4vYwog.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Part 20: Data Manipulation in Multi-Dimensional Aggregation</title>
		<link>https://towardsai.net/p/machine-learning/part-20-data-manipulation-in-multi-dimensional-aggregation</link>
		
		<dc:creator><![CDATA[Raj kumar]]></dc:creator>
		<pubDate>Thu, 16 Apr 2026 08:32:34 +0000</pubDate>
				<category><![CDATA[Data Engineering]]></category>
		<category><![CDATA[Data Science]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/part-20-data-manipulation-in-multi-dimensional-aggregation</guid>

					<description><![CDATA[Last Updated on April 17, 2026 by Editorial Team Author(s): Raj kumar Originally published on Towards AI. When financial analysts need to segment customer profitability across product lines and regions, or when risk managers aggregate exposure metrics across multiple hierarchies, they rely on advanced grouping techniques that go far beyond basic sum() and mean() operations. Part 20 explores the sophisticated aggregation patterns that transform raw transactional data into actionable business intelligence. This article demonstrates production-grade grouping strategies used in banking analytics, risk management systems, and operational reporting pipelines. You will see how to apply multiple aggregations simultaneously, create custom aggregation functions, implement rolling and expanding window calculations, and construct multi-level aggregations with proper unstacking. The Business Context: Why Advanced Aggregation Matters Consider a commercial bank analyzing credit card transaction data. A basic GROUP BY reveals average transaction amounts per customer. But real business questions demand more: What is the range (max minus min) of transaction amounts per merchant category? How do 30-day rolling averages compare to overall means for fraud detection? What are the simultaneous calculations of sum, mean, median, and standard deviation across multiple dimensions? These questions require aggregation techniques that combine multiple operations, apply custom logic, and handle hierarchical grouping structures. The patterns you learn here apply directly to business intelligence dashboards, automated reporting systems, and analytical data pipelines. 1. Multiple Aggregations on Different Columns The most common production requirement is calculating different metrics across different columns in a single operation. Rather than running separate groupby statements and merging results, pandas allows you to specify a dictionary mapping columns to their respective aggregation functions. import pandas as pdimport numpy as np# Transaction data for a payment processordata = { &#39;merchant_category&#39;: [&#39;Retail&#39;, &#39;Retail&#39;, &#39;Dining&#39;, &#39;Dining&#39;, &#39;Travel&#39;, &#39;Travel&#39;, &#39;Retail&#39;, &#39;Dining&#39;, &#39;Travel&#39;, &#39;Retail&#39;], &#39;transaction_amount&#39;: [125.50, 89.30, 45.20, 67.80, 320.00, 155.75, 210.40, 52.30, 189.60, 178.90], &#39;processing_fee&#39;: [3.77, 2.68, 1.36, 2.03, 9.60, 4.67, 6.31, 1.57, 5.69, 5.37], &#39;transaction_count&#39;: [1, 1, 1, 1, 1, 1, 1, 1, 1, 1]}df = pd.DataFrame(data)# Multiple aggregations across different columnsresult = df.groupby(&#39;merchant_category&#39;).agg({ &#39;transaction_amount&#39;: [&#39;mean&#39;, &#39;median&#39;], &#39;processing_fee&#39;: [&#39;min&#39;, &#39;max&#39;]})print(&#34;Multiple Aggregations by Merchant Category:&#34;)print(result) Output: transaction_amount processing_fee mean median min maxmerchant_category Dining 55.10 52.30 1.36 2.03Retail 150.78 125.50 2.68 6.31Travel 221.78 189.60 5.69 9.60 This pattern appears in every revenue analytics dashboard. The finance team needs average transaction values alongside median values (which are less sensitive to outliers), while the operations team monitors the range of processing fees to identify anomalies. A single aggregation call produces all metrics efficiently. Notice the hierarchical column structure in the output. The outer level contains the original column names, while the inner level contains the aggregation function names. This structure becomes important when you need to flatten or manipulate results for downstream systems. 2. Custom Aggregation Functions Standard aggregations cover 80% of use cases. The remaining 20% require business-specific logic. Lambda functions and named custom functions allow you to implement domain-specific calculations that would be impossible with built-in methods alone. # Same transaction datadf = pd.DataFrame(data)# Custom aggregation: calculate the range (spread between max and min)result = df.groupby(&#39;merchant_category&#39;).agg({ &#39;transaction_amount&#39;: lambda x: x.max() - x.min()})print(&#34;\nTransaction Amount Range by Category:&#34;)print(result) Output: transaction_amountmerchant_category Dining 22.60Retail 121.10Travel 164.25 The range calculation is critical in risk management. A merchant category with high transaction variance requires different fraud detection thresholds than a category with consistent transaction sizes. Banks use this metric to calibrate their anomaly detection algorithms. You can also define named functions for more complex logic that requires multiple operations or conditional branching. def weighted_average(series): &#34;&#34;&#34;Calculate average with additional business logic&#34;&#34;&#34; if len(series) &#60; 2: return series.mean() # Weight recent transactions more heavily weights = np.linspace(0.5, 1.5, len(series)) return np.average(series, weights=weights)result = df.groupby(&#39;merchant_category&#39;).agg({ &#39;transaction_amount&#39;: weighted_average})print(&#34;\nWeighted Average Transaction Amount:&#34;)print(result) Output: transaction_amountmerchant_category Dining 56.833333Retail 153.525000Travel 218.316667 Named functions improve code readability and allow you to add documentation explaining the business rationale. When an analyst reviews this aggregation six months later, the function name and docstring make the logic immediately clear. 3. Rolling Window Aggregations Time-series analysis requires comparing current metrics against recent historical patterns. Rolling windows calculate aggregations over a sliding subset of data, essential for trend analysis, moving averages, and anomaly detection systems. # Time-series transaction datadates = pd.date_range(&#39;2024-01-01&#39;, periods=10, freq=&#39;D&#39;)ts_data = { &#39;date&#39;: dates, &#39;category&#39;: [&#39;Electronics&#39;] * 10, &#39;daily_revenue&#39;: [1200, 1350, 1180, 1420, 1390, 1510, 1280, 1450, 1380, 1520]}df_ts = pd.DataFrame(ts_data)df_ts = df_ts.set_index(&#39;date&#39;)# Rolling 3-day averagedf_ts[&#39;rolling_avg&#39;] = df_ts.groupby(&#39;category&#39;)[&#39;daily_revenue&#39;].rolling(window=3).mean().reset_index(level=0, drop=True)print(&#34;\nRolling 3-Day Average Revenue:&#34;)print(df_ts[[&#39;category&#39;, &#39;daily_revenue&#39;, &#39;rolling_avg&#39;]]) Output: category daily_revenue rolling_avgdate 2024-01-01 Electronics 1200 NaN2024-01-02 Electronics 1350 NaN2024-01-03 Electronics 1180 1243.3333332024-01-04 Electronics 1420 1316.6666672024-01-05 Electronics 1390 1330.0000002024-01-06 Electronics 1510 1440.0000002024-01-07 Electronics 1280 1393.3333332024-01-08 Electronics 1450 1413.3333332024-01-09 Electronics 1380 1370.0000002024-01-10 Electronics 1520 1450.000000 The first two rows show NaN values because a 3-day window requires three data points. This is expected behavior. In production systems, you decide whether to forward-fill these nulls, drop them, or use a minimum number of periods parameter. Rolling averages smooth out daily volatility, revealing underlying trends. Revenue operations teams use these calculations to distinguish between normal fluctuations and meaningful changes requiring investigation. The window size (3 days here) is a business decision based on your data’s characteristics and the analysis timeframe. 4. Expanding Window Aggregations While rolling windows maintain a constant size, expanding windows grow progressively from the start of the dataset. This technique calculates cumulative metrics and running totals, critical for year-to-date reporting and cumulative performance tracking. # Same time-series datadf_ts = pd.DataFrame(ts_data)df_ts = df_ts.set_index(&#39;date&#39;)# Expanding cumulative sumdf_ts[&#39;cumulative_sum&#39;] = df_ts.groupby(&#39;category&#39;)[&#39;daily_revenue&#39;].expanding().sum().reset_index(level=0, drop=True)print(&#34;\nExpanding Cumulative Revenue:&#34;)print(df_ts[[&#39;category&#39;, &#39;daily_revenue&#39;, &#39;cumulative_sum&#39;]]) Output: category daily_revenue cumulative_sumdate 2024-01-01 Electronics 1200 1200.02024-01-02 Electronics 1350 2550.02024-01-03 Electronics 1180 3730.02024-01-04 Electronics 1420 5150.02024-01-05 Electronics 1390 6540.02024-01-06 Electronics 1510 8050.02024-01-07 Electronics 1280 9330.02024-01-08 Electronics 1450 10780.02024-01-09 Electronics 1380 12160.02024-01-10 Electronics 1520 13680.0 Every row shows the total revenue from the beginning of the period through that date. Financial reporting systems use this pattern for year-to-date revenue, quarter-to-date expenses, and month-to-date transaction counts. The expanding window eliminates the need for complex SQL window functions or manual cumulative sum calculations. You can apply any aggregation function to expanding windows, not just sum. Expanding means and standard deviations help calibrate control [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*MwmHVEmOxd5fSgK1shMOgg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>A Fundamental Introduction to Genetic Algorithm -Part Two</title>
		<link>https://towardsai.net/p/machine-learning/a-fundamental-introduction-to-genetic-algorithm-part-two</link>
		
		<dc:creator><![CDATA[Hossein Chegini]]></dc:creator>
		<pubDate>Thu, 16 Apr 2026 07:56:20 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/a-fundamental-introduction-to-genetic-algorithm-part-two</guid>

					<description><![CDATA[Last Updated on April 16, 2026 by Editorial Team Author(s): Hossein Chegini Originally published on Towards AI. “A 100-Queen solution” …picture from ‘repo/images/solutions’ Code Investigation In the previous introduction, I provided a detailed explanation of the fundamental steps involved in training a Genetic Algorithm (GA). I discussed important concepts such as mutation, genes, chromosomes, and genetic population, and presented a case study on solving the N-Queen problem using a GA. Following the publication of the article, I proceeded to create a repository and converted my previously written Matlab code into Python code. In this article, my focus is on explaining the different components of the repository and how the main file is structured to set up the GA scenario and find the optimal solution. You can find the repo here. The main file (n_queen_solver.py) serves as the entry point for setting up the GA model and initiating the training process. It prompts the user to provide essential parameters that are crucial for configuring the GA model. These parameters include: Chromosome size or Chessboard Size: The size of the chessboard, which represents the number of queens and the dimensions of the board. Population Size: The number of chromosomes in the population, representing the number of candidate solutions. Epochs: The number of iterations or generations for which the GA model will be trained. parser = argparse.ArgumentParser(description=&#39;Computation of the GA model for finding the n-queen problem.&#39;)parser.add_argument(&#39;chromosome_size&#39;, type=int, help=&#39;The size of a chromosome&#39;)parser.add_argument(&#39;population_size&#39;, type=int, help=&#39;The size of the population of the chromosomes&#39;)parser.add_argument(&#39;epoches&#39;, type=int, help=&#39;The nmber of iterations to traing the GA model&#39;)args = parser.parse_args() After obtaining the parameters, the next block of code is responsible for initializing the population. The ‘init_population()’ method generates the population based on the specified number of individuals, using the encoding explained in the previous article. It returns the initialized population back to the main method of the file. The fitness function and the calculation of the fitness score play a crucial role in selecting the best parents and guiding their reproduction to ensure the program progresses along the optimal path. For the simplicity and clarity of this implementation, I have chosen a straightforward fitness method. The following code block demonstrates the ‘fitness()’ method: def fitness(chrom,chromosome_size): q = 0 for i1 in range(chromosome_size): tmp = i1 - chrom[i1] for i2 in range(i1+1,chromosome_size): q = q + (tmp == (i2 - chrom[i2])) for i1 in range(chromosome_size): tmp = i1 + chrom[i1] for i2 in range(i1+1,chromosome_size): q = q + (tmp == (i2 + chrom[i2])) return 1/(q+0.001) The ‘fitness()’ In this block received an individual chromosome and its size as input parameters and returns back its fitness score. In the given code block, the fitness function checks whether two queens in the chromosome are crossing each other or not. If two queens are found to be crossing, the variable ‘q’ is incremented by one. The purpose of this check is to evaluate the chromosome&#39;s fitness based on the number of queen collisions. The line ‘1 / (q+0.001)’ represents the fitness score based on ‘q’ . By using the reciprocal of the value ‘q + 0.001’, the fitness score will be higher for chromosomes with fewer queen collisions (i.e., a lower value of ‘q’). The addition of ‘0.001’ is to avoid division by zero. The fitness score is used to assess the quality of each chromosome in the population. The higher the fitness score, the better the chromosome’s performance. In the case of reaching a fitness score of 1000, it signifies that the solution has been found, and the program can terminate without further operations. def train_population(population,epoches,chromosome_size): num_best_parents = 2 ft = [] success_booelan = False population_size = len(population) for i1 in tqdm(range(epoches)): # 1 should be epoches later fitness_score = [] for i2 in range(population_size): fitness_score.append(fitness(population[i2],chromosome_size)) #fitness score initialisation ft.append(sum(fitness_score)/population_size) pop = np.concatenate((population, np.expand_dims(fitness_score, axis=1)), axis=1) sorted_indices = np.argsort(pop[:, -1]) pop_sorted = pop[sorted_indices] pop = pop_sorted[:, :-1] best_parents_muted = [] best_parents = pop[-num_best_parents:] best_parents_muted = [mutation(best_parents[i], chromosome_size) for i in range(num_best_parents)] pop[0:num_best_parents] = best_parents_muted population = pop if ft[-1] == 1000: # this should be calculated accurately. In each case the model might pass the potimum solution, so whenever it is touching the solution&#39;s score we should stop the training print(&#39;Woowww, the model could find the solution!!&#39;) print(&#39;Here is an example of a solution : &#39;,population[-1]) success_booelan = True break return population, ft, success_booelan The genetic algorithm (GA) employs a selection process to choose parents with higher fitness scores for reproduction through mutation or crossover. The resulting offspring are added to the population, while chromosomes with lower fitness scores are excluded from the next training round. The line ‘if ft[-1] == 1000’ checks if the latest fitness score indicates convergence to a solution. If the condition is true, the loop breaks, and the method terminates, making way for the execution of subsequent blocks.&#34; HINT: After reaching the solution or finding the global optimum of the solution space, it is possible for the program to continue executing operations. To ensure that the program terminates after finding the best fitness score, a break statement is used. The break statement exits the loop and ensures that no further operations are performed. In the figure above, we observe the step-wise behavior of the learning curve. The program remains at a fitness score of 0 for the first 28 epochs and then suddenly jumps to a fitness score of 100. During a typical run, the solution is reached after 70 epochs, but there is a brief period where the program gets stuck at a fitness score of 600. You can run the program to generate additional learning curves or check the “repo/images/learning_curve” directory for existing curves. After training the model, two additional methods, namely “fitness_curve_plot” and “n_queen_plot”, are called to display the learning curve and visualize the positions of the queens on the chessboard. Conclusion and Questions This article presented various blocks of Python code for solving the N-Queen problem. The code can be modified and enhanced in different ways to improve efficiency or add additional [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:516/1*xDfLY_fJp9sPIwD1cIcviA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>TAI #200: Anthropic’s Mythos Capability Step Change and Gated Release</title>
		<link>https://towardsai.net/p/machine-learning/tai-200-anthropics-mythos-capability-step-change-and-gated-release</link>
		
		<dc:creator><![CDATA[Towards AI Editorial Team]]></dc:creator>
		<pubDate>Wed, 15 Apr 2026 10:01:02 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.net/p/artificial-intelligence/tai-200-anthropics-mythos-capability-step-change-and-gated-release</guid>

					<description><![CDATA[Last Updated on April 16, 2026 by Editorial Team Author(s): Towards AI Editorial Team Originally published on Towards AI. What happened this week in AI by Louie This week, Anthropic unveiled a new flagship-class model, Claude Mythos Preview. It limited access to the model to “Project Glasswing”, a tightly gated cyber-defense consortium with AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, and more than 40 other organizations that maintain critical software infrastructure. Anthropic stresses that Mythos is a general-purpose frontier model, not a narrow cyber model, but one whose coding ability now surpasses that of all but the most skilled humans at finding and exploiting vulnerabilities. Its own risk report says the gap between Mythos and Opus 4.6 is larger than the gap between prior releases. My first reaction is that this potentially looks like the biggest capability step change in years. Not because Anthropic says so, since every lab loves a dramatic launch, but because the benchmark jumps, concrete exploit examples, and outside evaluation are hard to wave away. Anthropic shows Mythos at 77.8% on SWE-bench Pro vs. 53.4 for Opus 4.6, 93.9 on SWE-bench Verified vs. 80.8, 82.0 on Terminal-Bench 2.0 vs. 65.4, 83.1 on CyberGym vs. 66.6, and 64.7 on Humanity’s Last Exam with tools vs. 53.1. Anthropic Website An important independent data point came from the UK AI Security Institute. AISI found that Mythos succeeds 73% of the time on expert-level capture-the-flag tasks and became the first model to solve its 32-step corporate attack simulation, “The Last Ones,” end-to-end, succeeding in 3 of 10 attempts and averaging 22 of 32 steps, compared with 16 for Opus 4.6. AISI also reports that performance continued to improve up to the 100-million-token inference budget it tested, which is a quiet but potent hint that dangerous capability is increasingly governed by test-time compute and scaffolding. AISI notes that its ranges are easier than those in the real world because they lack active defenders, but the basic story is much harder to dismiss as Anthropic theater. Anthropic’s exploit examples are not toy demos. Mythos found a 27-year-old OpenBSD bug, a 16-year-old FFmpeg bug in code that automated testing tools hit five million times without catching it, and a 17-year-old FreeBSD remote code execution bug, later triaged as CVE-2026–4747, that grants root access to an unauthenticated internet user. Anthropic says Mythos can identify and exploit zero-days in every major OS and browser when directed to do so, and that over 99% of the vulnerabilities it has found remain unpatched. On one internal Firefox benchmark, Opus 4.6 produced working exploits twice out of several hundred attempts; Mythos produced 181. Anthropic also reports that engineers without formal security training have asked Mythos to find RCE bugs overnight and woken up to a working exploit. The Mythos system card also contains some fun and somewhat concerning stories. In an earlier Mythos version that managed to escape a sandbox, the researcher learned of it via an unexpected email from the model while “eating a sandwich in a park.” The same version then went further than asked and posted details of the exploit to several obscure public-facing websites. Earlier versions also sometimes tried to conceal disallowed actions, including reasoning that a final answer should not be “too accurate,” hiding unauthorized edits from git history, and obfuscating permission-elevation attempts. Anthropic says these severe incidents came from earlier versions, not the final Preview. Its framing is also interesting: Mythos is called Anthropic’s best-aligned released model to date, while also likely posing the greatest alignment risk it has ever shipped, because it is more capable and used on harder tasks. My read is that Mythos is materially larger than Opus in both active and total parameters, and likely trained on substantially more compute. Pricing is a clue. Mythos Preview is listed at $25 per million input tokens and $125 per million output, vs. $5 and $25 for Opus 4.6. For the last year, the frontier story has looked more like scaling reinforcement learning and inference-time compute than scaling raw model size. GPT-4.5, OpenAI’s largest chat model at the time, was a pure pretraining-scale bet and a reminder that base-model scaling alone was no longer obviously producing discontinuous jumps. That comparison is unfair in hindsight because GPT-4.5 was trained before the modern RL wave and never received the full post-training recipe that followed. Mythos suggests the interesting story is not “size is back” but “size plus the new RL-heavy playbook still works.” Anthropic is probably not alone on this curve. OpenAI’s next base model, reportedly codenamed “Spud,” has been described by Greg Brockman as a new pre-training with a “big model smell,” and a leaked internal memo suggests it is central to OpenAI’s next commercial push. Why should you care? I see three shifts in this release, and I think each is bigger than it looks. The first is scaling. Mythos, plus the rumored OpenAI Spud model, suggests the labs are reopening the giant base-model frontier on top of a much better RL stack. GPT-4.5’s muted reception made it easy to write off size scaling, but that read was always going to be unfair: GPT-4.5 was trained before the modern RL wave and never got the post-training recipe that followed. If big base models now compound with big RL, the next cycle probably does not look like tidy point upgrades, and the labs with the compute may pull further ahead of those that do not. The second is cyber economics. Mythos puts the long tail of under-audited software in real danger for the first time. Regional banks, hospital scheduling stacks, industrial dashboards, municipal systems, and the pile of neglected open-source dependencies most enterprises quietly run on were never worth a human week of attention. They are now worth an overnight Mythos job. I also expect the scarcity premium on hoarded zero-day exploits to collapse. If a frontier model can cheaply rediscover and then patch a bug that used to be worth years of [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*FFeHPD9Wa9t3rVJnS6-lOQ.png" medium="image"></media:content>
            	</item>
	</channel>
</rss>
