<?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>Mon, 02 Nov 2026 10:31:19 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.11</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>Navigating the Invisible Hazard: How Deep Recurrent Reinforcement Learning and POMDPs Automate Orbital Collision Avoidance Under Sensor Uncertainty</title>
		<link>https://towardsai.com/p/machine-learning/navigating-the-invisible-hazard-how-deep-recurrent-reinforcement-learning-and-pomdps-automate-orbital-collision-avoidance-under-sensor-uncertainty</link>
		
		<dc:creator><![CDATA[Aarush Mahajan]]></dc:creator>
		<pubDate>Mon, 02 Nov 2026 14:42:05 +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=55255</guid>

					<description><![CDATA[Author(s): Aarush Mahajan Originally published on Towards AI. Navigating the Invisible Hazard: How Deep Recurrent Reinforcement Learning and POMDPs Automate Orbital Collision Avoidance Under Sensor Uncertainty An autonomous satellite executing a real-time thruster burn in Low Earth Orbit to navigate space debris Author: Aarush Mahajan Primary Source: Spacecraft Autonomous Decision-Planning for Collision Avoidance: a Reinforcement Learning Approach (Bourriez, Loizeau, &#38; Abdin, 2023) [1] Thesis Question: Where do traditional Markov Decision Processes (MDPs) fail in space domain awareness, and how does a Partially Observable Markov Decision Process (POMDP) paired with Deep Recurrent Q-Networks (DRQN) enable autonomous satellite collision avoidance under severe tracking noise?[1], [7] Section 1: Roadmap &#38; Real-World Stakes 1.1 The Invisible Emergency Above Our Heads Every second, the orbital infrastructure that powers modern civilization — GPS navigation, financial transaction synchronization, climate monitoring, and emergency disaster response — hangs in a delicate balance 2,000 kilometers above Earth[8]. Low Earth Orbit (LEO) is currently experiencing an unprecedented population explosion. Ground-based tracking networks actively monitor over 35,000 resident space objects larger than 10 centimeters[8]. Alongside these trackable objects float an estimated 900,000 lethal fragments between 1 cm and 10 cm — objects far too small for radar networks to track consistently, yet carrying enough kinetic energy at hyper-velocities (7.8 km/s or ~17,500 mph) to obliterate an active satellite upon impact.[8] +----------------------------------------------------------------------------------+&#x007C; THE ORBITAL DEBRIS SPECTRUM &#x007C;+----------------------------------------------------------------------------------+&#x007C; Size Class &#x007C; Estimated Count &#x007C; Tracking Status &#x007C; Risk Level &#x007C;+----------------+-----------------+----------------------+------------------------+&#x007C; &#62; 10 cm &#x007C; ~35,000+ &#x007C; Tracked by SSN / USSF&#x007C; Catastrophic impact &#x007C;&#x007C; 1 cm - 10 cm &#x007C; ~900,000 &#x007C; Hard to track &#x007C; Lethal disruption &#x007C;&#x007C; 1 mm - 1 cm &#x007C; ~128 Million &#x007C; Untracked &#x007C; Shielding required &#x007C;+----------------+-----------------+----------------------+------------------------+ When hyper-velocity objects collide, they trigger a runaway chain reaction known as Kessler Syndrome: each collision fragments satellites into thousands of new high-speed projectiles, increasing the probability of subsequent collisions until entire orbital bands become unusable[8]. 1.2 The Operational Bottleneck: Why Manual Operations Are Failing To prevent catastrophic conjunctions, global bodies like the U.S. Space Surveillance Network (SSN) continuously screen orbits and issue Conjunction Data Messages (CDMs)[6]. A single satellite operator in LEO receives hundreds of CDMs per week, detailing close approaches with uncertain miss distances and collision probabilities[1], [6]. Currently, collision risk mitigation relies on human-in-the-loop workflows[1], [6]: Ground radar networks detect a potential close-approach event (conjunction). Operators receive automated CDMs 1 to 7 days before the Time of Closest Approach (TCA). Specialized orbital analysts manually evaluate the CDM covariance matrices, run trajectory propagation models, calculate thruster burns, and upload command sequences to the spacecraft[1], [2]. [Ground Radar Tracking] ---&#62; [CDM Generation] ---&#62; [Human Analyst Review (Hours/Days)] ---&#62; [Uplink Maneuver Command] &#x007C; Operational Bottleneck! (Cannot scale to mega-constellations) With commercial mega-constellations deploying tens of thousands of new satellites, manual analysis is reaching an unsustainable tipping point. Mega-constellation operators like SpaceX’s Starlink execute thousands of Collision Avoidance Maneuvers (CAMs) annually. If every satellite requires manual human oversight for every close approach, satellite operations will stall, response latency will spike, and human error under stress will lead to orbital impacts. To protect humanity’s shared orbital environment, we must transition from manual ground-based control to on-board autonomous decision-making[1]. Takeaway — Section 1: Over 35,000 tracked space objects and 900,000 untracked lethal fragments threaten LEO infrastructure[8]. Traditional human-in-the-loop collision avoidance cannot scale to the era of satellite mega-constellations, demanding on-board AI systems capable of autonomous decision-making[1], [6]. Section 2: The Core Bottleneck — Why Standard Markov Decision Processes (MDPs) Fail in Space 2.1 The Fully Observable Illusion of Standard Reinforcement Learning When Reinforcement Learning (RL) is applied to terrestrial robotics or games, researchers typically model the problem as a Markov Decision Process (MDP)[7]. In a standard MDP, the system assumes full state observability: at any time step t, the autonomous agent knows its exact state in state space S such as its precise 3D position, velocity, and orientation. Under a fully observable MDP, an RL policy π(s) maps the exact environment state directly to an optimal control action in action space A. If space traffic management were a true MDP, a satellite’s flight computer could observe the exact positions and velocity vectors of all surrounding space debris and execute a single, deterministic thruster burn to dodge the collision. +-----------------------------------------------------------------------------------+&#x007C; FULL OBSERVABILITY ILLUSION (MDP) &#x007C;+-----------------------------------------------------------------------------------+&#x007C; True State (s_t) ---&#62; Agent Directly Observes (s_t) ---&#62; Optimal Action (a_t) &#x007C;&#x007C; (Exact Debris Pos) (Zero Tracking Error) (Single Evasive Burn)&#x007C;+-----------------------------------------------------------------------------------+ In Low Earth Orbit (LEO), however, true state observability is impossible[1], [7]. 2.2 Dual Layers of Orbital Uncertainty: Aleatory vs. Epistemic Space Situational Awareness (SSA) data is corrupted by two distinct, compounded layers of uncertainty[1], [4]: Aleatory Uncertainty (Sensor &#38; Measurement Noise): Ground-based radar arrays, optical tracking telescopes, and on-board satellite sensors suffer from physical measurement noise and timing jitter. A radar return does not yield an exact point in space; it yields a probabilistic cloud of potential locations[4]. Epistemic Uncertainty (Model &#38; Propagation Imperfections): To project where a piece of debris will be 24 to 48 hours in the future, engineers rely on mathematical orbit propagators like the Simplified General Perturbations 4 (SGP4) model[1], [3]. However, SGP4 uses mathematical approximations for complex physical phenomena — such as Earth’s asymmetric gravitational field (J₂ oblateness harmonics), upper atmospheric drag fluctuations caused by solar activity, and solar radiation pressure. Over time, these unmodeled physical forces cause positional uncertainty ellipsoids to expand nonlinearly[2]. +-----------------------------------------------------------------------------------+&#x007C; REAL-WORLD ORBITAL UNCERTAINTY &#x007C;+-----------------------------------------------------------------------------------+&#x007C; True State (s_t) + [Aleatory Noise (Radar Jitter)] &#x007C;&#x007C; + [Epistemic Noise (SGP4 Drag/J2 Errors)] &#x007C;&#x007C; &#x007C; &#x007C;&#x007C; v &#x007C;&#x007C; Noisy Observation (o_t) RECEIVED &#x007C;+-----------------------------------------------------------------------------------+ Both aleatory and epistemic uncertainties are characterized statistically using Gaussian distribution models[1], [4]. Because of this noise, a satellite never knows the true state ; it only receives a noisy, corrupted observation in observation space O. 2.3 The Fog Analogy: Why Naive MDP Agents Crash in LEO To understand why standard RL algorithms fail in space, consider a plain-English analogy: The Highway Fog Analogy: Imagine driving a high-performance sports car down a highway at 17,500 miles per [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*rSgThGib9Ikgv60dqLjbrA.png" medium="image"></media:content>
            	</item>
		<item>
		<title>What Is the Best GPU to Rent for LLMs in 2026? (RTX 5090 to H100)</title>
		<link>https://towardsai.com/p/machine-learning/what-is-the-best-gpu-to-rent-for-llms-in-2026-rtx-5090-to-h100</link>
		
		<dc:creator><![CDATA[Anubhav]]></dc:creator>
		<pubDate>Mon, 02 Nov 2026 14:42:02 +0000</pubDate>
				<category><![CDATA[Data Science]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=55257</guid>

					<description><![CDATA[Author(s): Anubhav Originally published on Towards AI. RTX 5090s rent for under $1 an hour while H100s cost nearly 50% more than in December. Which card fits which open model, RunPod vs Vast.ai vs Lambda, and when the API is still cheaper GPU rental sites list dozens of cards, from old gaming cards to NVIDIA’s newest datacenter ones, and the top of the list costs many times more an hour than the bottom. The prices make it look like you get what you pay for. After the price sticker shock of renting GPUs, the article explains how to choose hardware based on model size and memory needs (typically running open models in 4-bit) and then walks through practical recommendations by card category: gaming GPUs (where 3090/5090 are strong value for smaller models and coding agents), workstation cards (good capacity but mixed value, with Pro 6000s notable for single-card performance), and datacenter cards (A100/H200/H100/B200/B300/MI300X for larger models, multi-GPU scaling, and cases where fast interconnects matter). It compares where to rent—marketplaces, GPU clouds, big cloud providers, and pay-per-second services—highlighting tradeoffs in cost, setup, and reliability. The piece also covers downtime risks and “why your cheap lease isn’t always safe,” then provides decision rules for when renting beats an API (especially for batch jobs and fine-tuning) versus when an API is cheaper (often for interactive single-user coding where GPUs sit idle waiting). It closes with a suggested starting approach: rent small first, test real workloads, measure startup/download/queue effects, and keep renting or buy depending on expected usage. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*YR-MWDeKRZNDzKHe12rV_A.png" medium="image"></media:content>
            	</item>
		<item>
		<title>The Elephant-Goldfish Model: Why the AI That Knows Least Reviews Best</title>
		<link>https://towardsai.com/p/machine-learning/the-elephant-goldfish-model-why-the-ai-that-knows-least-reviews-best</link>
		
		<dc:creator><![CDATA[Udaykiran Estari]]></dc:creator>
		<pubDate>Mon, 02 Nov 2026 14:41:48 +0000</pubDate>
				<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/?p=55259</guid>

					<description><![CDATA[Author(s): Udaykiran Estari Originally published on Towards AI. What Google’s open-source EGM plugin is, how its fresh-context reviewers check a design before any code exists, and why that differs from asking the same chat to check its own work. When I opened Google’s elephant-goldfish-model repository, the first line under the logo was a tagline: &#34;Design with an elephant. Review with a goldfish.&#34; I had seen plenty of AI coding tools, but none that started by telling the AI to forget things on purpose. After the introduction, the article explains what the Elephant-Goldfish Model (EGM) is at a conceptual level—an approach to spec-driven development where one long “elephant” session drafts a design and separate, fresh-context “goldfish” reviewer sessions read only that draft (and a rubric) before any code exists. It breaks down EGM’s roles and architecture into layers (skills/commands, stateless reviewer personas, document standards, and versioned “living documentation”), then walks through how the workflow runs in phases: brainstorm, draft, structured multi-stage review with prioritization and re-review, resolve/approve in an edit-and-signoff loop, and finally implement followed by drift reporting when code diverges from the spec. A concrete webhook-delivery example shows how the elephant’s context can miss gaps that reviewers catch when they start from a clean slate. The piece also contrasts EGM against common prompting patterns (direct coding, self-review in the same context, one generic “review this,” or stale docs) and ends with practical limits such as extra cost/latency, requirements for subagent-capable harnesses, and the fact that it doesn’t replace testing or human judgment. Read the full blog for free on Medium. Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor. Published via Towards AI]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:1000/1*PNkZJ8sZYm2MuIFvgYItrQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>My Model Thought Tamil Was Telugu: Open-Source Language ID for Hinglish, Tanglish and Kanglish</title>
		<link>https://towardsai.com/p/machine-learning/my-model-thought-tamil-was-telugu-open-source-language-id-for-hinglish-tanglish-and-kanglish</link>
		
		<dc:creator><![CDATA[Latent AI Labs]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 10:11: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/artificial-intelligence/my-model-thought-tamil-was-telugu-open-source-language-id-for-hinglish-tanglish-and-kanglish</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): Latent AI Labs Originally published on Towards AI. My Model Thought Tamil Was Telugu: Open-Source Language ID for Hinglish, Tanglish and Kanglish By Arun Prabhakaran · @LatentAILabs The article introduces Bhasha, an open-source word-level language identification model for code-mixed Indian text (including Hinglish and other romanized/native-script mixes). It explains why message-level language ID is insufficient when you need per-word language tags for tasks like transliteration, tokenization, translation modeling, measuring code-mixing, and filtering corpora. The author describes how Bhasha was built from 1.65M code-mixed sentences generated programmatically from public text, and how the model outputs both word-level labels and message-level summaries (main language, script type, and language shares). Results from various evaluation sets show strong performance overall, but a surprising weakness for Tamil: on human-labelled data, many Tamil words are incorrectly tagged as Telugu, a failure attributed to differences between written/news Tamil (which dominated training) and spoken forms common in comments. A “language-pair hint” (the langs option) helps, and Bhasha v2 improves Tamil substantially by adding more real, word-labelled YouTube comment data. The post closes with guidance on where Bhasha works best, key lessons from the Tamil error analysis, and release details plus links to try Bhasha and related 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*E-NQ0RuMr8tZpnuo9eO38g.png" medium="image"></media:content>
            	</item>
		<item>
		<title>The Worst Ways to Use AI Are the Ones That Feel Productive</title>
		<link>https://towardsai.com/p/machine-learning/the-worst-ways-to-use-ai-are-the-ones-that-feel-productive</link>
		
		<dc:creator><![CDATA[Hayanan]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 04:01:02 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/the-worst-ways-to-use-ai-are-the-ones-that-feel-productive</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): Hayanan Originally published on Towards AI. Nine ordinary AI habits that quietly waste time, weaken judgment, and create technical problems, and how to replace them with workflows you can actually trust. The moth is still there, under a piece of aging tape. Someone found it caught in a relay of the Harvard Mark II computer, pulled it out, and fixed it to a page in the maintenance log. There was a physical cause. A physical place to look. You could point to the broken thing. Cover image: The original computer “bug,” a real moth taped into a Harvard Mark II maintenance log in 1947. Source: U.S. Naval Historical Center / Naval Surface Warfare Center, via Wikimedia Commons. Public domain.The article argues that many everyday AI failures don’t look like obvious “hallucinations”—they look like plausible, polished output that prevents people from noticing wrong assumptions and missing evidence. It outlines nine common traps to avoid: optimizing based on output volume rather than completed, accepted work; treating prompts as if they guarantee certainty instead of requiring evidence; giving vague tasks that lead to precise-but-wrong changes; outsourcing thinking to confident prose; building multi-agent or autonomous systems when a simple function or clear specification would suffice; confusing retrieved text with trusted instructions (prompt-injection and data boundaries matter); granting too much automation without human checkpoints; trusting beautiful benchmark/test results instead of evaluating real failure modes and regression cases; and spending more effort rewriting prompts than fixing the underlying problem (like missing data). The takeaway is to make AI earn trust per task by measuring time to accepted results, verifying with sources and review, and tracking what actually gets finished correctly and at what cost. 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:2600/0*0L2NN9-CqhBOK9CD.jpg" medium="image"></media:content>
            	</item>
		<item>
		<title>[Day 37/100] Build Your Own Agent Memory Layer with Postgres and pgvector</title>
		<link>https://towardsai.com/p/machine-learning/day-37-100-build-your-own-agent-memory-layer-with-postgres-and-pgvector</link>
		
		<dc:creator><![CDATA[Montasir Mahmud]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 02:01:01 +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/day-37-100-build-your-own-agent-memory-layer-with-postgres-and-pgvector</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): Montasir Mahmud Originally published on Towards AI. Mem0 made four decisions for you. Here is how to own every one of them with one SQL table, one Python class, and an update policy you can read. Suppose Priya, the user who has been following us through this whole memory phase, tells your agent: “Heads up, I started eating fish again.” Yesterday, Mem0 handled that sentence for you. A model read it next to her old “is vegetarian” memory, decided the two conflicted, and rewrote the memory. The new fact is searchable. The old one survives only in an audit table that your agent’s search never touches. AI Generated ImageThe rest of the article walks through rebuilding Mem0’s memory layer yourself on Postgres using pgvector: it explains why a dedicated memory schema and a PgMemory class are useful, shows how to run pgvector locally, designs the memories table (including embedding, importance, and a superseded_by link for history), and implements nearest-neighbor recall plus access tracking. It also covers the tricky behavior of approximate vector indexes with SQL filtering (including pgvector’s iterative scan setting), proposes a readable write/update policy that uses similarity thresholds and a model only for ambiguous cases (supersede rather than delete), and demonstrates integrating the memory layer into a LangGraph agent via an extraction step plus hot-path recall. Finally, it compares hand-rolled tables with LangGraph’s PostgresStore, lists key takeaways, and gives homework to validate schema behavior, threshold effects, and query plans. 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*-Doos2nmUT3FPZ-Qxbk3Hw.png" medium="image"></media:content>
            	</item>
		<item>
		<title>A School Form Took Me 30 Minutes. “Just Use AI” Missed 4 in 10 Blanks.</title>
		<link>https://towardsai.com/p/machine-learning/a-school-form-took-me-30-minutes-just-use-ai-missed-4-in-10-blanks</link>
		
		<dc:creator><![CDATA[Paul Weng]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 01:31:01 +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/a-school-form-took-me-30-minutes-just-use-ai-missed-4-in-10-blanks</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): Paul Weng Originally published on Towards AI. I built an app to fill school forms for my kids. On forms it had never seen, the vision model alone found 62% of the blanks. Put a cheap detector in front of the same model and it found 97%. Here’s how I built it, and how I tested it. Note: I used AI tools for this article. I built the app with Claude Code, and an AI assistant ran the tests on my laptop and helped me shape the draft. The app, the numbers and the screenshots are from real runs. The author explains why “just give it to ChatGPT” doesn’t work for form filling: completing a form is two tasks—identifying what each blank is and locating exactly where it is. They describe building PaperKit to split these responsibilities: a cheap detector proposes candidate boxes (over-including to avoid missing fields) and a vision/LLM model judges each candidate, labeling it with field type and ownership, while the phone performs the actual filling. They report an experimental comparison between a model-alone approach and the detector-plus-model pipeline across tuned and held-out pages, showing the model-alone setup performs poorly at checkbox detection and box placement, while their pipeline achieves much higher accuracy (notably 97% for blanks with the detector front-end). They also discuss edge failures (misaligned boxes, skipped sections, drift on unseen layouts, and ambiguity on two-parent forms), then detail a real run on a Florida childcare form, speed and cost breakdowns, and their “what I’d do now” checklist plus remaining uncertainties (small tuning set, only one grounding model tested properly, and the need for further evaluation). 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*-zZ_qXimWVhOvuftVP6R_w.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Tracing AI Agents: What OTel’s GenAI Spans Actually Capture</title>
		<link>https://towardsai.com/p/machine-learning/tracing-ai-agents-what-otels-genai-spans-actually-capture</link>
		
		<dc:creator><![CDATA[M. Haseeb Hassan]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 01:01:02 +0000</pubDate>
				<category><![CDATA[Artificial Intelligence]]></category>
		<category><![CDATA[Latest]]></category>
		<category><![CDATA[Machine Learning]]></category>
		<category><![CDATA[Towards AI - Medium]]></category>
		<guid isPermaLink="false">https://towardsai.com/p/artificial-intelligence/tracing-ai-agents-what-otels-genai-spans-actually-capture</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): M. Haseeb Hassan Originally published on Towards AI. Tracing AI Agents: What OTel’s GenAI Spans Actually Capture On June 12, 2026, OpenTelemetry shipped semantic conventions release v1.42.0, and quietly pulled every gen_ai.* attribute, span, metric, and event out of its core repository [1]. If you had dashboards or alerting rules built against the old spec pages, they now redirect to a notice that reads &#34;this page has moved and is no longer maintained&#34; [1]. The conventions didn&#39;t disappear. They moved to a dedicated repository, semantic-conventions-genai, so the GenAI working group can ship faster than the rest of OpenTelemetry&#39;s release cycle allows [2]. OpenTelemetry’s GenAI semantic conventions moved into their own faster-moving repository in June 2026. That move matters more than a changelog entry usually would, because these conventions are the only vendor-neutral vocabulary for describing what an LLM call, a tool execution, or an agent run actually did on the wire. Here’s what’s in that vocabulary right now, what changed, and what’s worth building against before the next spec revision moves the furniture again. In this article: Why your agent traces just got a new home What a span tree for an agent run actually looks like The attributes that carry the real signal None of this is stable yet, and that changes how you should treat it What to adopt now, and what to pin against the churn Why your agent traces just got a new home OpenTelemetry’s semantic conventions are the part of the project that defines shared vocabulary: agreed-upon attribute names so that a trace produced by one instrumentation library means the same thing in any backend that reads it. The GenAI conventions are the subset that covers model calls, embeddings, retrieval, tool execution, and agent orchestration. Until this spring, that vocabulary lived inside the same repository as HTTP, database, and messaging conventions, and shipped on the same release cadence. The GenAI working group outgrew that cadence. Providers keep adding new request parameters, new token-accounting categories (cached tokens, reasoning tokens, per-modality tokens), and new span types for agents and workflows faster than a shared quarterly-ish release train could absorb them cleanly. The v1.42.0 release notes say as much directly: the gen_ai.* definitions under model/gen-ai/, model/openai/, and model/mcp/ were deprecated in the core repo and moved to semantic-conventions-genai [2]. Notably, the MCP-specific conventions moved with them, which means tool-call spans for MCP servers now share the exact same attribute vocabulary as everything else under gen_ai.*, rather than living as a separate side convention. That&#39;s worth knowing if you&#39;re designing MCP tools that Claude or another agent will actually call correctly, since the same spans that trace a bad tool call also trace the model call that chose it. The new repository had no tagged release as of this writing, and ships straight from its main branch against a schema labeled gen-ai/1.42.0 [3]. If you&#39;re pinning an instrumentation library today, pin it by commit or by the exported schema URL it emits, not by a spec version number you&#39;d expect from the old repo&#39;s release pattern. What a span tree for an agent run actually looks like A single agent turn doesn’t produce one span. It produces a tree, and the GenAI conventions now describe each layer of it. At the top sits an invoke_agent span, which comes in two flavors: a CLIENT-kind span when one agent calls another across a process boundary, and an INTERNAL-kind span for an agent&#39;s own internal reasoning loop [4]. Both are named invoke_agent {gen_ai.agent.name} when the agent has a name, or just invoke_agent when it doesn&#39;t. Underneath that, every model call gets its own span, named {gen_ai.operation.name} {gen_ai.request.model} (so a real span name looks like chat gpt-4 or chat claude-opus-5-5) [5]. Underneath that, each tool call the model triggers gets an execute_tool span of its own, carrying attributes like the tool&#39;s name and a call ID so you can match it back to the specific tool-use block that requested it [6]. Stack enough of these and you get a tree that reads, top to bottom, as: the agent was invoked, it made a model call, the model asked for a tool, the tool ran, and the result fed back into the next model call. That&#39;s the shape that makes it possible to answer &#34;why did this agent run cost four model calls instead of one,&#34; which is the exact question that tends to blow up agent-loop budgets in production. A single agent turn as a span tree: one invoke_agent span containing two model calls and a tool call in between. The attributes that carry the real signal Two attributes are required on nearly every GenAI span: gen_ai.operation.name (values like chat, embeddings, execute_tool, invoke_agent) and gen_ai.provider.name (openai, anthropic, and so on) [5]. That second one is itself a renamed field. The older gen_ai.system attribute is gone in the current spec, replaced by gen_ai.provider.name, and the old gen_ai.usage.prompt_tokens and gen_ai.usage.completion_tokens fields were replaced by gen_ai.usage.input_tokens and gen_ai.usage.output_tokens [5]. If your dashboards still query the old names, they&#39;re silently reading nothing from any instrumentation library that&#39;s updated to the current spec. Beyond the required pair, most of what you’d actually want to query is “Recommended” rather than required: token counts, gen_ai.response.finish_reasons, gen_ai.conversation.id, and a growing list of per-modality usage fields for audio, image, and cached tokens [5]. None of that is captured by default, and deliberately so. The actual prompt and response text live behind gen_ai.input.messages and gen_ai.output.messages, both marked Opt-In, specifically because they can carry personal data that you don&#39;t want landing in a trace backend without a conscious decision to put it there [5][6]. That opt-in boundary is the same tension that shows up anywhere you&#39;re deciding how much raw context to surface for debugging versus how much context an agent should actually be carrying around in the first place: more captured content makes a trace more useful for debugging and more expensive and riskier to store. Four attribute changes worth checking your [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*68LFykHUExmFFV1jVodVow.png" medium="image"></media:content>
            	</item>
		<item>
		<title>[Day 36/100] Mem0 in Practice: Long-Term Memory That Decides What Your Agent Forgets</title>
		<link>https://towardsai.com/p/machine-learning/day-36-100-mem0-in-practice-long-term-memory-that-decides-what-your-agent-forgets</link>
		
		<dc:creator><![CDATA[Montasir Mahmud]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 01:01:01 +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/day-36-100-mem0-in-practice-long-term-memory-that-decides-what-your-agent-forgets</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): Montasir Mahmud Originally published on Towards AI. A hands-on guide to Mem0’s add and search API, the model-driven ADD/UPDATE/DELETE step behind it, and wiring it into a LangGraph agent without losing track of what it changed Suppose Priya tells your agent in March that she is vegetarian, and in October that she has started eating fish again. Both sentences end up in your vector store as memories, and Day 35, the post on embeddings, showed why that is a problem: “is vegetarian” and “now eats fish” land almost on top of each other in embedding space. Similarity search finds both. It cannot tell you that the second one cancels the first. AI Generated ImageAfter the lead, the article explains how Mem0 resolves the negation/contradiction problem by packaging a memory pipeline around its add and search APIs: it extracts candidate facts from new user messages, embeds and compares them against existing memories, then uses a second model call to decide whether to ADD, UPDATE, DELETE, or do nothing for each fact. It highlights that the decision is prompt-driven (not deterministic), so updates may vary, and emphasizes the need for an audit trail (via Mem0’s history) to debug why an agent made a particular memory change. The post then shows how to wire Mem0 into a LangGraph agent by retrieving on the last human message (not tool messages) and writing only the latest human input plus the final assistant response, keeping tool outputs out of long-term user memory. Finally, it covers production configuration (persistent vector store, matching embedding dimensions, history DB path, temperature and telemetry settings), the trade-offs and failure modes of model-managed memory (lossy overwrites, silent parse/update errors, privacy considerations, and the option to store raw messages via infer=False), and ends with key takeaways and suggested homework. 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*-WP6Edcgl-6CTMXLs1yshQ.png" medium="image"></media:content>
            	</item>
		<item>
		<title>Part XIX — Spark on Kubernetes: Executor Sizing and Dynamic Allocation</title>
		<link>https://towardsai.com/p/machine-learning/part-xix-spark-on-kubernetes-executor-sizing-and-dynamic-allocation</link>
		
		<dc:creator><![CDATA[chakshu_salgotra]]></dc:creator>
		<pubDate>Sat, 31 Oct 2026 00:31:01 +0000</pubDate>
				<category><![CDATA[Data Engineering]]></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/part-xix-spark-on-kubernetes-executor-sizing-and-dynamic-allocation</guid>

					<description><![CDATA[Last Updated on November 2, 2026 by Editorial Team Author(s): chakshu_salgotra Originally published on Towards AI. Part XIX — Spark on Kubernetes: Executor Sizing and Dynamic Allocation Kubernetes killed our executors every night for a week while the JVM insisted memory was fine. The JVM was telling the truth — it just wasn’t the memory Kubernetes was measuring. Part I &#x007C; Part II &#x007C; Part III &#x007C; Part IV &#x007C; Part V &#x007C; Part VI &#x007C; Part VII &#x007C; Part VIII &#x007C; Part IX &#x007C; Part X &#x007C; Part XI &#x007C; Part XII &#x007C; Part XIII &#x007C; Part XIV &#x007C; Part XV &#x007C; Part XVI &#x007C; Part XVII &#x007C; Part XVIII &#x007C; Part XIX The Executors That Kept Dying at 2 AM The page came at 2:14 AM on a Tuesday: the overnight ETL had failed. Again. The third night in a row, and the fourth time that week if you counted Sunday’s partial run. Each time the same signature — executors dying mid-stage with exit code 137, the job restarting from the last shuffle boundary, and the whole thing stretching from its usual 90 minutes to 5 hours and 12 minutes before finally limping across the finish line or giving up. Here’s what made it maddening: the Spark UI showed nothing wrong. Executor heap usage hovered at 55–65%, GC looked healthy, no skew (Part VII’s playbook came back clean), no spill warnings. The driver was calm. By every metric Spark itself reported, the job was fine — and yet Kubernetes kept killing executors like it had a grudge. The kill count told the real story: 43 OOMKills in one night across 48 executors, each one forcing its shuffle outputs to be recomputed, each recompute triggering a retry storm that made the survivors work harder and die faster. We had configured each executor with 8 GB of heap, confident that was generous for the workload. Kubernetes disagreed, silently, at 2 AM, every night. So: why does Kubernetes kill a JVM that reports healthy memory — and how do you size executors for the scheduler that’s actually in charge? The Mechanic Underneath: The Pod Is the Unit of Accounting Here is the mental model: the JVM manages heap; Kubernetes manages the cgroup; and the cgroup always wins. When you set spark.executor.memory=8g, you&#39;ve configured the JVM&#39;s heap ceiling — not the pod&#39;s memory footprint. The pod also carries everything off-heap: Netty shuffle buffers, direct byte buffers, native libraries, thread stacks, GC bookkeeping, and Spark&#39;s own memory overhead. Kubernetes sums all of it against the pod&#39;s memory limit, and when the total crosses the line, the OOM killer fires. Exit 137. No warning, no heap dump, no appeal. This is why Spark’s metrics lied to us. The UI reports heap. The killer measures the cgroup. Our executors were running at 60% heap and 104% of their pod limit — healthy by Spark’s books, dead by Kubernetes’. Part IX of this series broke down what the driver, executors, and cluster manager each own. On Kubernetes, add one more owner: the kubelet, which enforces the one limit Spark never sees. Memory Overhead Is Not a Tuning Knob — It’s Physics Spark knows about this gap, which is why spark.executor.memoryOverhead exists. The default is max(384MB, 10% of executor memory) — for our 8 GB executors, 800 MB of headroom above heap. The problem: off-heap usage doesn&#39;t scale politely with heap. Shuffle-heavy stages allocate large Netty buffers and direct memory that can spike well past 10%, especially with wide joins or big aggregations. Our 800 MB of overhead was being eaten by shuffle buffers alone during the join stage; the rest — thread stacks, native code, page cache pressure — pushed the pod over the limit. The rule that actually holds: size the pod limit as heap + measured off-heap peak + margin, not heap + 10% and hope. The 10% default is a starting guess for average workloads. Shuffle-heavy ETL is not an average workload. Big Executors Are a Scheduling Tax Our original instinct had been fat executors: 12 cores, 32 GB heap each, fewer pods to manage. On YARN that instinct is often fine. On Kubernetes it’s a scheduling tax with three line items: Bin-packing: a 12-core pod only schedules where 12 contiguous cores are free. On a busy cluster, fat pods sit in Pending while small pods flow around them. We watched executors wait 9 minutes for placement on nights the cluster was warm. Blast radius: one OOMKill on a 12-core executor loses 12 cores of shuffle output at once. The retry storm is proportional to executor size. Task granularity: Spark parallelizes at the task level; a 12-core executor needs 12 concurrent tasks to stay busy. Narrow stages and small partitions leave cores idle — the “97% idle cluster” failure mode from Part IX, wearing a Kubernetes costume. The sane band for K8s executors is boring on purpose: 4–5 cores, 12–16 GB heap each. Small enough to schedule anywhere, small enough that a kill is a flesh wound, granular enough to keep cores fed. Match the node pool to the pod shape while you’re at it. If your executors request 4 cores and 15 GB, a node with 16 cores and 64 GB fits exactly four of them with no stranded capacity. Nodes sized as clean multiples of your executor shape turn bin-packing from a scheduling lottery into arithmetic — and it’s the cheapest utilization win on this whole page. Dynamic Allocation on Kubernetes Is Not YARN’s Dynamic Allocation This is the trap that bites every YARN veteran. On YARN, dynamic allocation leans on the external shuffle service — executors can be killed and their shuffle data survives. On Kubernetes there is no external shuffle service by default. If the autoscaler (or idle timeout) kills an executor holding shuffle output, that output is gone, and every downstream stage recomputes it. Spark 3.x added shuffle tracking on Kubernetes (spark.dynamicAllocation.shuffleTracking.enabled=true) as the answer: the driver tracks which executors hold shuffle data needed by running stages [&#8230;]]]></description>
		
		
		
		<media:content url="https://miro.medium.com/v2/resize:fit:700/1*6nT5uKb2wlo6gP-fye8tLA.png" medium="image"></media:content>
            	</item>
	</channel>
</rss>
