<?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>Fri, 25 Sep 2026 09:34:25 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.9</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>Structured Data Extraction With AI That “Can’t Hallucinate”</title>
		<link>https://towardsai.com/p/machine-learning/structured-data-extraction-with-ai-that-cant-hallucinate-2</link>
		
		<dc:creator><![CDATA[Umair Ali Khan, Ph.D.]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 10:31:54 +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=54100</guid>

					<description><![CDATA[Author(s): Umair Ali Khan, Ph.D. Originally published on Towards AI. How AI decision models offer a fast and cost-effective approach to turning unstructured text into decisions Most of the organizational data is unstructured, such as incident reports, support tickets, maintenance logs, call-center transcripts, and customer reviews. Image source: https://stock.adobe.com (Licensed)The article explains why large language models are often an inefficient, high-latency, and sometimes unreliable way to perform “structured decision” extraction (like classification, routing, and scoring) and frames a better alternative: specialized decision models that output calibrated probabilities over predefined answer spaces. Using TypeSafe AI’s Jev as an example, it describes how decision models operate on a provided “state” plus “questions,” returning typed outputs (Choice, Score, Noul) with probabilities—preventing invalid answers (“can’t hallucinate”) while still requiring thresholding and validation to manage uncertainty. It also covers how to integrate decision models into real workflows (routing high-confidence cases automatically, escalating uncertain or high-severity cases) and where they fit in the AI stack: as a specialized component that complements LLMs and other extraction methods, especially when values can be represented as constrained candidates rather than fully open-ended text. 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*jeOuuoJgbx8vAFgtJsLLAA.jpeg" medium="image"></media:content>
            	</item>
		<item>
		<title>Structured Data Extraction With AI That “Can’t Hallucinate”</title>
		<link>https://towardsai.com/p/machine-learning/structured-data-extraction-with-ai-that-cant-hallucinate</link>
		
		<dc:creator><![CDATA[Umair Ali Khan, Ph.D.]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 10:31:54 +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=54049</guid>

					<description><![CDATA[Author(s): Umair Ali Khan, Ph.D. Originally published on Towards AI. How AI decision models offer a fast and cost-effective approach to turning unstructured text into decisions Most of the organizational data is unstructured, such as incident reports, support tickets, maintenance logs, call-center transcripts, and customer reviews. Image source: https://stock.adobe.com (Licensed)The article explains why large language models (LLMs) are often a poor fit for “structured extraction” when the downstream need is a single bounded decision (e.g., classification, routing, scoring, or filtering). It argues that LLMs are heavyweight for these tasks and can suffer from higher latency, higher cost, and unreliable uncertainty estimates. As an alternative, it introduces TypeSafe AI’s decision model (Jev) and describes how decision models are designed to return typed answers from predefined option spaces with calibrated probabilities. The piece outlines Jev’s core components (state and questions) and its supported output types (Choice, Score, and Noul), then walks through a practical manufacturing incident example showing how structured probabilistic outputs can drive automation with human review for uncertain cases. Finally, it clarifies where decision models fit in an AI stack—useful for bounded judgments, escalation/guardrails, and large-scale processing—while noting their limitations (no arbitrary value extraction, and reliance on text-only state at the time) and emphasizing the value of specialization alongside LLMs rather than replacement. 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*jeOuuoJgbx8vAFgtJsLLAA.jpeg" medium="image"></media:content>
            	</item>
		<item>
		<title>Claude&#8217;s New addTools() Can Reuse 98.7% of Your Next Request. Editing tools[] Reuses None.</title>
		<link>https://towardsai.com/p/machine-learning/claudes-new-addtools-can-reuse-98-7-of-your-next-request-editing-tools-reuses-none-2</link>
		
		<dc:creator><![CDATA[Chew Loong Nian - AI ENGINEER]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 09:29:22 +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=54096</guid>

					<description><![CDATA[Author(s): Chew Loong Nian &#8211; AI ENGINEER Originally published on Towards AI. Anthropic’s SDK 0.128.0, released with Claude Opus 5.5, can hand the model a new tool mid-run without touching tools[]. It needs one beta flag the runner won’t add for you. If your Claude agent picks up a new tool halfway through a long conversation, the way you add it decides how much of the next request can still come from the prompt cache: 98.7% of it with the new runner.addTools(), none if you edit tools[]. After introducing the problem of tool changes during long runs, the article explains what changed in the Anthropic SDK (TypeScript 0.128.0) and why editing tools[] is expensive: tool definitions are at the front of the prompt-cached prefix, so changing them forces a full cache miss. It then shows how addTools() avoids that by leaving tools[] intact and instead appending a system message containing a tool_addition block, so only the appended part is processed as new input. The author provides and walks through a reproducible Node script that measures request JSON reuse, demonstrating up to 98.7% shared prefix with addTools() versus near-zero reuse when updating tools[], and shows how the gap grows with conversation length. Key caveats include needing the inline-tools-2026-09-15 beta header/param (not auto-added by the runner), model limitations, and behavioral details like one special case that can still cause a full miss, plus how pause turns delay tool change propagation while both addition/removal are immediate on the agent side. The piece ends with a practical verdict: keep your initial tools[] unchanged and use addTools(), but add the beta flag explicitly for supported models. 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*PQPDhVBIYAzYTqEV_Tbd9Q.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Claude&#8217;s New addTools() Can Reuse 98.7% of Your Next Request. Editing tools[] Reuses None.</title>
		<link>https://towardsai.com/p/machine-learning/claudes-new-addtools-can-reuse-98-7-of-your-next-request-editing-tools-reuses-none</link>
		
		<dc:creator><![CDATA[Chew Loong Nian - AI ENGINEER]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 09:29:22 +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=54001</guid>

					<description><![CDATA[Author(s): Chew Loong Nian &#8211; AI ENGINEER Originally published on Towards AI. Anthropic’s SDK 0.128.0, released with Claude Opus 5.5, can hand the model a new tool mid-run without touching tools[]. It needs one beta flag the runner won’t add for you. If your Claude agent picks up a new tool halfway through a long conversation, the way you add it decides how much of the next request can still come from the prompt cache: 98.7% of it with the new runner.addTools(), none if you edit tools[]. The article explains what changed in Anthropic’s SDK 0.128.0: a new inline tool runner supports addTools() and removeTools(), allowing tools to be added during an active conversation. It contrasts this with the older approach of editing tools[], which is expensive because tool definitions sit at the front of the cached prompt prefix—so changing them invalidates the entire cache. With addTools(), the existing cached prefix remains intact and the new tool is sent as an appended system message, yielding very high request reuse (measured up to 98.7% on a 40-turn conversation). It provides a no-API-key Node.js script to measure request-body reuse, shows how the cache-reuse gap grows as conversation length increases, and calls out a key gotcha: you must explicitly include the inline-tools-2026-09-15 beta in the runner parameters because the SDK will not add it automatically. Finally, it notes which models and platforms support mid-conversation tool changes, plus several practical details (edge cases that can cause full misses, how pause turns delay the change, and that add/remove actions take effect immediately on the next step), ending with a recommendation to keep tools[] unchanged and always add the required beta flag. 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*PQPDhVBIYAzYTqEV_Tbd9Q.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Four Ways to Reach a Model in Another Azure Region From Microsoft Foundry</title>
		<link>https://towardsai.com/p/machine-learning/four-ways-to-reach-a-model-in-another-azure-region-from-microsoft-foundry-2</link>
		
		<dc:creator><![CDATA[Dave R - Microsoft Azure &#38; AI MVP☁️]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 09:29: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=54098</guid>

					<description><![CDATA[Author(s): Dave R &#124; Microsoft Azure &#038; AI MVP ☁️ Originally published on Towards AI. How each pattern handles identity, routing, and private networking, and which Foundry features stop working when a gateway sits in the path. Microsoft Foundry model availability is regional, so the model or Foundry Agent Service feature you need can live outside the region your project was approved for. Foundry supports four ways to reach it, and they differ in who owns identity, routing, and the network path. One of them also makes first-party tools such as SharePoint grounding fail with bad_request. This guide compares all four patterns, shows the API Management option running on a fully private network, lists which features survive the hop, and ends with a decision flow you can apply to your own landing zone. Four patterns connecting a Foundry project in one Azure region to model deployments in another region.The article explains why cross-region model access is an ownership decision across three boundaries—control plane, identity, and the data path—and then details four supported patterns. Pattern 1 is a direct Foundry-to-Foundry connection that provides static model governance but cannot enforce per-call policies like token limits, metrics, caching, or failover. Pattern 2 uses Azure API Management (APIM) as a model gateway, with one parameterized route per deployment type so a platform team can centrally apply managed identity, routing, and response labeling while gaining token budgets, metrics, caching, and resilience controls; it also shows how to run this fully privately using private endpoints and private DNS. Pattern 3 places APIM on the agent ingress for governance and observability, but it cannot replace the caller’s identity on the agent surface, so key first-party on-behalf-of capabilities depend on Foundry validating the caller token. Pattern 4 adapts routing for the Responses API, where the model name is in the request body; it relies on Foundry’s dynamic model connections rather than a single APIM route, trading centralized routing visibility for cleaner dispatch. Finally, it summarizes what still works when traffic goes through a gateway (e.g., state-bearing agents and most routing) and what breaks or must be moved (notably first-party grounding with gateway-routed calls), provides guidance for private networking end-to-end, and closes with a decision flow and recommended build order. 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*Q1yDOj5ZCvevpSjGBuXC9Q.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Four Ways to Reach a Model in Another Azure Region From Microsoft Foundry</title>
		<link>https://towardsai.com/p/machine-learning/four-ways-to-reach-a-model-in-another-azure-region-from-microsoft-foundry</link>
		
		<dc:creator><![CDATA[Dave R - Microsoft Azure &#38; AI MVP☁️]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 09:29: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=54003</guid>

					<description><![CDATA[Author(s): Dave R &#124; Microsoft Azure &#038; AI MVP ☁️ Originally published on Towards AI. How each pattern handles identity, routing, and private networking, and which Foundry features stop working when a gateway sits in the path. Microsoft Foundry model availability is regional, so the model or Foundry Agent Service feature you need can live outside the region your project was approved for. Foundry supports four ways to reach it, and they differ in who owns identity, routing, and the network path. One of them also makes first-party tools such as SharePoint grounding fail with bad_request. This guide compares all four patterns, shows the API Management option running on a fully private network, lists which features survive the hop, and ends with a decision flow you can apply to your own landing zone. Four patterns connecting a Foundry project in one Azure region to model deployments in another region.The article explains why cross-region model access is fundamentally an ownership decision across three boundaries—control plane, identity, and the data path—and then lays out four supported patterns for reaching a remote Foundry model. It starts with a direct Foundry-to-Foundry connection (simple, but lacking per-call enforcement), then covers using Azure API Management (APIM) as a model gateway with a parameterized single route (enabling token limits, token metrics, caching, load balancing, and circuit breaking). Next it presents APIM in front of the agent surface for stronger ingress governance (but with firm constraints because Foundry still must validate the caller token for on-behalf-of scenarios and tools). Finally, it describes dynamic model connections for the Responses API where the model name is in the JSON body (shifting routing decisions to the project). The guide details what continues to work through an APIM “gateway hop,” what doesn’t (notably first-party on-behalf-of tools), how to keep content filtering and monitoring consistent, and how to implement the gateway pattern fully privately using subnets, private endpoints, and private DNS. It concludes with a decision flow and build order, emphasizing that once you choose ownership and networking strategy, the correct pattern largely follows. 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*Q1yDOj5ZCvevpSjGBuXC9Q.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Build an AI Agent Evaluation with JEV</title>
		<link>https://towardsai.com/p/machine-learning/build-an-ai-agent-evaluation-with-jev</link>
		
		<dc:creator><![CDATA[Quan Huynh]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 09:27:13 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=54005</guid>

					<description><![CDATA[Author(s): Quan Huynh Originally published on Towards AI. Build an AI Agent Evaluation with JEV Build a small eval harness for a tool-using AI agent: code checks the work it did, and JEV judges the words it wrote. One run of my incident agent told me a checkout slowdown was caused by a config deploy that shrank the database pool from 50 connections to 5. It was right. The explanation was clear; it cited four tools, and it even ruled out a payment-provider warning that showed up later in the logs. Then I ran it with a shorter system prompt and got an answer that read almost the same. That one was wrong in two ways. It cited a tool it never called, and it never saw the warning it was supposed to rule out. If I had only read the paragraph, I would have shipped it. That is the problem with grading an agent by reading its answer. A good paragraph and a good investigation are two different things. This post builds a small harness that checks both. Plain Python checks the work. Jev, a fast structured evaluation model, judges the explanation. You can clone it and run it in a few minutes. Run it first, read about it later I think the fastest way to understand an eval harness is to watch it grade something. So let’s start there. You need Python 3.10 or newer, an OpenAI API key, and (for the judge step) a Cloudflare account. The code is in the devops-ai-guidelines repo: git clone https://github.com/VersusControl/devops-ai-guidelines.gitcd devops-ai-guidelines/07-evaluating-ai-agents/code/chapter-08python -m pip install -r requirements.txtcp .env.example .env Open .env and fill in OPENAI_API_KEY. Leave the Cloudflare fields empty for now. OPENAI_MODEL defaults to gpt-4.1-mini; I used gpt-5.4-mini. Now run the agent once: python run_agent.py Before you look at the output, here is what that command does. It takes about ten seconds, and nothing in it touches a real system. It loads a recorded incident and checks that the case hasn’t expired. It hands the agent two things: the alert text and four read-only tools (get_metrics, get_logs, get_deploys, get_db_status). Each tool returns a response recorded from the incident, not live data. The model picks one tool per turn. The runner calls it, writes down the call, and passes the result back. This repeats for up to five turns. When the model thinks it knows the cause, it calls submit_diagnosis with a paragraph plus a few structured fields. The script prints that. The answer key is in the same JSON file, but the agent never gets it. That matters later: it’s the only reason a grade means anything. Here is what one run printed for me on September 24, 2026: Scenario: checkout-latency-after-pool-changeAgent model: gpt-5.4-mini-2026-03-17Alert: checkout-service p95 latency &#62; 2sTool calls: get_metrics, get_deploys, get_db_status, get_logsRoot cause: A deploy at 14:02 changed DB_MAX_CONNECTIONS 50 -&#62; 5, which immediatelyreduced database pool capacity and caused checkout requests to queue and time out.Category: deployCause change: DB_MAX_CONNECTIONS 50 -&#62; 5Cause effect: pool_exhaustedCited evidence: get_metrics, get_logs, get_deploys, get_db_statusRejected signals: payment_provider_latency, checkout_image_v1_9_2, general_capacity_limitSteps: 5 Your run will not match this word for word. The tool data is frozen, but the model can pick a different tool order or different wording every time. That’s normal, and it’s exactly why we need a grader instead of eyeballs. What that output actually tells you It’s worth slowing down here, because every line in that output is either something the agent did or something the agent said. The whole harness is built on keeping those two apart. Read the figure from top to bottom: Alert is the input. The agent gets only this and four read-only tools. Tool calls are recorded by the runner, not reported by the agent. The agent can’t edit it after the fact. This is the most trustworthy line. Root cause is the agent’s own paragraph. It’s free text, so no == check can grade it. This is the line Jev reads. Category, Cause change, and Cause effect are short structured fields the agent must fill in. Code can compare them exactly with a hidden answer key. Cited evidence is a claim. The agent says it relied on these tools. The grader checks that claim against the Tool calls line. Rejected signals is also a claim: “I saw these and ruled them out.” The recording has a planted misleading signal (a payment-provider latency line that appears after the alert). The grader checks that the agent actually saw it and named it. Steps are counted by the runner. This case allows five: four tool calls and one answer. So in this run, the agent did the work: it called all four tools, including get_logs, so it really could have seen the payment line. The paragraph also sounds right. But &#34;sounds right&#34; is the part we can&#39;t check with code, and that is where Jev comes in. The incident behind the example The example is an incident agent for a checkout service. The alert says p95 latency crossed two seconds. The real cause is a config deploy one minute earlier that cut DB_MAX_CONNECTIONS from 50 to 5. The pool fills up, requests wait for a connection, and checkout times out. The order on that timeline is the whole puzzle. The deploy comes before the alert, so it can be the cause. The payment-provider line comes after, so it can’t be, even though “payment provider slow” sounds like a checkout problem. A good agent notices the order. A lucky one just picks the scariest line. Every tool response comes from a recorded JSON file, not from production. The same file holds a hidden answer key: the true cause, the evidence that proves it, the planted distraction, and the step budget. The runner never gives the answer key to the agent. It loads it only after the agent has committed to an answer. Incidents are just my example. The pattern works for any agent that uses tools and then explains itself: a support agent, a SQL agent, a code-review agent. Two checks, one [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*veN28NqypBqtN3M9OACt0w.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Confidence Comes From Experience: What XConf Changes About How We Measure LLM Confidence</title>
		<link>https://towardsai.com/p/machine-learning/confidence-comes-from-experience-what-xconf-changes-about-how-we-measure-llm-confidence</link>
		
		<dc:creator><![CDATA[luisacsfreitas]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 04:01:02 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/confidence-comes-from-experience-what-xconf-changes-about-how-we-measure-llm-confidence</guid>

					<description><![CDATA[Last Updated on September 25, 2026 by Editorial Team Author(s): luisacsfreitas Originally published on Towards AI. Confidence Comes From Experience: What XConf Changes About How We Measure LLM Confidence Anyone who has put an LLM in charge of a real decision knows the question that comes right after the demo: when do we trust it? Routing an email to the right team, approving a patch, answering a customer without review. In all of these we need a number that says “this one can go, this one goes to a person”. The trouble is that the number usually comes from the model itself, and the model is not a good judge of itself. On 15 September 2026, a team from the University of Cambridge and Google DeepMind published “Confidence Comes from Experience: Experiential Confidence Estimation from Reasoning to Agents” (Zhang, Zhu, Li, Chen, Kumaran and Collier). The method, called XConf, is simple to state and changes the starting point: confidence is not read from the current answer. It is read from the history of past answers. In this post I explain the idea, what the results actually show, how it compares with the rest of the confidence-estimation toolbox, and what it takes to use it in a real system, including the risks the paper does not cover. TL;DR The usual methods (verbalized confidence, token probabilities, self-consistency) only look at the current answer. When a model is wrong the same way every time, all of them say “confident”. XConf keeps a bank of past, graded episodes and asks: on similar tasks, when the model was as sure as it is now, how often was it right? With a single generation, it matches or beats ten-sample self-consistency in 23 of 24 comparisons, with much lower calibration error. It needs no logit access, trains nothing, and works the same for multiple choice, code and agents. The one condition everything rests on: the right/wrong labels must come from outside the model. With labels produced by the model itself, the method gets worse. 1. The problem: confidence only reads the moment There are three families of methods for putting a confidence number on a black-box LLM: Verbalized confidence. Ask the model: “from 0 to 1, how sure are you?”. Cheap and works on any task, but models are systematically overconfident and sensitive to how the question is phrased. Token probabilities (logprobs, P(True)). The probability the model assigned to its own answer. It requires logit access, which most frontier APIs do not give, and it measures uncertainty about the next token rather than about whether the claim is true. Self-consistency. Ask several times with temperature and see whether the answer changes. It was the strongest black-box method available, but it costs N generations per request and does not map cleanly onto code or agent trajectories. All three have one thing in common: they only look at what the model is doing right now. And they share a blind spot. If the model has a stable misconception (it reads “stop paying” and always thinks payments, when in your company that is a cancellation), it gives the same answer every time, with the same certainty and high probabilities. All three methods report “confident” on an error. Legenda: Figure 1. Left: the usual methods only read the current answer. Right: XConf reads the history of similar episodes. 2. The idea: confidence as an observed frequency The paper draws on decades of research on human metacognition. We do not judge our confidence only by re-inspecting the reasoning we just did. We also remember how similar situations turned out. A student who has solved a hundred determinants trusts the result without re-checking. The same student, facing a hard inequality, writes the answer already expecting it to be wrong, because they remember how often such proofs collapsed on the last line. XConf formalises this. Instead of asking the model what it feels, it asks the record what happened. 3. How it works Figure 2. Two readings of the same record: Recall (statistical) and Reflect (verbal). The experience bank. Every time the model solves a task, an episode is stored with five fields: the task; a short reflection by the model on its own solution, written before the outcome is known; the confidence the model stated; the graded outcome (right or wrong), once it arrives; a lesson, written by the model after it learns the outcome. The lesson is quarantined: it is never shown to the model while it assesses a solution that has not been graded yet. The authors are explicit about why: knowing the outcome biases self-judgement in ways that instructions alone do not fix. Recall: a confidence-conditioned hit rate. For a new task, XConf retrieves the most similar episodes from the bank. The important detail is that the search key has two parts: the task embedding and the stated confidence. It does not look for “similar tasks”, it looks for “similar tasks where the model felt equally sure”. It takes the 50 nearest neighbours and computes the fraction in which the model was right. The paper shows this conditioning is not decoration: removing stated confidence from the key costs 0.08 AUROC on reasoning and 0.12 on agents. There is one more subtle detail: similarity is not raw embedding cosine. It is measured in a space rescaled using the bank’s own graded outcomes, so that “similar” means “fails for the same reasons” rather than just “is about the same topic”. Reflect: the model reads its own track record. The retrieved neighbours are shown to the model as short cards (task, stated confidence, outcome, lesson). The model first has to name the recurring failure mode it sees, and only then restates a confidence. It is a short call that does not re-solve the task. Combine. The final confidence is the plain average of the two readings: ½ × (Recall + Reflect). Two properties make this practical. When the bank is sparse around a task, the neighbours are only weakly similar and Recall [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*06oOVs9dtqs-LBqXChcSvQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Qwen-Image-2.1 Is the Best Local Image Model in 2026. The Download Is 33 GB.</title>
		<link>https://towardsai.com/p/machine-learning/qwen-image-2-1-is-the-best-local-image-model-in-2026-the-download-is-33-gb</link>
		
		<dc:creator><![CDATA[Ankit Agrawal]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 03:31: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.com/p/artificial-intelligence/qwen-image-2-1-is-the-best-local-image-model-in-2026-the-download-is-33-gb</guid>

					<description><![CDATA[Last Updated on September 25, 2026 by Editorial Team Author(s): Ankit Agrawal Originally published on Towards AI. Qwen-Image-2.1 tops both blind image arenas among downloadable models. Here is the VRAM, the speed on a 4090, and the licence. Qwen-Image-2.1 is 7 billion parameters. The download is 33 gigabytes. It runs in 15 GB of VRAM. The parameter count, the download, and what actually sits on your card are three different numbersThe article explains how to reconcile Qwen-Image-2.1’s seemingly conflicting specs—7B parameters, a 33GB download, and ~15GB VRAM at runtime—by focusing on how the “reader” (Qwen3-VL-8B) is offloaded and runs only once per prompt while the image “drawer” stays on the GPU for iterative denoising. It evaluates real-world behavior by testing text rendering (often close but prompt-sensitive), comparing leaderboard scores and licensing constraints, and demonstrating transparent PNG/RGBA output where alpha is good but soft shadows have color fringing unless you regenerate without shadows and composite later. The piece then dives into practical deployment: which quantization formats work at different VRAM tiers, the crucial performance switches (especially Cache-DiT), example pipeline code, expected runtimes at 1024px vs 2048px, and why community distillations and ecosystem tooling rapidly filled gaps after release. It concludes with what remains unmeasured (quality tradeoffs of compressing the reader, distilled builds’ true impact, broader hardware timings) and guidance on what to run based on your GPU size and the non-commercial Research License versus Apache-licensed alternatives for commercial use. 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*pQ4TQecrUL-3P47jZgkZOA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Jev Doesn’t Write, It Decides: Games Today, Company Data with Care, Computer Vision Next</title>
		<link>https://towardsai.com/p/machine-learning/jev-doesnt-write-it-decides-games-today-company-data-with-care-computer-vision-next</link>
		
		<dc:creator><![CDATA[luisacsfreitas]]></dc:creator>
		<pubDate>Fri, 25 Sep 2026 03:01:02 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/jev-doesnt-write-it-decides-games-today-company-data-with-care-computer-vision-next</guid>

					<description><![CDATA[Last Updated on September 25, 2026 by Editorial Team Author(s): luisacsfreitas Originally published on Towards AI. Jev Doesn’t Write, It Decides: Games Today, Company Data with Care, Computer Vision Next Most of what we build with LLMs is not writing. It is deciding. Which team gets this email. Is this message spam. Which move should the bot make. Is this action allowed. We use a text generator for these decisions because it is the tool we have, and then we spend time parsing its prose, fixing its JSON and wondering whether its “90% sure” means anything. In September 2026, TypeSafe released Jev, a model built for exactly that gap. It does not generate text at all. You give it a state and a set of typed questions, and it returns answers with probabilities, in one parallel pass, in a fraction of a second. I have spent the last weeks looking at where a model like this fits in real systems. My conclusion so far has three parts, and they are the structure of this post: Games are its natural home today. Bounded choices, code that owns the rules, tight latency and no sensitive data. Company data needs care. Jev is API-only and closed. That is not a deal-breaker, but it changes what you can send it. Computer vision is where it gets interesting. Vision models have been “System One” for a decade. Jev brings the same idea to language, and the two fit together naturally. 1. What Jev is, in one picture Figure 1. A generative LLM writes its answer token by token. Jev reads the state once and returns typed decisions with probabilities. The public facts, from TypeSafe’s documentation and early coverage: Input: a state (a string, a JSON object or a list of text values) and a set of questions. Three question types: choice (pick one option from a list), score (a value on a scale) and noul (yes/no). Output: for each question, the answer and a probability distribution. No text, no rationale. How it runs: the state is read once and every question is evaluated against it in parallel. There is no token-by-token decoding, which is why calls take roughly 70–500 ms. Limits: text only (no images, audio or video), up to 64k tokens per request. Price: about $0.04 per million input tokens; output tokens are free. Training: a post-training method TypeSafe calls RLCD (Reinforcement Learning for Calibrated Decisions), aimed at making the probabilities mean what they say. The recipe is not public. On TypeSafe’s own four-workflow evaluation, Jev scored about the same accuracy as GPT-5.6 Terra (67.8% vs 67.9%) at roughly 1/75 of the cost per case and about 25 times faster, while larger reasoning models scored higher. Those numbers are the vendor’s. The most useful independent look I found (an analysis on archerhume.com) supports the core claim that probabilities are read out directly, measured a calibration error of about 0.03 on 1,200 MMLU items, and also found two things worth remembering: calibration was weaker on harder, freshly generated problems, and the same option’s probability moved between 0.84 and 0.96 depending on where it sat in the option list. So: fast, cheap, typed and reasonably calibrated, with no explanation of why. 2. Why games are its natural home A game is almost the ideal environment for a model like this: The choices are bounded. The engine knows the legal moves, the NPCs in the room and the actions each one can take. Code owns the rules. The model picks; the engine validates and executes. A bad pick costs a strange NPC reaction, not a lost customer. Latency matters. A decision loop runs every few seconds or every frame. Ten seconds for a reasoning model is unplayable; 200 ms is fine. The data is not sensitive. Game state is yours, synthetic and public. Nothing personal leaves your perimeter. Figure 2. The game loop with Jev as the decision step, and a concrete example: working out which NPC the player is talking to. An easy example. A player with a microphone says: “hey, you with the sword, how much for a room?”. The speech-to-text transcript and the NPCs in range go into the state, and Jev gets one yes/no question per NPC: is the player talking to this character? It comes back with innkeeper 0.81, guard 0.12, bard 0.03. The guard is the one carrying a sword, but the request is for a room, and Jev weighs both. The code decides what happens next: above 0.6 the innkeeper answers, below it the NPC asks “talking to me?”. This is not hypothetical. A community benchmark (jev-benchmark, on jev-1.13.0) tested exactly this task on 79 hand-labelled utterances designed to be tricky, and reported an F1 of 0.96 with precision 1.0, against 0.82 for a fuzzy name-matching heuristic, and 0.93 when names were phonetically misspelled. The same repository used Jev as a chess engine: about 37% best-move accuracy, an estimated ~950 Elo and a median of 166 ms per move, provided the code first computes the facts about the position (Jev does not calculate ahead). Another project, WorldKit, packages the pattern as an NPC runtime: the engine enforces the rules and Jev only ever sees the actions that are currently valid. What about game engines? Jev is an HTTP API with official Python and JavaScript SDKs, so any engine can call it. The most complete integration I found is jev-unreal-statetree, a C++ plugin (public alpha) that adds a “Jev Decision” task to Unreal Engine 5.8’s StateTree. It sends one request when a state is entered, not every frame, and tags each request with a world “revision” number so that answers arriving after the game state has changed are simply discarded. For Unity, Godot or browser engines like Three.js the pattern is the same over HTTP. One rule applies everywhere: never ship the API key inside the game build; put a small server or gateway between the game and Jev. The samples are small, and these are community projects, not peer-reviewed [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*hxGvnNAuv7gxvcY2juJp2g.png" medium="image"></media:content>
            	</item>
	</channel>
</rss>
