今日已更新 222 条资讯 | 累计 40667 条内容
关于我们

标签:#model

找到 131 篇相关文章

AI 资讯

Posterior Inference: From Joint Distributions to the Inference Bottleneck

A probabilistic model can describe more than the data you observe. It can also include hidden variables that capture structure you cannot observe directly. But defining that model is only the beginning. Once an observation x is available, the practical question changes: Given this x , what does the model imply about the hidden variable z ? That is the central problem of Posterior Inference . The notation is compact, but the computation is not always easy. High-dimensional latent spaces, complex posterior distributions, and interactions among hidden variables can make both the posterior itself and expectations under that posterior difficult to compute. Start with the Joint Distribution Suppose a probabilistic model contains an observed variable x and a hidden or latent variable z . The model does not treat them as unrelated quantities. Instead, it represents their probabilistic relationship through a Joint Distribution : p ( z , x ) This joint distribution describes how the observed data and the hidden variable fit together inside a single probability structure. Once x is observed, however, the question becomes conditional. We are no longer asking only how x and z relate in general. We want to know how the possible values of z are distributed given the particular observation x . That conditional distribution is the posterior. Posterior Distribution: Conditioning on Observed Data The Posterior Distribution is p ( z ∣ x ) = p ( x ) p ( z , x ) ​ The numerator p ( z , x ) contains the probabilistic relationship between the latent variable and the observation. The denominator p ( x ) normalizes those values so that the result becomes a conditional probability distribution over z . The distinction is important: The joint distribution p ( z , x ) describes the probability structure of the model. The posterior distribution p ( z ∣ x ) tells us what that structure implies about z after x has been observed. In that sense, the posterior connects the model with actual data. Pos

2026-09-08 原文 →
开发者

Filtered should never mean deleted

We shipped a filter that threw away bad GPS readings. Months later somebody asked whether it was working, and I could not answer. The evidence was gone. That question changed how I build anything that rejects data. The obvious version, and why it rots Mileage tracking depends on trustworthy distance, and GPS lies constantly. So the first version of our cleanup did what everyone's first version does: if (! fix . isPlausible ( previous )) return // drop it, move on accumulateDistance ( fix ) Clean data comes out the other end. It feels responsible. It is also a trap, because that return destroys the only record that could ever tell you whether the rejection was correct. Six months in, someone asked the reasonable question: is the filter right? I could not say how many readings we had dropped, on which journeys, or whether any of them had been a genuine drive through a tunnel rather than a glitch. We had built a thing that made a judgement call thousands of times a day and kept no record of any of it. Persist, then classify The rebuild flipped the default. Rejection stopped being a return and became a label. Only two cases are still deleted, because they cannot physically be real: // impossible coordinates if ( fix . lat ! in - 90.0 .. 90.0 || fix . lng ! in - 180.0 .. 180.0 ) return null // impossible accuracy: too precise to be true, or useless if ( fix . accuracyM <= 0.1f || fix . accuracyM >= 250f ) return null That is the entire delete list. Everything else is persisted and sorted into named accumulators: originalDistanceM += displacement // every metre we ever saw when { fix . isMock -> mockDistanceM += displacement abnormal -> { abnormalDistanceM += displacement if ( isHardSpike ) spikeDistanceM += displacement } accuracyGated -> { /* recorded, deliberately not counted */ } else -> cleanedDistanceM += displacement } Five numbers instead of one. The UI shows cleaned . The rest live beside it. And the row itself keeps its provenance: accuracy, provider, bearing, a

2026-09-06 原文 →
AI 资讯

Why Most AI Agents Fail Long Before the Model Does

The agent did not fail because the model was stupid. It failed because a CRM tool returned a 502, the agent retried, created two support tickets, read a stale knowledge-base article, filled the context window with stack traces, and then told the customer everything was fine. When teams see this, the instinct is often to upgrade the model. But the same failure usually happens again, only with better prose. Most AI agent failures are not model failures. They are system failures: unclear objectives, weak tool contracts, missing budgets, excessive permissions, noisy context, no idempotency, no trajectory evaluation, and no sane recovery path. The model is only one component in a loop. The loop is the product. By 2026, models are much better at tool calling, structured output, and multi-step reasoning than they were a few years ago. That has made agents more practical, but it has not removed the engineering problem. If anything, more capable models make weak guardrails more dangerous, because the system looks competent for longer. TL;DR: AI agents usually fail because of the surrounding system, not the model. The common failure points are vague task contracts, weak tool schemas, excessive permissions, context rot, unbounded loops, non-idempotent tools, prompt-injection risk, missing trajectory evals, poor observability, and an obsession with autonomy over recovery. Reliable agents are built like careful distributed systems, not magic chatbots. 📋 Table of Contents The Model Is Not the System 1. The Agent Was Given a Goal, Not a Contract 2. Tool Schemas Are the Real Prompt 3. The Agent Has Access Before It Has Judgment 4. Context Rot Happens Before Model Degradation 5. Loops Fail When There Is No Budget or Circuit Breaker 6. Retries Turn Flaky Tools into Confident Lies 7. Prompt Injection Is an Architecture Problem 8. Nobody Evaluates the Trajectory 9. Observability Stops at the Final Answer 10. The System Optimizes for Autonomy Instead of Recovery A Practical Autonomy Che

2026-09-05 原文 →
AI 资讯

Stop Wasting API Tokens: How to Bridge ChatGPT Web to Your IDE Using MCP

If you are an active user of AI-powered IDEs like Cursor, VS Code with Copilot, or Windsurf, you already know the sinking feeling of seeing this notification: "You have used 100% of your fast premium requests for this billing cycle." Suddenly, your snappy, context-aware coding assistant slows to a crawl or starts racking up expensive pay-as-you-go API bills. At the same time, you are likely paying $20/month for a ChatGPT Plus or Team subscription that sits underutilized in a browser tab. You use it for general questions, but it lacks direct, real-time access to your local codebase, forcing you to engage in a tedious dance of copying and pasting code blocks. What if you could bridge this gap? What if you could let ChatGPT Web do the heavy reasoning and planning using your local context, while saving your premium IDE tokens for fast auto-completions ? In this article, we’ll explore a highly novel, intermediate-level setup that does exactly this. By leveraging the Model Context Protocol (MCP) , Node.js , and secure Cloudflare Tunnels , you can route heavy code-planning tasks directly to your web-based ChatGPT Plus subscription safely and completely free of extra token charges. The Philosophy: Let ChatGPT Think, Let Your IDE Work When building complex software with AI, your workflow generally splits into two distinct phases: Reasoning & Planning (High Token Usage): This is where you ask the AI to read 10 source files, understand the architecture, design a new feature, or find a subtle bug. This consumes massive amounts of context window tokens. Execution & Autocomplete (Low Latency): This is where the AI writes single lines of code, refactors a function, or autocompletes your imports. This requires fast, inline API queries. Paying premium API rates (per token) for Phase 1 is incredibly expensive. This is where this open-source MCP bridge project shines. It exposes a read-only view of your local project as an MCP server. Your web-based ChatGPT (via custom GPTs or MCP int

2026-09-04 原文 →
AI 资讯

Cohere’s Parse 5 Promises Efficient Multi-Modal Information Extraction From Complex Documents

Cohere has launched Parse 5, a multimodal foundation model designed to extract structured data from complex enterprise documents. The 2.3-billion-parameter system converts visually rich PDFs into Markdown while providing bounding box coordinates for visual grounding. It has been evaluated against over 2,000 enterprise pages, achieving an average score of 79.2 in key performance areas. By Olimpiu Pop

2026-09-03 原文 →
AI 资讯

Presentation: Beyond Prompting: Context Engineering for Production-Grade AI

Ricardo Ferreira discusses moving beyond simple prompt engineering to build production-grade AI applications. He shares practical architectural strategies for integrating long-term and short-term memory using Redis, managing LLM token limits via summarization, mitigating context rot with reranking and semantic caching, and controlling exponential API costs under strict latency constraints. By Ricardo Ferreira

2026-09-02 原文 →
AI 资讯

Generative Modeling: From Data Distributions to Deep Generative Models

If you approach generative models as ""networks that create images,"" the field quickly turns into a collection of disconnected architectures. A more useful developer mental model starts one level lower: What probability structure could have produced the data, and how can we represent, learn, and infer that structure without making the computation impossible? That question connects autoregressive models, VAEs, flow-based models, GANs, and diffusion models. Their architectures look very different, but they all respond to the same underlying tension: high-dimensional data distributions are difficult to represent, learn, normalize, sample from, and reason about. Generative modeling can therefore be organized around three interacting problems: Representation: How do we represent a complex high-dimensional joint distribution? Learning: How do we make the model distribution approach the data distribution? Inference: Given an observation, how do we reason backward about hidden variables or the process that generated it? Once these three pieces are connected, the major families of deep generative models become much easier to understand. From prediction to distribution learning A discriminative model usually begins with a prediction problem. Given an input x , predict the most likely output y : f ( x ) = y ar g max ​ p ( y ∣ x ) The model focuses directly on the conditional relationship required for prediction. A generative model asks a broader question. Instead of learning only the path from x to y , it models the probability structure from which the data arises. For class-conditional modeling, for example, we can model p ( x ∣ y ) together with the prior p ( y ) and recover the posterior using Bayes' rule: p ( y ∣ x ) = p ( x ) p ( x ∣ y ) p ( y ) ​ In unsupervised generative modeling, the target becomes the data distribution itself. We assume the training samples come from some unknown distribution: x 1 ​ , x 2 ​ , … , x N ​ ∼ i.i.d. p data ​ ( x ) The model then construc

2026-09-02 原文 →
AI 资讯

From Natural Language to Robot Actions with Physical Foundation Models

From Natural Language to Robot Actions with Physical Foundation Models Physical AI aims to connect intelligence with real-world action. A user might say: "Bring me the bottle from the kitchen." A robot must turn that high-level instruction into a sequence of grounded actions. The Full Pipeline Natural Language | v Task Understanding | v World Model | v Task Planning | v Motion Planning | v Control | v Physical Robot The important insight is that language understanding alone is not enough. Grounding Language in the World Consider: "Pick up the bottle." The system must identify: Which bottle? Where is it? Can the robot reach it? Is the gripper suitable? Is the route collision-free? Therefore: Language + Vision + Robot State + Environment Model | v Grounded Action Action Representation A foundation model can produce structured actions rather than motor commands: { "action" : "pick" , "object" : "bottle" , "location" : "kitchen_counter" } The robotics stack then translates this into navigation and manipulation primitives. Hierarchical Planning A high-level instruction can be decomposed: Bring bottle | +--> Navigate to kitchen | +--> Find bottle | +--> Reach bottle | +--> Grasp bottle | +--> Navigate to user | +--> Release bottle Each subtask can be executed and verified independently. Connecting to ROS 2 /natural_language_task | v /task_planner | v /world_model | v /action_executor / v v /navigation /manipulation Verification Loop Physical AI should use closed-loop execution: Plan | v Execute | v Observe | v Verify | +---- success ---> Next Step | +---- failure ---> Replan This is critical because the physical world is uncertain. A grasp may fail. An obstacle may move. A door may be closed. Safety Boundaries Foundation models should operate behind explicit constraints: Allowed actions Workspace limits Collision checking Velocity limits Force limits Emergency stop Human approval for sensitive actions Production Architecture Separate responsibilities: Foundation Model | |

2026-09-01 原文 →
AI 资讯

Presentation: Architecting the Data Layer for AI Agents: From Transactional Systems to MCP and Semantic Models

Fabiane Nardon shares how TOTVS prepares enterprise data for token-hungry AI agents. She discusses balancing deterministic logic and non-deterministic LLMs across precision, security, and cost. Nardon details using data mesh, low-latency database architectures, semantic ontologies, and dynamic MCP tool selection to optimize context windows and reduce token overhead in transactional systems. By Fabiane Nardon

2026-08-29 原文 →
AI 资讯

OpenSCAD Model With Animation Video and MakerWorld Multi-Plate Support

Contents Motivation and Purpose Using an Animation to Visualize Key Concepts Working With the Model 1. Get the Files 2. Choose the Dimensions 3. Inspect the Assembly 4. Export the MakerWorld Plates 5. Attach the Hoses Create the Model Animation Reference Links Motivation and Purpose I made a parametric bayonet connector for AC hoses , to attach such hoses to a mobile AC unit and a typical window kit taking the hot air outside. It is part of my Air Conditioning Collection on MakerWorld . And of course, I prefer code over using some GUI CAD application, leading straight to OpenSCAD as the established standard for 3D-models-as-code. It is also one of the few ways MakerWorld models can be made customizable by the end user. The connector allows attaching a hose with a simple push and a short twist, instead of needing a threaded joint or tools every time the hose is removed. The design has three printable parts: A female connector with bayonet slots on the inside. A male connector with matching lugs. A female adapter with a wider fitting section for joining to an existing tube, like the one on an air intake cover. The male lugs fit into the slots in the female connector. Push the parts together, twist them, and the lugs travel along the horizontal parts of the L-shaped slots. This is the same basic idea used by bayonet light fittings, camera mounts, and other quick-release connectors. See the Bayonet mount overview for useful background. The hose itself is held on the printed connector with a worm-drive hose clamp. A screw on the clamp pulls the perforated band tight around the hose. See the Hose clamp reference for an explanation of that mechanism. Using an Animation to Visualize Key Concepts The OpenSCAD file contains code that creates a 10-scene animation. It shows the female connector turning to expose the slots, the hose and male connector moving into position, the male part twisting to lock, and the parts separating again. It also emphasises the parametric nature of

2026-08-29 原文 →
AI 资讯

FreeToken Unlocks Frontier MoE Inference on Consumer Hardware via Dynamic Co-Execution

Researchers from UC Berkeley and MIT have developed FreeToken, an open-source inference engine that enhances the utility of Mixture-of-Experts models on consumer hardware. By implementing a dynamic scheduling policy and optimising weight management, FreeToken improves decoding speeds and execution efficiency in edge AI applications, fostering self-hosted reasoning systems. By Olimpiu Pop

2026-08-29 原文 →