<?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.com/feed" rel="self" type="application/rss+xml" />
	<link>https://towardsai.com</link>
	<description>Making AI accessible to all</description>
	<lastBuildDate>Tue, 01 Sep 2026 08:21:52 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.7</generator>

<image>
	<url>https://towardsai.com/wp-content/uploads/2019/05/cropped-towards-ai-square-circle-png-32x32.png</url>
	<title>Towards AI</title>
	<link>https://towardsai.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Vercel&#039;s New Coding Agent Takes Away Your MCP Tool List. It Sends the Same 15 Schemas.</title>
		<link>https://towardsai.com/p/machine-learning/vercels-new-coding-agent-takes-away-your-mcp-tool-list-it-sends-the-same-15-schemas</link>
		
		<dc:creator><![CDATA[Chew Loong Nian - AI ENGINEER]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 10:30:47 +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.com/?p=53581</guid>

					<description><![CDATA[Author(s): Chew Loong Nian &#8211; AI ENGINEER Originally published on Towards AI. fx declares seventeen built-in tools, and a full turn with a subagent host carries fifteen function schemas. I measured a stock four-server MCP setup at 37 tools and 22,226 bytes — the exact payload this design keeps out of the request. Every few weeks I go through the same small humiliation. I add an MCP server to a coding agent because it looks useful, then I add a second one, then a third, and somewhere around the fourth my agent starts behaving like a person who has read the entire menu out loud before ordering. It picks the wrong tool. It picks a tool that is almost right. It calls the filesystem server’s read_file when the built-in read_file was sitting right there. Nothing is broken, exactly. The thing just gets duller. The author explains that many coding agents include every MCP tool’s schema in every request, inflating prompts and causing the model to “pick from a bloated menu.” By inspecting Vercel’s fx (a Zig coding agent) and measuring real MCP-server payload sizes, they show fx avoids this by using a compile-time tool registry and a search/deferral mechanism: MCP tools are not actually included in the model-facing tool list at the start of a turn, but instead are discovered and inserted only after the model selects a specific “door” tool by name. This results in stable, bounded tool exposure (typically fifteen function schemas on a full turn, despite many installed MCP servers) with special handling for vision and provider-executed tools. The article also quantifies the cost (extra steps and a hard ceiling of five search results per capability query), compares the approach to OpenAI Codex’s runtime-based deferral and spec budgeting, and concludes that fx trades extra round trips and tighter discovery limits for a more reliable tool list size—avoiding the failure mode where the model has too many options and chooses wrong. 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*_dhPbvMfPwTosi3AYYaZZw.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Z.ai’s Models Found 2,436 Vulnerabilities. The Weights Aren’t the Bottleneck — Your Patch Pipeline Is</title>
		<link>https://towardsai.com/p/machine-learning/z-ais-models-found-2436-vulnerabilities-the-weights-arent-the-bottleneck-your-patch-pipeline-is</link>
		
		<dc:creator><![CDATA[Decoding AI]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 10:30:24 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53583</guid>

					<description><![CDATA[Author(s): Decoding AI Originally published on Towards AI. 2,436 findings is a discovery number. Nothing in it is a remediation number. There is a particular kind of silence that follows a very productive week. On August 14, 2026, the AI lab Z.ai published a model and a ledger. The model was GLM-5.3. The ledger listed 2,436 software vulnerabilities the lab says its models found across 269 open-source projects (a cumulative count running from GLM-5.2 through GLM-5.3, rather than the output of a single release) — including the Linux kernel, Redis, WebKit and FreeBSD. Of those, 53 had been disclosed. The other 2,383 were under embargo. Read that pair again, because it is the whole story. About two percent of the findings are out in the open. Ninety-eight percent are in a queue. Nearly every write-up of the GLM-5.3 vulnerability findings focused on the release decision: the lab held the downloadable weights, targeting around August 28 for safety evaluation and hardening — its first delayed GLM weight release — after cyber capability “developed faster than we expected” during scaled post-training. That is a legitimate story. It is also the less consequential one. Here is the thesis, stated plainly so it survives being quoted out of context: the scarce resource in software security has flipped from finding vulnerabilities to fixing them, and the weight delay does nothing about the 2,383 findings already in the pipeline. Discovery is now something you buy by the token. Patch delivery still runs at the speed of whoever maintains the package — and we measured that speed. Key takeaways Z.ai’s vulnerability ledger listed 2,436 findings across 269 open-source projects as of August 14, 2026 (a cumulative total across GLM-5.2 and GLM-5.3 rather than one model’s output) — 107 critical, 990 high — with 53 disclosed and 2,383 still under embargo. GLM-5.3 scored 84.5% on CyberGym (finding known flaws) against 83.8% and 83.6% for two frontier competitors, but only 54.4% on ExploitBench against 78.0% — a 23.6-point gap between finding and weaponising. Z.ai says the listed vulnerabilities had gone undiscovered for an average of 26.6 years, the oldest introduced in 1981. The flaws were always there; the cost of noticing them collapsed. Our own measurement, August 20, 2026: 39.3% of 84 of the most-depended-on PyPI packages had shipped no release at all in the previous 90 days, and 15.5% none in a year. On npm, 28.3% of 46 core packages had shipped nothing in 90 days. Every cyber figure above is Z.ai’s own, produced in its configuration, with no independent replication as of publication. TL;DR: A model shipped in August 2026 with a hold on its downloadable weights because it got unexpectedly good at security work; the stated target of around August 28 passed with the flagship weights still unpublished. The industry read that as a story about model access. It is really a story about throughput. One lab’s evaluation run produced 2,436 vulnerability findings, 2,383 of them still undisclosed and waiting on fixes — while the projects on the receiving end ship at a cadence we measured directly, and for four in ten of the most-depended-on Python packages, that cadence over the last quarter was zero. Vulnerability discovery is scaling like software. Vulnerability remediation is still scaling like people. What did Z.ai actually ship, and why hold the weights? It shipped GLM-5.3 on August 14, 2026 through paid and controlled channels, while holding the downloadable weights and pointing at a target of around August 28. As of August 28, 2026 the flagship weights had not appeared: the zai-org/GLM-5.3 repository on Hugging Face was still a placeholder listing that date. The smaller GLM-5.3-Flash was released under an MIT licence on August 26, 2026. Z.ai stated that GLM-5.3 uses the same base model as GLM-5.2 and that every reported gain came from roughly a month of expanded post-training — more task environments, a broader work mix, more compute. It had deliberately included vulnerability-discovery work, but says the model progressed from finding isolated flaws toward planning complete exploitation chains: &#34;as we scaled post-training, cyber capability developed faster than we expected.&#34; The delay is a notable first for this lab’s open-weight line. It is also narrower than the headlines suggest. The model itself was already available at launch — through a paid coding plan, a hosted environment, and a trusted-access tier for selected security partners. What is being delayed is not capability access. It is irreversibility. A gated API can be rate-limited, logged, revoked and re-tuned after the fact. Published weights cannot. Z.ai acknowledged as much: once the weights are public, it will no longer control how people modify or use the model. Two weeks of hardening buys a better starting point for a permanent release, not a smaller total capability footprint. The frontier is broadly converging on metered release here — the strongest competing cyber model is behind a verified-partner program, and another lab ships its security-specialised model only to vetted defenders. But all of that operates on future capability, not on the findings already produced. What are the GLM-5.3 vulnerability findings, exactly? They are 2,436 entries in a ledger Z.ai published on August 14, 2026, covering 269 open-source projects after what the lab describes as expert review, screening and deduplication. The severity breakdown is 107 critical and 990 high — 1,097 findings in the top two bands. Named affected software includes the Linux kernel, Redis, WebKit and FreeBSD. Only 53 had been disclosed; 2,383 remained under embargo. Two details in that ledger deserve more attention than they got. The first is age. Z.ai reports the listed vulnerabilities had gone undiscovered for an average of 26.6 years, with the oldest introduced in 1981. These are not new bugs created by new code. They are old bugs nobody could afford to look for. That reframes the whole event: the software did not get worse this month. The economics of noticing got better. The second is provenance. Every cyber number here — benchmark scores and ledger alike — comes from Z.ai’s [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*bJESUQZbep1kEgIIoakeXw.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Claude’s Protein Design Hit Rate Was 26.8%. One Target Returned 0 for 90.</title>
		<link>https://towardsai.com/p/machine-learning/claudes-protein-design-hit-rate-was-26-8-one-target-returned-0-for-90</link>
		
		<dc:creator><![CDATA[Decoding AI]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 10:30:17 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53585</guid>

					<description><![CDATA[Author(s): Decoding AI Originally published on Towards AI. We refit Anthropic’s published per-target protein design counts on Aug 25, 2026. Ninety designs went into the wet lab against maltose-binding protein. Ninety came back with nothing. That is the part of the story that stopped us. On August 18, 2026, Anthropic published the results of an autonomous protein design campaign, and the number everyone repeated was the Claude protein design hit rate: 354 binders out of 1,320 designs, 26.8%, against an industry norm of 10–15%. It is a real result, independently validated in two contract labs. But sitting inside that 26.8% is a target where the agent produced ninety designs, every one of which was synthesized, expressed, and measured — and not one of them bound. Both facts came out of the same campaign, the same prompt, the same model. So we spent August 25 doing the arithmetic nobody in the coverage did: 26.8% is a portfolio average across sixteen targets, not the probability that your target works. Run the published per-target counts through a binomial test and a single shared hit rate is rejected at p ≈ 1.8 × 10⁻⁶³. Fit a model that allows targets to differ and the picture inverts: for a new target, the chance of landing below the 10% industry floor is about 38%. Key takeaways Anthropic’s campaign (published 2026–08–18) produced 354 binders from 1,320 designs — a pooled hit rate of 26.8% — but per-target rates ran from 72/90 on TREM2 to 0/90 on maltose-binding protein. Under a single 26.8% rate, MBP’s 0-for-90 result has probability 6.3 × 10⁻¹³ — roughly one in 1.6 trillion. The pooled rate is a mixture, not a per-target expectation. Our beta-binomial fit to the eight published per-target counts (run 2026–08–25) puts the 90% predictive interval for a new target at 0.1% to 84.7%, with a median of 18.6% — well below the 26.8% headline. On that fit, a 30-design batch against an unseen target has a 20.1% chance of returning zero binders, versus 0.0086% if you assume one shared rate — a factor of roughly 2,300. The in-silico confidence scores did not distinguish the failures: per Anthropic’s report, designs against MBP and BBF-14 scored about the same as designs against targets that worked. TL;DR: An autonomous agent orchestrated a dozen open-source protein design tools and beat expert human hit rates on most targets. That happened, and it matters. But the headline number is a portfolio statistic, and almost nobody deploys a portfolio — they deploy against one target, one ticket, one customer. When we modeled the published spread instead of the mean, the expected experience of a single new target looked dramatically worse and dramatically noisier than 26.8% implies. And the pipeline’s own confidence scores could not tell in advance which regime it was in. That combination — high average, enormous variance, uncalibrated self-assessment — is the shape of nearly every agentic AI benchmark result you will read this year. What did Claude’s protein design campaign actually measure? Anthropic gave Claude (Mythos Preview and Opus 4.8) a set of 16 protein targets and asked for 30 minibinders per target per design arm — small proteins engineered to latch onto a target, the mechanism behind a large share of modern biologic drugs. With three arms running, most targets ended up with 90 designs in the lab. Fifteen targets produced usable measurements; one, mature GDF-8, was dropped because the target aggregated in the assay. The agent did not invent a protein model. It installed and ran existing open-source tools: backbones came from PXDesign (358 designs), RFdiffusion3 (267), Genie 3 (185), FreeBindCraft (135), BoltzGen (134), RFdiffusion (118) and Proteina-Complexa (100), among others, with sequences mostly from SolubleMPNN and filtering through ESMFold2 and Protenix v2. What was new was the layer above: choosing the epitope, installing the software, combining it across 24 distinct workflows, and ranking the output with no human touching a design decision. Validation was independent. Adaptyv Bio’s wet-lab case study, published 2026–08–19, reports that the designs arrived anonymized — the lab did not know which model produced which sequence — and were run on surface plasmon resonance at five target concentrations in duplicate. 95% of designs expressed. 354 of 1,320 bound. That is a genuinely strong result and we are not going to shave it down. Against RBX1, an open design competition had produced 9 binders from 245 entries (3.7%); Claude produced 28 from 90. Anthropic had the competition’s winning design rebuilt and measured on the same assay plate: it bound at 45 nM, while Claude’s best bound at 3.9 nM, roughly ten times tighter. Why doesn’t Claude’s protein design hit rate apply to your target? Because the targets are not interchangeable, and the published per-target counts make that impossible to ignore. Here are the eight per-target results disclosed across Anthropic’s post, Adaptyv Bio’s case study and The Decoder’s technical breakdown of the report: Binders per target, from the published counts: TREM2–72 of 90 designs bound (80.0%) VEGF-A — 54 of 90 (60.0%) IL-7Rα — 49 of 90 (54.4%) RBX1–28 of 90 (31.1%) TNFα — 12 of 150 (8.0%) BBF-14–3 of 90 (3.3%) 15-PGDH — 1 of 30 (3.3%) MBP — 0 of 90 (0.0%) Pooled, all 15 targets — 354 of 1,320 (26.8%) Now ask the question the coverage skipped: if every design really had a 26.8% chance of binding, how surprised should we be by the bottom row? The answer is that we should be about as surprised as it is possible to be. The probability of drawing zero successes in 90 independent trials at p = 0.268 is 0.732 raised to the 90th power, or 6.3 × 10⁻¹³ — one in roughly 1.6 trillion. TREM2 is equally impossible from the other direction: getting 72 or more hits in 90 trials at that rate has probability 1.1 × 10⁻²⁵. Neither of those is a fluke you explain away. They are the model being wrong. We ran a formal likelihood-ratio test comparing one shared rate against a model [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*Z754YXPNAmvNt5WPs07FsA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>LLM-as-a-Judge: How to Build Reliable AI Evaluation Systems</title>
		<link>https://towardsai.com/p/machine-learning/llm-as-a-judge-how-to-build-reliable-ai-evaluation-systems</link>
		
		<dc:creator><![CDATA[Rohan Mistry]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:09:06 +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.com/?p=53587</guid>

					<description><![CDATA[Author(s): Rohan Mistry Originally published on Towards AI. Calibrate your judge. Detect its biases. Trust your scores. Your LLM judge might be lying to you. After introducing the problem of uncalibrated LLM evaluators, the article explains what LLM-as-a-judge actually is (a model scoring another model’s output using criteria/rubrics), why teams use it instead of human review or string/code checks, and the three common judging modes—single-output scoring, pairwise comparison, and reference-based scoring—arguing that pairwise is usually the best default. It reviews evidence that judges can align with human preferences only when properly calibrated for the relevant task, then details the key biases that must be designed around (like position bias and self-preference). The core implementation section provides a practical nine-step process: start from real failure modes, limit criteria, use binary decisions, force reasoning before verdicts, add few-shot anchors, decompose subjective judgments into sub-decisions, pin configuration, calibrate against human labels with proper agreement metrics, and ensemble when stakes are high. It concludes with monitoring/validation practices (“judging the judge”), where to place judges in CI/regression gates, pre-release comparisons, and production monitoring, when not to use a judge (when deterministic checks, cheap ground truth, or specialist knowledge applies), and the takeaway that an LLM judge is a small ML system that must be built, calibrated, versioned, and continuously validated. 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*GwZ8dkWMfemiSTpRMSmQqg.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Eye of the Infra — What is a Batch and an Epoch?</title>
		<link>https://towardsai.com/p/machine-learning/eye-of-the-infra-what-is-a-batch-and-an-epoch</link>
		
		<dc:creator><![CDATA[Sai Kaushik Ponnekanti]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:09:00 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53589</guid>

					<description><![CDATA[Author(s): Sai Kaushik Ponnekanti Originally published on Towards AI. Firstly, In the previous article, we founded a startup whose mission is to stop people from losing their life savings to fraudulent emails.. One thing we left out is that we forgot to name the startup. I think I understand why, we are engineers at heart and want to get our hands dirty as quickly as possible and as such started thinking about the product. Now, some customers are expressing interest and we have to create a brand. We came up with a quirky, funny and imaginative name “Phish &#38; Chips” (as our startup identifies spam emails. Really cool, right!). Let’s take a moment here and congratulate ourselves on taking the first step to creating the brand. Now let’s get back to the topic at hand. We started off the company with a dataset consisting of 100,000 emails which have already been pre-classified as “Spam” and “Not Spam”. Now in the previous article, we were talking about what training is Give the model some data → let it make a prediction → measure how wrong it is → adjust the weights → repeat. But we didn’t ask the question. “How do we give the 100,000 emails we have to the model?” First, when you think about it, it’s not such a big or great question. I mean u can think how does it matter right? But as you are going to see, it matters a whole lot when it comes to the infrastructure layer. Let’s get started. Option 1 The first thing that comes to mind is why not directly dump the 100,000 emails directly to the trainer and process them in one shot. You wouldn’t be wrong. So the pipeline looks something like this. This looks decent I must say. For any company to be successful, we need to try to break down our own ideas to see if there are any problems. We do have faith in our product and our company and we expect that we are going to be successful. Once the customer base starts growing, our 100,000 emails will also grow. So tomorrow it may grow to 10 Million and frankly even billions in the future. So what problems are we going to face by dumping the total training dataset to the model? Memory Our GPUs only have a finite amount of memory and frankly, the training data is not the only one using that memory. The model itself takes some memory and during the training, we need memory for intermediate results, gradients etc. Conclusion Processing the entire dataset in one shot won’t scale as the dataset grows. Option 2 The immediate next thing that comes to mind is what happens if we try and process 1 at a time. You might think this might be an overkill and you are right but let’s run through the option first. So, the pipeline looks like this. Then we do Email 2, then Email 3, so on until 100,000. Let’s try and see what the problems with this approach are. Wasting GPU GPUs are very good at doing lots of similar computations in parallel. In this approach, we are literally feeding GPU 1 email at a time. We are not giving the GPUs enough work. So, we are letting our expensive GPUs waste their power. Signal As we are processing 1 email at a time, let’s consider this scenario. The email we are processing is an obvious “Spam” email. The model makes a prediction, computes the loss and updates the weights based on this 1 email. Now, the next email comes in. It may look completely different to the first email. So the weights change again. As you can see, processing 1 email at a time gives a very noisy signal on which direction the model moves. Conclusion So, processing 1 email at a time is inefficient. Option 3 This leads us to the next option, why not meet somewhere in the middle. How about we process 100 emails at a time. This is pretty much what we call a batch. To put it in a more formal definition. A batch is a set of training examples that we process together before performing an update to the model and the size of the batch is called Batch Size. So if you look at it, we are not trying to fit the entire dataset into memory and we are also trying to give GPU some amount of work at a time. Step In Option 3, if someone were to ask the question “When are the weights being updated?”, you can clearly answer that right after a batch is processed. This is exactly what is called a Step. So, going back to our original training dataset of 100,000 emails. Processing 100 emails at a time would result in 100,000/100 → 1000 steps. There are some exceptions to it but let’s not go there yet. We’ll cross that bridge when we get there. Epoch I know I am throwing a lot of terminology but believe me this is the last one. We have identified that processing 100,000 emails 100 at a time results in our model training having 1000 steps. So after 1000 steps, our model should have seen every one of our 100,000 emails. This is exactly what is called an Epoch 1 Epoch → 1 complete pass through the training dataset. You may now ask the question, “isn’t that the end of the model training. I mean once the model processes all the emails, can’t we consider the model trained?” That would be a great question. Answer to that would be, not quite. Processing each email once wouldn’t necessarily mean the model learnt everything because after every step, we only update the weights a little. So after 1 epoch, our model might be better than where it started but doesn’t mean it’s great. So what do we do? We go through the training dataset over and over again. [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/0*sdTi28DiPdkPbUEU.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Beyond a Single Model: Mastering Ensemble Learning in ML</title>
		<link>https://towardsai.com/p/machine-learning/beyond-a-single-model-mastering-ensemble-learning-in-ml</link>
		
		<dc:creator><![CDATA[Naveen]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:08:27 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53591</guid>

					<description><![CDATA[Author(s): Naveen Originally published on Towards AI. Discover how combining multiple machine learning models — using techniques like bagging, boosting, and stacking — can dramatically improve prediction accuracy and create more robust, production-ready systems. Instead of relying on a single, fallible model, ensemble learning strategically combines multiple models to achieve superior performance, balancing the bias-variance tradeoff to deliver robust and highly accurate predictions. Figure 1: Multi-Layer Stacking Architecture — Diversified Level-0 base models feeding out-of-fold predictions to a Level-1 Meta-Learner.After introducing ensemble learning, the article explains why single-model approaches struggle with the bias-variance tradeoff and then details three core ensemble strategies: bagging (variance reduction via parallel training on bootstrapped samples, often exemplified by Random Forest), boosting (bias reduction via sequential error correction, including AdaBoost and gradient boosting methods like XGBoost/LightGBM/CatBoost), and stacking (a two-level system that uses diverse base models plus a meta-model trained on out-of-fold predictions to optimally combine strengths). It highlights practical implementation ideas with scikit-learn, warns about common pitfalls such as data leakage, and closes with guidance for production use—balancing accuracy gains against latency, cost, and maintainability—plus interpretability support using SHAP and a final emphasis on designing cooperative model systems rather than searching for a single “perfect” model. 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*HDaegQtVw3im3rZPAKmPyA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Knowledge Graphs vs. Vector DBs: Which One Should You Use?</title>
		<link>https://towardsai.com/p/machine-learning/knowledge-graphs-vs-vector-dbs-which-one-should-you-use</link>
		
		<dc:creator><![CDATA[Naveen]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:08:11 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53593</guid>

					<description><![CDATA[Author(s): Naveen Originally published on Towards AI. Stop choosing between structured knowledge and semantic search. Learn when to use Knowledge Graphs for explicit facts and Vector Databases for implicit similarity to build smarter, more reliable AI systems. Explore the architectural tradeoff between explicit knowledge graphs and semantic vector databases, learning when to deploy each for building scalable, factually-grounded AI without hallucinations. Figure 1: The mechanics of a Knowledge Graph: atomic Subject-Predicate-Object (RDF) triples forming a traversable, logical network for deterministic query execution.The article explains how knowledge graphs and vector databases represent and retrieve information differently—KGs by explicit, deterministic SPO triples and graph traversals (e.g., Cypher/SPARQL) and vector DBs by embedding text into high-dimensional space for semantic similarity using ANN methods like HNSW. It then argues that the most practical enterprise approach is often hybrid GraphRAG: use vector search to find relevant “seed entities,” map them into a knowledge graph, and traverse multi-hop relationships to provide grounded, auditable context for LLM responses. Finally, it discusses production concerns and failure modes (KG rigidity/cold starts and VDB garbage-in/garbage-out or memory constraints), presents real-world use cases for each paradigm, and concludes with a recommendation for neuro-symbolic fusion depending on whether the domain requires strict reasoning or flexible semantic discovery. 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*SUujIt_z9NYJhUWXzoAbVA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Qwen Code Ditched Google 10 Months Ago. Why Do 1,110 Files Still Say &#8220;Copyright Google&#8221;?</title>
		<link>https://towardsai.com/p/machine-learning/qwen-code-ditched-google-10-months-ago-why-do-1110-files-still-say-copyright-google</link>
		
		<dc:creator><![CDATA[Chew Loong Nian - AI ENGINEER]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:08:00 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53595</guid>

					<description><![CDATA[Author(s): Chew Loong Nian &#8211; AI ENGINEER Originally published on Towards AI. I checked every one of them against every blob Google’s Gemini CLI has ever committed. The header is still literally true for 58. I was reading Qwen Code’s source last night for an unrelated reason — I wanted to see how it routes a tool call to a non-Qwen provider — and I opened a file about a memory connector. The first thing on the screen was a copyright notice. It said Google. The article tests whether Qwen Code’s many “Copyright Google LLC” headers actually reflect code provenance. After finding that specific files appear to be “signed” by Google, the author designs a rigorous audit: first, classify which headers each TypeScript file carries; then verify the header claim by checking whether each file’s exact bytes (git blobs) ever appear in any commit of Google’s Gemini CLI history, avoiding confounds from post-fork edits and filename/path changes. The analysis is broken into buckets (verbatim byte-identical copies, edited at the same path, moved/edited, and “never upstream” cases), and it’s extended by weighting results by line counts and running the reverse direction to ensure there’s no Google code hiding under Qwen headers. The key findings are that only 58 file copies (5.2%) remain byte-identical to Google in the relevant window, and only 0.8% of lines under Google headers are truly Google bytes; moreover, the “mem0” connector’s files are not found anywhere upstream despite being labeled. The author concludes that copyright headers are mostly sticky boilerplate rather than reliable provenance, since tooling and reviews enforce the presence of the block but don’t ensure it’s updated or checked against actual authorship, and the result is a practical warning to run this kind of byte-level audit on vendored/folkor derivative code before trusting header-based attribution. 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*0mIiMPjmyhyD3tTtNKouDQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>ContextFusion: The Context Brain Your LLM Apps Are Missing</title>
		<link>https://towardsai.com/p/machine-learning/contextfusion-the-context-brain-your-llm-apps-are-missing</link>
		
		<dc:creator><![CDATA[Rohan R]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:07:28 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53597</guid>

					<description><![CDATA[Author(s): Rohan R Originally published on Towards AI. A deep dive for users who want results and developers who want control TL;DR (For the Impatient) Normal users: Install context-portfolio-optimizer, run cpo compile ./your-docs --budget 4000, and stop overpaying for tokens. Developers: Middleware pipeline that ingests heterogeneous sources → normalizes → precomputes → optimizes via multi-objective knapsack → compiles provider-specific payloads with delta fusion for agents. Both groups get 60–99% token reduction with identical answer quality. Part 1: For Normal Users — “Just Make My LLM Cheaper and Faster” The Problem You Actually Face You’re building with LLMs. Maybe it’s a chatbot over your company docs. Maybe it’s a coding assistant. Maybe it’s an agent that needs to remember context across 20 turns. You keep hitting the same frustrations: “Why is this API call so expensive?” — You’re sending 8,000 tokens when 800 would suffice “Why does it take 10 seconds to respond?” — Latency scales with prompt size “Why does my agent forget everything?” — You’re not managing context deltas across turns “Why do I have to rewrite everything when I switch from GPT-4 to Claude?” — Hardcoded prompt formats You’ve tried RAG. You’ve tried chunking. But you’re still blindly stuffing retrieved chunks into prompts without knowing which ones actually matter. What ContextFusion Does (No Jargon) Think of it like a smart travel packer for your LLM trips. You have a weight limit (token budget). You have dozens of items (documents, code, images). Some items are essential. Some are nice-to-have. Some are duplicates. Some are risky (outdated, untrusted). ContextFusion: Unpacks everything — PDFs, Word docs, spreadsheets, images, code files Weighs and labels each item — How useful? How risky? How heavy? Packs the optimal suitcase — Maximum value within your weight limit Formats it for your destination — OpenAI’s preferred style, Anthropic’s format, or local Ollama And for return trips (agent conversations), it remembers what you already packed and only adds what’s new. Real Results Benchmarks run with Claude Sonnet 4.6 on production-like workloads. Full methodology at github.com/rotsl/context-fusion/benchmarks Getting Started (Three Options) Option A: NPM Wrapper (Easiest — No Python Required) # One-time setupnpm install -g @rotsl/contextfusionnpx @rotsl/contextfusion setup# Create API keys filenpx @rotsl/contextfusion env# Edit .env with your OPENAI_API_KEY or ANTHROPIC_API_KEY# Run optimizationnpx @rotsl/contextfusion run ./my-documents \ --query &#34;Summarize key findings&#34; \ --provider anthropic \ --model claude-sonnet-4-6 \ --budget 4000# Launch Web UInpx @rotsl/contextfusion ui --port 8080 Option B: Python Package (More Control) pip install context-portfolio-optimizer# Set up environmentcat &#62; .env &#60;&#60; &#39;EOF&#39;ANTHROPIC_API_KEY=your_key_hereOPENAI_API_KEY=your_key_hereEOF# Run CLIcpo run ./my-documents --budget 4000 --query &#34;What are the main points?&#34;# Or compile for specific task typecpo compile ./my-codebase \ --task &#34;Explain this function&#34; \ --provider openai \ --model gpt-5-mini \ --mode code \ --budget 3000 Option C: Docker (Isolated, Reproducible) docker build -t context-fusion:latest .docker run --rm -it -v &#34;$(pwd)&#34;:/app context-fusion:latest run ./data --budget 3000 The Web UI: See What Your LLM Actually Receives Run cpo ui --port 8080 and open your browser. You&#39;ll see: Run stats: Files ingested, blocks selected, total tokens Representation usage: Which compact variants were chosen Selected blocks: Source, representation type, utility score, token estimate Context preview: Exactly what gets sent to the LLM Model answer: Optional direct comparison This transparency is rare. Most RAG tools are black boxes. ContextFusion shows its work. Common Use Cases When ContextFusion Helps Most &#x2705; Multi-provider setups — Same pipeline, different output formats&#x2705; Cost-sensitive production — 60–99% token reduction&#x2705; Agent conversations — Delta fusion prevents token churn&#x2705; Complex ingestion — PDFs, images, code, spreadsheets unified&#x2705; Latency requirements — Precomputation + caching When You Might Not Need It &#x274C; Simple single-turn Q&#38;A with tiny documents&#x274C; You’re already heavily invested in a specific RAG framework and happy with costs&#x274C; You need real-time streaming with sub-100ms latency (ContextFusion adds 50–200ms optimization overhead) Part 2: For Developers — “How This Actually Works” Architecture Overview ┌─────────────────────────────────────────────────────────────────┐│ INGESTION LAYER ││ PDF │ DOCX │ CSV │ JSON │ Images (OCR) │ Code │ Markdown │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ NORMALIZATION LAYER ││ Convert all sources to uniform ContextBlock objects ││ - source_type, content_hash, created_at, metadata │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ REPRESENTATION LAYER ││ Precompute compact variants per block: ││ - universal_summary (general purpose) ││ - qa_extractive (question-answering focused) ││ - code_signature (functions, classes, dependencies) ││ - agent_condensed (working memory format) │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ PRECOMPUTE PIPELINE ││ Store: fingerprints, summaries, token stats, ││ retrieval features, compact variants in .cpo_cache/ │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ RETRIEVAL LAYER ││ Query classification → Lexical retrieval (top-100) ││ → Fast rerank (top-20/25) → Candidate set │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ MULTI-OBJECTIVE PLANNER (Core) ││ ││ maximize Σ( w_u·utility - w_r·risk - w_t·token_cost ││ - w_l·latency + w_c·cacheability + w_d·diversity ) ││ ││ subject to: Σ(token_i) ≤ budget ││ ││ Selects optimal representation variant per block │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ COMPRESSION LAYER ││ - JSON minification ││ - Citation compaction (Source URI → [id]) ││ - Schema field pruning ││ Levels: none │ light │ medium │ aggressive │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ DELTA FUSION (Agent Mode) ││ Compute ContextDelta: ││ - added_blocks: new since last turn ││ - updated_blocks: changed content ││ - removed_blocks: no longer relevant ││ - unchanged_block_ids: reuse from cache │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ PROVIDER ADAPTER LAYER ││ Compile provider-specific payloads: ││ - openai: chat.completions format ││ - anthropic: messages with XML citations ││ - ollama: local API structure ││ - openai_compatible: generic wrapper │└─────────────────────────────────────────────────────────────────┘ ↓┌─────────────────────────────────────────────────────────────────┐│ CACHE-AWARE ASSEMBLY ││ Segment into: ││ - stable: system instructions, citation maps, cacheable blocks ││ - dynamic: volatile content, real-time data │└─────────────────────────────────────────────────────────────────┘ The Knapsack Formulation: Why This Isn’t Just “Smart Chunking” Most RAG tools use semantic similarity: embed query, embed chunks, return top-k. This fails when: Your budget is 4,000 tokens and you have 50 relevant chunks of 500 tokens each Some chunks are high-utility but high-risk (outdated documentation) Some chunks are cacheable, others must be fresh You need diversity (don’t send 5 versions of the same information) ContextFusion’s planner treats this as a constrained optimization problem: # Pseudocode of the core algorithmdef select_context_blocks(candidates, budget, weights): &#34;&#34;&#34; candidates: List[ContextBlock with multiple representation variants] budget: int (token limit) weights: dict[str, float] (utility, risk, latency, cacheability, diversity) [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*ZeJ8auXVhxEOIOfrxS4PwQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Finding the Right Answers from Thousands of Documents: A Smarter RAG Approach</title>
		<link>https://towardsai.com/p/machine-learning/finding-the-right-answers-from-thousands-of-documents-a-smarter-rag-approach</link>
		
		<dc:creator><![CDATA[Shrinidhi Atmakur]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 09:05:22 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=53599</guid>

					<description><![CDATA[Author(s): Shrinidhi Atmakur Originally published on Towards AI. Finding the Right Answers from Thousands of Documents: A Smarter RAG Approach Introduction RAG is often presented as a simple, three-step architecture: put documents into a vector database, convert the user’s question into an embedding, retrieve a handful of chunks, and hand them to an LLM. That approach is a great proof of concept. It is also where most RAG projects quietly stall. But what happens when the knowledge base grows to hundreds or thousands of documents? Retrieval becomes more challenging, irrelevant chunks can reach the LLM, token consumption increases, and the quality of the final answer becomes increasingly dependent on retrieval quality. This article shares information on building a production-ready, multi-stage RAG pipeline that can scale without simply sending more and more context to the LLM. RAG in Two Lines Retrieval-Augmented Generation allows an AI model to answer questions using external knowledge. Instead of relying only on the LLM’s internal knowledge, the system retrieves relevant information from a knowledge base and provides it to the model as context before generating an answer. User Question → Retrieve Relevant Context → LLM → Answer The important word here is relevant.A powerful LLM cannot consistently produce high-quality answers if the retrieval system provides incomplete or irrelevant context. The Problem With Simple Vector Search A typical RAG implementation looks like this Documents → Chunk Documents → Create Embeddings → Store in Vector DB And on the query side:User Question → Create Query Embedding → Vector Search → Retrieve Chunks → Send to LLM → Generate Answer For a small dataset, this approach may work perfectly well. However, as the knowledge base grows, several challenges start to appear. ScalingWith thousands of documents, there may be hundreds of thousands of chunks. A vector search may return content that is semantically similar but does not actually answer the user’s question. Response TimeOne common solution is to retrieve more chunks. But more chunks mean more processing and potentially more context sent to the LLM. Token ConsumptionNot every retrieved chunk is useful. Passing 30 or 50 chunks directly to the LLM can significantly increase token consumption while adding unnecessary noise. Response QualitySemantic similarity does not always mean answer relevance. The 4-Stage Hybrid Retrieval Pipeline The overall philosophy is:Retrieve broadly. Combine intelligently. Rerank precisely. Then let the LLM reason. Stage 1: Embedding and Candidate Retrieval The first stage focuses on recall. The objective is not necessarily to find the perfect chunks immediately. Instead, the objective is to identify a wider set of potentially relevant candidates. Documents are split into chunks and converted into embeddings. These embeddings are stored in a vector database such as ChromaDB. When a user submits a question, the query is converted into an embedding using a model such as: all-MiniLM-L6-v2 This model produces vector representation of the text. The vector database then searches for semantically similar chunks.For example:User Query: “How do I rotate secrets?”Query Embedding -&#62; Vector Database -&#62;Top 50 Candidate Chunks The important idea is to retrieve a wider net of candidates. Vector search is fast and excellent at identifying semantic similarity, making it an ideal first stage. But semantic search should not be the only retrieval mechanism. Stage 2: BM25 and Reciprocal Rank Fusion Vector search is good at understanding semantic meaning, but it may miss exact keywords, error codes, commands, or technical terms. BM25 complements vector search by performing keyword-based retrieval. Instead of choosing one approach, the results from both searches are combined using Reciprocal Rank Fusion (RRF). RRF uses the ranking position of each result rather than directly comparing scores from different retrieval methods.Vector Search + BM25 → RRF Fusion → Better Candidate Ranking This creates a hybrid retrieval mechanism that combines semantic understanding with exact keyword matching. Stage 3: Cross-Encoder Reranking After the first two stages, the pipeline may have reduced thousands of chunks to perhaps 20 or 30 strong candidates. The next question is: Which of these chunks actually answers the user’s question? This is where a cross-encoder becomes useful. An embedding model processes the query and document separately and compares their vector representations. A cross-encoder processes them together:Query + Candidate Chunk → Cross-Encoder → Relevance Score For example:Query: “How do I rotate Cloud secrets?” Candidate Scores:0.98 Cloud Secret Manager supports automatic rotation…0.81 Secret lifecycle defines credential management…0.22 Cloud provides several storage services…0.07 Metadata helps organize enterprise data… The cross-encoder can make a much more precise relevance decision because it sees the query and candidate chunk together. The trade-off is performance. A cross-encoder is slower than vector search, so running it against thousands of chunks would be inefficient. That is why the earlier stages are important:100,000 Chunks → Vector + BM25 Retrieval → 30 Candidates → Cross-Encoder → Top 5 This follows a simple principle: Use fast retrieval to reduce the search space, then use more precise models on a smaller candidate set. Stage 4: LLM Answer Generation Only after the retrieval and ranking stages do we send context to the LLM. The final top-ranked chunks are assembled into a context prompt and passed to Mistral, or any other LLM.Top Relevant Chunks → Context Builder → Mistral / LLM → Final Answer A simple prompt could instruct the model to:* Answer using only the provided context.* Avoid making unsupported claims.* Clearly state when the answer cannot be found.* Provide source information where possible. The LLM can now focus on what it does best: reasoning, connecting information, summarizing, and generating a clear response. It does not need to search through 50 loosely related chunks. How the Complete Pipeline Works Imagine a knowledge base containing:2,000 Documents -&#62; 100,000 ChunksA user asks: How can I troubleshoot a failed secret rotation?The pipeline could work like this: Every stage has a specific purpose. Instead of asking one component to do everything, the pipeline allows each component to do what it is best at. Best Practices for Fine-Tuning the Pipeline A RAG pipeline should be tuned based on the type and size of the knowledge base. [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*FUNBUtJOykn5t_KIokLWFw.jpeg" medium="image"></media:content>
            	</item>
	</channel>
</rss>
