YouZum

Uncategorized

AI, Committee, 新闻, Uncategorized

IBM AI Releases Granite 4.0 1B Speech as a Compact Multilingual Speech Model for Edge AI and Translation Pipelines

IBM has released Granite 4.0 1B Speech, a compact speech-language model designed for multilingual automatic speech recognition (ASR) and bidirectional automatic speech translation (AST). The release targets enterprise and edge-style speech deployments where memory footprint, latency, and compute efficiency matter as much as raw benchmark quality. What Changed in Granite 4.0 1B Speech At the center of the release is a straightforward design goal: reduce model size without dropping the core capabilities expected from a modern multilingual speech system. Granite 4.0 1B Speech has half the number of parameters of granite-speech-3.3-2b, while adding Japanese ASR, keyword list biasing, and improved English transcription accuracy. The model provides faster inference through better encoder training and speculative decoding. That makes the release less about pushing model scale upward and more about tightening the efficiency-quality tradeoff for practical deployment. Training Approach and Modality Alignment Granite-4.0-1b-speech is a compact and efficient speech-language model trained for multilingual ASR and bidirectional AST. The training mix includes public ASR and AST corpora along with synthetic data used to support Japanese ASR, keyword-biased ASR, and speech translation. This is an important detail for devs because it shows IBM’s team did not build a separate closed speech stack from scratch; it adapted a Granite 4.0 base language model into a speech-capable model through alignment and multimodal training. Language Coverage and Intended Use The supported language set includes English, French, German, Spanish, Portuguese, and Japanese. IBM positions the model for speech-to-text and speech translation to and from English for those languages. It also support for English-to-Italian and English-to-Mandarin translation scenarios. The model is released under the Apache 2.0 license, which makes it more straightforward for teams evaluating open deployment options compared with speech systems that carry commercial restrictions or API-only access patterns. Two-Pass Design and Pipeline Structure IBM’s Granite Speech Team describes the Granite Speech family as using a two-pass design. In that setup, an initial call transcribes audio into text, and any downstream language-model reasoning over the transcript requires a second explicit call to the Granite language model. That differs from integrated architectures that combine speech and language generation into a single pass. For developers, this matters because it affects orchestration. A transcription pipeline built around Granite Speech is modular by design: speech recognition comes first, and language-level post-processing is a separate step. Benchmark Results and Efficiency Positioning Granite 4.0 1B Speech recently ranked #1 on the OpenASR leaderboard. The Open ASR leaderboard row states with an Average WER of 5.52 and RTFx of 280.02, alongside dataset-specific WER values such as 1.42 on LibriSpeech Clean, 2.85 on LibriSpeech Other, 3.89 on SPGISpeech, 3.1 on Tedlium, and 5.84 on VoxPopuli. Deployment Details For deployment, Granite 4.0 1B Speech is supported natively in transformers>=4.52.1 and can be served through vLLM, giving teams both standard Python inference and API-style serving options. IBM’s reference transformers flow uses AutoModelForSpeechSeq2Seq and AutoProcessor, expects mono 16 kHz audio, and formats requests by prepending <|audio|> to the user prompt; keyword biasing can be added directly in the prompt as Keywords: <kw1>, <kw2> …. For lower-resource environments, IBM’s vLLM example sets max_model_len=2048 and limit_mm_per_prompt={“audio”: 1}, while online serving can be exposed through vllm serve with an OpenAI-compatible API interface. Key Takeaways Granite 4.0 1B Speech is a compact speech-language model for multilingual ASR and bidirectional AST. The model has half the parameters of granite-speech-3.3-2b while improving deployment efficiency. The release adds Japanese ASR and keyword list biasing for more targeted transcription workflows. It supports deployment through Transformers, vLLM, and mlx-audio, including Apple Silicon environments. The model is positioned for resource-constrained devices where latency, memory, and compute cost are critical. Check out Model Page, Repo and Technical details. Also, feel free to follow us on Twitter and don’t forget to join our 120k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post IBM AI Releases Granite 4.0 1B Speech as a Compact Multilingual Speech Model for Edge AI and Translation Pipelines appeared first on MarkTechPost.

IBM AI Releases Granite 4.0 1B Speech as a Compact Multilingual Speech Model for Edge AI and Translation Pipelines Read Post »

AI, Committee, 新闻, Uncategorized

Moonshot AI Releases 𝑨𝒕𝒕𝒆𝒏𝒕𝒊𝒐𝒏 𝑹𝒆𝒔𝒊𝒅𝒖𝒂𝒍𝒔 to Replace Fixed Residual Mixing with Depth-Wise Attention for Better Scaling in Transformers

Residual connections are one of the least questioned parts of modern Transformer design. In PreNorm architectures, each layer adds its output back into a running hidden state, which keeps optimization stable and allows deep models to train. Moonshot AI researchers argue that this standard mechanism also introduces a structural problem: all prior layer outputs are accumulated with fixed unit weights, which causes hidden-state magnitude to grow with depth and progressively weakens the contribution of any single layer. The research team proposes Attention Residuals (AttnRes) as a drop-in replacement for standard residual accumulation. Instead of forcing every layer to consume the same uniformly mixed residual stream, AttnRes lets each layer aggregate earlier representations using softmax attention over depth. The input to layer (l) is a weighted sum of the token embedding and previous layer outputs, where the weights are computed over prior depth positions rather than over sequence positions. The core idea is simple: if attention improved sequence modeling by replacing fixed recurrence over time, a similar idea can be applied to the depth dimension of a network. https://github.com/MoonshotAI/Attention-Residuals/tree/master?tab=readme-ov-file Why Standard Residuals Become a Bottleneck The research team identified three issues with standard residual accumulation. First, there is no selective access: all layers receive the same aggregated state even though attention layers and feed-forward or MoE layers may benefit from different mixtures of earlier information. Second, there is irreversible loss: once information is blended into a single residual stream, later layers cannot selectively recover specific earlier representations. Third, there is output growth: deeper layers tend to produce larger outputs to remain influential inside an ever-growing accumulated state, which can destabilize training. This is the research team’s main framing: standard residuals behave like a compressed recurrence over layers. AttnRes replaces that fixed recurrence with explicit attention over previous layer outputs. Full AttnRes: Attention Over All Previous Layers In Full AttnRes, each layer computes attention weights over all preceding depth sources. The default design does not use an input-conditioned query. Instead, each layer has a learned layer-specific pseudo-query vector wl ∈ Rd, while keys and values come from the token embedding and previous layer outputs after RMSNorm. The RMSNorm step is important because it prevents large-magnitude layer outputs from dominating the depth-wise attention weights. Full AttnRes is straightforward, but it increases cost. Per token, it requires O(L2 d) arithmetic and (O(Ld)) memory to store layer outputs. In standard training this memory largely overlaps with activations already needed for backpropagation, but under activation re-computation and pipeline parallelism the overhead becomes more significant because those earlier outputs must remain available and may need to be transmitted across stages. Block AttnRes: A Practical Variant for Large Models To make the method usable at scale, Moonshot AI research team introduces Block AttnRes. Instead of attending over every earlier layer output, the model partitions layers into N blocks. Within each block, outputs are accumulated into a single block representation, and attention is applied only over those block-level representations plus the token embedding. This reduces memory and communication overhead from O(Ld) to O(Nd). The research team describes cache-based pipeline communication and a two-phase computation strategy that make Block AttnRes practical in distributed training and inference. This results in less than 4% training overhead under pipeline parallelism, while the repository reports less than 2% inference latency overhead on typical workloads. Scaling Results The research team evaluates five model sizes and compares three variants at each size: a PreNorm baseline, Full AttnRes, and Block AttnRes with about eight blocks. All variants within each size group share the same hyperparameters chosen under the baseline, which the research team note makes the comparison conservative. The fitted scaling laws are reported as: Baseline: L = 1.891 x C-0.057Block AttnRes: L = 1.870 x C-0.058Full AttnRes: L = 1.865 x C-0.057 The practical implication is that AttnRes achieves lower validation loss across the tested compute range, and the Block AttnRes matches the loss of a baseline trained with about 1.25× more compute. Integration into Kimi Linear Moonshot AI also integrates AttnRes into Kimi Linear, its MoE architecture with 48B total parameters and 3B activated parameters, and pre-trains it on 1.4T tokens. According to the research paper, AttnRes mitigates PreNorm dilution by keeping output magnitudes more bounded across depth and distributing gradients more uniformly across layers. Another implementation detail is that all pseudo-query vectors are initialized to zero so the initial attention weights are uniform across source layers, effectively reducing AttnRes to equal-weight averaging at the start of training and avoiding early instability. On downstream evaluation, the reported gains are consistent across all listed tasks. It reports improvements from 73.5 to 74.6 on MMLU, 36.9 to 44.4 on GPQA-Diamond, 76.3 to 78.0 on BBH, 53.5 to 57.1 on Math, 59.1 to 62.2 on HumanEval, 72.0 to 73.9 on MBPP, 82.0 to 82.9 on CMMLU, and 79.6 to 82.5 on C-Eval. Key Takeaways Attention Residuals replaces fixed residual accumulation with softmax attention over previous layers. The default AttnRes design uses a learned layer-specific pseudo-query, not an input-conditioned query. Block AttnRes makes the method practical by reducing depth-wise memory and communication from O(Ld) to O(Nd). Moonshot research teamreports lower scaling loss than the PreNorm baseline, with Block AttnRes matching about 1.25× more baseline compute. In Kimi Linear, AttnRes improves results across reasoning, coding, and evaluation benchmarks with limited overhead. Check out Paper and Repo. Also, feel free to follow us on Twitter and don’t forget to join our 120k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post Moonshot AI Releases 𝑨𝒕𝒕𝒆𝒏𝒕𝒊𝒐𝒏 𝑹𝒆𝒔𝒊𝒅𝒖𝒂𝒍𝒔 to Replace Fixed Residual Mixing with Depth-Wise Attention for Better Scaling in Transformers appeared first on MarkTechPost.

Moonshot AI Releases 𝑨𝒕𝒕𝒆𝒏𝒕𝒊𝒐𝒏 𝑹𝒆𝒔𝒊𝒅𝒖𝒂𝒍𝒔 to Replace Fixed Residual Mixing with Depth-Wise Attention for Better Scaling in Transformers Read Post »

AI, Committee, 新闻, Uncategorized

How to Build Type-Safe, Schema-Constrained, and Function-Driven LLM Pipelines Using Outlines and Pydantic

In this tutorial, we build a workflow using Outlines to generate structured and type-safe outputs from language models. We work with typed constraints like Literal, int, and bool, and design prompt templates using outlines.Template, and enforce strict schema validation with Pydantic models. We also implement robust JSON recovery and a function-calling style that generates validated arguments and executes Python functions safely. Throughout the tutorial, we focus on reliability, constraint enforcement, and production-grade structured generation. Copy CodeCopiedUse a different Browser import os, sys, subprocess, json, textwrap, re subprocess.check_call([sys.executable, “-m”, “pip”, “install”, “-q”, “outlines”, “transformers”, “accelerate”, “sentencepiece”, “pydantic”]) import torch import outlines from transformers import AutoTokenizer, AutoModelForCausalLM from typing import Literal, List, Union, Annotated from pydantic import BaseModel, Field from enum import Enum print(“Torch:”, torch.__version__) print(“CUDA available:”, torch.cuda.is_available()) print(“Outlines:”, getattr(outlines, “__version__”, “unknown”)) device = “cuda” if torch.cuda.is_available() else “cpu” print(“Using device:”, device) MODEL_NAME = “HuggingFaceTB/SmolLM2-135M-Instruct” tokenizer = AutoTokenizer.from_pretrained(MODEL_NAME, use_fast=True) hf_model = AutoModelForCausalLM.from_pretrained( MODEL_NAME, torch_dtype=torch.float16 if device == “cuda” else torch.float32, device_map=”auto” if device == “cuda” else None, ) if device == “cpu”: hf_model = hf_model.to(device) model = outlines.from_transformers(hf_model, tokenizer) def build_chat(user_text: str, system_text: str = “You are a precise assistant. Follow instructions exactly.”) -> str: try: msgs = [{“role”: “system”, “content”: system_text}, {“role”: “user”, “content”: user_text}] return tokenizer.apply_chat_template(msgs, tokenize=False, add_generation_prompt=True) except Exception: return f”{system_text}nnUser: {user_text}nAssistant:” def banner(title: str): print(“n” + “=” * 90) print(title) print(“=” * 90) We install all required dependencies and initialize the Outlines pipeline with a lightweight instruct model. We configure device handling so that the system automatically switches between CPU and GPU based on availability. We also build reusable helper functions for chat formatting and clean section banners to structure the workflow. Copy CodeCopiedUse a different Browser def extract_json_object(s: str) -> str: s = s.strip() start = s.find(“{“) if start == -1: return s depth = 0 in_str = False esc = False for i in range(start, len(s)): ch = s[i] if in_str: if esc: esc = False elif ch == “\”: esc = True elif ch == ‘”‘: in_str = False else: if ch == ‘”‘: in_str = True elif ch == “{“: depth += 1 elif ch == “}”: depth -= 1 if depth == 0: return s[start:i + 1] return s[start:] def json_repair_minimal(bad: str) -> str: bad = bad.strip() last = bad.rfind(“}”) if last != -1: return bad[:last + 1] return bad def safe_validate(model_cls, raw_text: str): raw = extract_json_object(raw_text) try: return model_cls.model_validate_json(raw) except Exception: raw2 = json_repair_minimal(raw) return model_cls.model_validate_json(raw2) banner(“2) Typed outputs (Literal / int / bool)”) sentiment = model( build_chat(“Analyze the sentiment: ‘This product completely changed my life!’. Return one label only.”), Literal[“Positive”, “Negative”, “Neutral”], max_new_tokens=8, ) print(“Sentiment:”, sentiment) bp = model(build_chat(“What’s the boiling point of water in Celsius? Return integer only.”), int, max_new_tokens=8) print(“Boiling point (int):”, bp) prime = model(build_chat(“Is 29 a prime number? Return true or false only.”), bool, max_new_tokens=6) print(“Is prime (bool):”, prime) We implement robust JSON extraction and minimal repair utilities to safely recover structured outputs from imperfect generations. We then demonstrate strongly typed generation using Literal, int, and bool, ensuring the model returns values that are strictly constrained. We validate how Outlines enforces deterministic type-safe outputs directly at generation time. Copy CodeCopiedUse a different Browser banner(“3) Prompt templating (outlines.Template)”) tmpl = outlines.Template.from_string(textwrap.dedent(“”” <|system|> You are a strict classifier. Return ONLY one label. <|user|> Classify sentiment of this text: {{ text }} Labels: Positive, Negative, Neutral <|assistant|> “””).strip()) templated = model(tmpl(text=”The food was cold but the staff were kind.”), Literal[“Positive”,”Negative”,”Neutral”], max_new_tokens=8) print(“Template sentiment:”, templated) We use outlines.Template to build structured prompt templates with strict output control. We dynamically inject user input into the template while preserving role formatting and classification constraints. We demonstrate how templating improves reusability and ensures consistent, constrained responses. Copy CodeCopiedUse a different Browser banner(“4) Pydantic structured output (advanced constraints)”) class TicketPriority(str, Enum): low = “low” medium = “medium” high = “high” urgent = “urgent” IPv4 = Annotated[str, Field(pattern=r”^((25[0-5]|2[0-4]d|[01]?dd?).){3}(25[0-5]|2[0-4]d|[01]?dd?)$”)] ISODate = Annotated[str, Field(pattern=r”^d{4}-d{2}-d{2}$”)] class ServiceTicket(BaseModel): priority: TicketPriority category: Literal[“billing”, “login”, “bug”, “feature_request”, “other”] requires_manager: bool summary: str = Field(min_length=10, max_length=220) action_items: List[str] = Field(min_length=1, max_length=6) class NetworkIncident(BaseModel): affected_service: Literal[“dns”, “vpn”, “api”, “website”, “database”] severity: Literal[“sev1”, “sev2”, “sev3”] public_ip: IPv4 start_date: ISODate mitigation: List[str] = Field(min_length=2, max_length=6) email = “”” Subject: URGENT – Cannot access my account after payment I paid for the premium plan 3 hours ago and still can’t access any features. I have a client presentation in an hour and need the analytics dashboard. Please fix this immediately or refund my payment. “””.strip() ticket_text = model( build_chat( “Extract a ServiceTicket from this message.n” “Return JSON ONLY matching the ServiceTicket schema.n” “Action items must be distinct.nnMESSAGE:n” + email ), ServiceTicket, max_new_tokens=240, ) ticket = safe_validate(ServiceTicket, ticket_text) if isinstance(ticket_text, str) else ticket_text print(“ServiceTicket JSON:n”, ticket.model_dump_json(indent=2)) We define advanced Pydantic schemas with enums, regex constraints, field limits, and structured lists. We extract a complex ServiceTicket object from raw email text and validate it using schema-driven decoding. We also apply safe validation logic to handle edge cases and ensure robustness at production scale. Copy CodeCopiedUse a different Browser banner(“5) Function-calling style (schema -> args -> call)”) class AddArgs(BaseModel): a: int = Field(ge=-1000, le=1000) b: int = Field(ge=-1000, le=1000) def add(a: int, b: int) -> int: return a + b args_text = model( build_chat(“Return JSON ONLY with two integers a and b. Make a odd and b even.”), AddArgs, max_new_tokens=80, ) args = safe_validate(AddArgs, args_text) if isinstance(args_text, str) else args_text print(“Args:”, args.model_dump()) print(“add(a,b) =”, add(args.a, args.b)) print(“Tip: For best speed and fewer truncations, switch Colab Runtime → GPU.”) We implement a function-calling style workflow by generating structured arguments that conform to a defined schema. We validate the generated arguments, then safely execute a Python function with those validated inputs. We demonstrate how schema-first generation enables controlled tool invocation and reliable LLM-driven computation. In conclusion, we implemented a fully structured generation pipeline using Outlines with strong typing, schema validation, and controlled decoding. We demonstrated how to move from simple typed outputs to advanced Pydantic-based extraction and function-style execution patterns. We also built resilience through JSON salvage and validation mechanisms, making

How to Build Type-Safe, Schema-Constrained, and Function-Driven LLM Pipelines Using Outlines and Pydantic Read Post »

AI, Committee, 新闻, Uncategorized

Zhipu AI Introduces GLM-OCR: A 0.9B Multimodal OCR Model for Document Parsing and Key Information Extraction (KIE)

Why Document OCR Still Remains a Hard Engineering Problem? What does it take to make OCR useful for real documents instead of clean demo images? And can a compact multimodal model handle parsing, tables, formulas, and structured extraction without turning inference into a resource bonfire? That is the problem targeted by GLM-OCR, introduced by researchers from Zhipu AI and Tsinghua University. The research team presents GLM-OCR as a 0.9B-parameter compact multimodal model for document understanding. It combines a 0.4B CogViT visual encoder, a lightweight cross-modal connector, and a 0.5B GLM language decoder. The stated goal is to balance document recognition quality with lower latency and lower computational cost than larger multimodal systems. Traditional OCR systems are often good at plain text transcription, but they struggle when documents contain mixed layouts, tables, formulas, code blocks, seals, and structured fields. Recent multimodal large language models improve document understanding, but the research team argue that their size and standard autoregressive decoding make them expensive for edge deployment and large-scale production. GLM-OCR is positioned as a smaller system built for these deployment constraints rather than as a general-purpose vision-language model adapted to OCR as an afterthought. A Compact Architecture Built for OCR Workloads A key technical point for this research is the use of Multi-Token Prediction (MTP). Standard autoregressive decoding predicts one token at a time, which is not ideal for OCR-style tasks where outputs are often deterministic and locally structured. GLM-OCR instead predicts multiple tokens per step. The model is trained to predict 10 tokens per step and generates 5.2 tokens per decoding step on average at inference time, yielding about 50% throughput improvement. To keep memory overhead manageable, the implementation uses a parameter-sharing scheme across the draft models. Two-Stage Layout Parsing Instead of Flat Page Reading At the system level, GLM-OCR adopts a two-stage pipeline. The first stage uses PP-DocLayout-V3 for layout analysis, which detects structured regions on the page. The second stage performs parallel region-level recognition over those detected areas. This is important because the model is not simply reading a whole page left-to-right as a generic vision-language model might. It first breaks down the page into semantically meaningful regions, which improves efficiency and makes the system more robust on documents with complicated layouts. Document Parsing and KIE Use Different Output Paths The architecture also separates two related document tasks. For document parsing, the pipeline uses layout detection and region processing to produce structured outputs such as Markdown and JSON. For Key Information Extraction (KIE), the research team describes a different path: the full document image is fed to the model with a task prompt, and the model directly generates JSON containing the extracted fields. That distinction matters because GLM-OCR is not presented as a single monolithic page-to-text model. It is a structured generation system with different operating modes depending on the task. A Four-Stage Training Pipeline with Task-Specific Rewards The training recipe is split into 4 stages. Stage 1 trains the vision encoder on image-text pairs and grounding or retrieval data. Stage 2.1 performs multimodal pretraining on image-text, document parsing, grounding, and VQA data. Stage 2.2 adds the MTP objective. Stage 3 is supervised fine-tuning on OCR-specific tasks including text recognition, formula transcription, table structure recovery, and KIE. Stage 4 applies reinforcement learning using GRPO. The reward design is task-specific: Normalized Edit Distance for text recognition, CDM score for formula recognition, TEDS score for table recognition, and field-level F1 for KIE, along with structural penalties such as repetition penalties, malformed structure penalties, and JSON validation constraints. Benchmark Results Show Strong Performance, With Important Caveats On public benchmarks, GLM-OCR reports strong results across several document tasks. It scores 94.6 on OmniDocBench v1.5, 94.0 on OCRBench (Text), 96.5 on UniMERNet, 85.2 on PubTabNet, and 86.0 on TEDS_TEST. For KIE, it reports 93.7 on Nanonets-KIE and 86.1 on Handwritten-KIE. The research team notes that results for Gemini-3-Pro and GPT-5.2-2025-12-11 are shown only for reference and are excluded from the best-score ranking, which is an important detail when interpreting claims about model leadership. https://arxiv.org/pdf/2603.10910 The benchmark story is strong, but it needs careful phrasing. GLM-OCR achieves the highest reported scores among the evaluated non-reference models on OmniDocBench v1.5, OCRBench (Text), UniMERNet, and TEDS_TEST. On PubTabNet, however, it does not lead overall; MinerU 2.5 reports 88.4 versus GLM-OCR’s 85.2. For KIE, GLM-OCR outperforms the listed open-source competitors in the above table, but Gemini-3-Pro scores higher on both Nanonets-KIE and Handwritten-KIE in the reference column. So the reserach team supports a strong competitive claim, but not a blanket ‘best at everything’ claim. Deployment Details The research team state that GLM-OCR supports vLLM, SGLang, and Ollama, and can be fine-tuned through LLaMA-Factory. They also report throughput of 0.67 images/s and 1.86 PDF pages/s under their evaluation setup. In addition, they describe a MaaS API priced at 0.2 RMB per million tokens, with example cost estimates for scanned images and simple-layout PDFs. These details suggest that GLM-OCR is being framed as both a research model and a deployable system. Key Takeaways GLM-OCR is a compact 0.9B multimodal OCR model built with a 0.4B CogViT encoder and 0.5B GLM decoder. It uses Multi-Token Prediction (MTP) to improve decoding efficiency, reaching 5.2 tokens per step on average and about 50% higher throughput. The model uses a two-stage pipeline: PP-DocLayout-V3 handles layout analysis, then GLM-OCR performs parallel region-level recognition. It supports both document parsing and KIE: parsing outputs Markdown/JSON, while KIE directly generates JSON from the full document image. Benchmark results are strong but not universal wins: GLM-OCR leads several reported non-reference benchmarks, but MinerU 2.5 is higher on PubTabNet, and Gemini-3-Pro is higher on the reference-only KIE scores. Check out Paper, Repo and Model Page. Also, feel free to follow us on Twitter and don’t forget to join our 120k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post Zhipu AI Introduces GLM-OCR: A 0.9B Multimodal OCR Model for Document Parsing and Key Information Extraction (KIE) appeared first on MarkTechPost.

Zhipu AI Introduces GLM-OCR: A 0.9B Multimodal OCR Model for Document Parsing and Key Information Extraction (KIE) Read Post »

AI, Committee, 新闻, Uncategorized

LangChain Releases Deep Agents: A Structured Runtime for Planning, Memory, and Context Isolation in Multi-Step AI Agents

Most LLM agents work well for short tool-calling loops but start to break down when the task becomes multi-step, stateful, and artifact-heavy. LangChain’s Deep Agents is designed for that gap. The project is described by LangChain as an ‘agent harness‘: a standalone library built on top of LangChain’s agent building blocks and powered by the LangGraph runtime for durable execution, streaming, and human-in-the-loop workflows. The important point is that Deep Agents does not introduce a new reasoning model or a new runtime separate from LangGraph. Instead, it packages a set of defaults and built-in tools around the standard tool-calling loop. LangChain team positions it as the easier starting point for developers who need agents that can plan, manage large context, delegate subtasks, and persist information across conversations, while still keeping the option to move to simpler LangChain agents or custom LangGraph workflows when needed. What Deep Agents Includes by Default The Deep Agents GitHub repository lists the core components directly. These include a planning tool called write_todos, filesystem tools such as read_file, write_file, edit_file, ls, glob, and grep, shell access through execute with sandboxing, the task tool for spawning subagents, and built-in context management features such as auto-summarization and saving large outputs to files. That framing matters because many agent systems leave planning, intermediate storage, and subtask delegation to the application developer. Deep Agents moves those pieces into the default runtime. Planning and Task Decomposition Deep Agents includes a built-in write_todos tool for planning and task decomposition. The purpose is explicit: the agent can break a complex task into discrete steps, track progress, and update the plan as new information appears. Without a planning layer, the model tends to improvise each step from the current prompt. With write_todos, the workflow becomes more structured, which is more useful for research tasks, coding sessions, or analysis jobs that unfold over several steps. Filesystem-Based Context Management A second core feature is the use of filesystem tools for context management. These tools allow the agent to offload large context into storage rather than keeping everything inside the active prompt window. LangChain team explicitly notes that this helps prevent context window overflow and supports variable-length tool results. This is a more concrete design choice than vague claims about ‘memory.’ The agent can write notes, generated code, intermediate reports, or search outputs into files and retrieve them later. That makes the system more suitable for longer tasks where the output itself becomes part of the working state. Deep Agents also supports multiple backend types for this virtual filesystem. The customization docs list StateBackend, FilesystemBackend, LocalShellBackend, StoreBackend, and CompositeBackend. By default, the system uses StateBackend, which stores an ephemeral filesystem in LangGraph state for a single thread. Subagents and Context Isolation Deep Agents also includes a built-in task tool for subagent spawning. This tool allows the main agent to create specialized subagents for context isolation, keeping the main thread cleaner while letting the system go deeper on specific subtasks. This is one of the cleaner answers to a common failure mode in agent systems. Once a single thread accumulates too many objectives, tool outputs, and temporary decisions, model quality often drops. Splitting work into subagents reduces that overload and makes the orchestration path easier to debug. Long-Term Memory and LangGraph Integration The Deep Agents GitHub repository also describe long-term memory as a built-in capability. Deep Agents can be extended with persistent memory across threads using LangGraph’s Memory Store, allowing the agent to save and retrieve information from previous conversations. On the implementation side, Deep Agents stays fully inside the LangGraph execution model. The customization docs specify that create_deep_agent(…) returns a CompiledStateGraph. The resulting graph can be used with standard LangGraph features such as streaming, Studio, and checkpointers. Deep Agents is not a parallel abstraction layer that blocks access to runtime features; it is a prebuilt graph with defaults. Deployment Details For deployment, the official quickstart shows a minimal Python setup: install deepagents plus a search provider such as tavily-python, export your model API key and search API key, define a search tool, and then create the agent with create_deep_agent(…) using a tool-calling model. The docs note that Deep Agents requires tool calling support, and the example workflow is to initialize the agent with your tools and system_prompt, then run it with agent.invoke(…). LangChain team also points developers toward LangGraph deployment options for production, which fits because Deep Agents runs on the LangGraph runtime and supports built-in streaming for observing execution. Copy CodeCopiedUse a different Browser # pip install -qU deepagents from deepagents import create_deep_agent def get_weather(city: str) -> str: “””Get weather for a given city.””” return f”It’s always sunny in {city}!” agent = create_deep_agent( tools=[get_weather], system_prompt=”You are a helpful assistant”, ) # Run the agent agent.invoke( {“messages”: [{“role”: “user”, “content”: “what is the weather in sf”}]} ) Key Takeaways Deep Agents is an agent harness built on LangChain and the LangGraph runtime. It includes built-in planning through the write_todos tool for multi-step task decomposition. It uses filesystem tools to manage large context and reduce prompt-window pressure. It can spawn subagents with isolated context using the built-in task tool. It supports persistent memory across threads through LangGraph’s Memory Store. Check out Repo and Docs. Also, feel free to follow us on Twitter and don’t forget to join our 120k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post LangChain Releases Deep Agents: A Structured Runtime for Planning, Memory, and Context Isolation in Multi-Step AI Agents appeared first on MarkTechPost.

LangChain Releases Deep Agents: A Structured Runtime for Planning, Memory, and Context Isolation in Multi-Step AI Agents Read Post »

AI, Committee, 新闻, Uncategorized

Why physical AI is becoming manufacturing’s next advantage

For decades, manufacturers have pursued automation to drive efficiency, reduce costs, and stabilize operations. That approach delivered meaningful gains, but it is no longer enough. Today’s manufacturing leaders face a different challenge: how to grow amid labor constraints, rising complexity, and increasing pressure to innovate faster without sacrificing safety, quality, or trust. The next phase of transformation will not be defined by isolated AI tools or individual robots, but by intelligence that can operate reliably in the physical world. This is where physical AI—intelligence that can sense, reason, and act in the real world—marks a decisive shift. And it is why Microsoft and NVIDIA are working together to help manufacturers move from experimentation to production at industrial scale. The industrial frontier: Intelligence and trust, not just automation Most early AI adoption focused on narrow optimization: automating tasks, improving utilization, and cutting costs. While valuable, that phase often created new friction, including skills gaps, governance concerns, and uncertainty about long‑term impact. Furthermore, the use cases were plentiful but not as strategic. The industrial frontier represents a different approach. Rather than asking how much work machines can replace, frontier manufacturers ask how AI can expand human capability, accelerate innovation, and unlock new forms of value while remaining trustworthy and controllable. Across industries, companies that successfully move into this frontier phase share two non‑negotiables: Intelligence: AI systems must understand how the business actually handles its data, workflows, and institutional knowledge. Trust: As AI begins to act in high‑stakes environments, organizations must retain security, governance, and observability at every layer. Without intelligence, AI becomes generic. Without trust, adoption stalls. Why manufacturing is the proving ground for physical AI Manufacturing is uniquely positioned at the center of this shift. AI is no longer confined to planning or analytics. It is moving into physical execution: coordinating machines, adapting to real‑world variability, and working alongside people on the factory floor. Robotics, autonomous systems, and AI agents must now perceive, reason, and act in dynamic environments. This transition exposes a critical gap. Traditional automation excels at repetition but struggles with adaptability. Human workers bring judgment and context but are constrained by scale. Physical AI closes that gap by enabling human‑led, AI‑operated systems, where people set intent and intelligent systems execute, learn, and improve over time. Humans are essential for scaled success. Microsoft and NVIDIA: Accelerating physical AI at scale Physical AI cannot be delivered through point solutions. It requires agentic-driven, enterprise-grade development, deployment, and operations toolchains and workflows that connect simulation, data, AI models, robotics, and governance into a coherent system. NVIDIA is building the AI infrastructure that makes physical AI possible, including accelerated computing, open models, simulation libraries, and robotics frameworks and blueprints that enable the ecosystem to build autonomous robotics systems that can perceive, reason, plan, and take action in the physical world. Microsoft complements this with a cloud and data platform designed to operate physical AI securely, at scale, and across the enterprise. Together, Microsoft and NVIDIA are enabling manufacturers to move beyond pilots toward production‑ready physical AI systems that can be developed, tested, deployed, and continuously improved across heterogeneous environments spanning the product lifecycle, factory operations, and supply chain. From intelligence to action: Human-agent teams in the factory At the industrial frontier, AI is not a standalone system, but a digital teammate. When AI agents are grounded in the proper operational data, embedded in human workflows, and governed end to end, they can assist with tasks such as: Optimizing production lines in real time Coordinating maintenance and quality decisions Adapting operations to supply or demand disruptions Accelerating engineering and product lifecycle decisions For example, manufacturers are beginning to use simulation‑grounded AI agents to evaluate production changes virtually before deploying them on the factory floor, reducing risk while accelerating decision‑making. Crucially, frontier manufacturers design these systems so humans remain in control. AI executes, monitors, and recommends, while people provide intent, oversight, and judgment. This balance allows organizations to move faster without losing confidence or control. The role of trust in scaling physical AI As physical AI systems scale, trust becomes the limiting factor. Manufacturers must ensure that AI systems are secure, observable, and operating within policy, especially when they influence safety‑critical or mission‑critical processes. Governance cannot be an afterthought; It must be engineered into the platform itself. This is why frontier manufacturers treat trust as a first‑class requirement, pairing innovation with visibility, compliance, and accountability. Only then can physical AI move from promising demonstrations to enterprise‑wide deployment. Why this moment matters—and what’s next The convergence of AI agents, robotics, simulation, and real‑time data marks an inflection point for manufacturing. What was once experimental is becoming operational. What was once siloed is becoming connected. At NVIDIA GTC 2026, Microsoft and NVIDIA will demonstrate how this collaboration supports physical AI systems that manufacturers can deploy today and scale responsibly tomorrow. From simulation‑driven development to real‑world execution, the focus is on helping manufacturers cross the industrial frontier with confidence. For manufacturing leaders, the question is no longer whether physical AI will reshape operations, but how quickly they can adopt it responsibly, at scale, and with trust built in from the start. Discover more with Microsoft at NVIDIA GTC 2026. This content was produced by Microsoft. It was not written by MIT Technology Review’s editorial staff.

Why physical AI is becoming manufacturing’s next advantage Read Post »

AI, Committee, 新闻, Uncategorized

Speak or Stay Silent: Context-Aware Turn-Taking in Multi-Party Dialogue

arXiv:2603.11409v1 Announce Type: cross Abstract: Existing voice AI assistants treat every detected pause as an invitation to speak. This works in dyadic dialogue, but in multi-party settings, where an AI assistant participates alongside multiple speakers, pauses are abundant and ambiguous. An assistant that speaks on every pause becomes disruptive rather than useful. In this work, we formulate context-aware turn-taking: at every detected pause, given the full conversation context, our method decides whether the assistant should speak or stay silent. We introduce a benchmark of over 120K labeled conversations spanning three multi-party corpora. Evaluating eight recent large language models, we find that they consistently fail at context-aware turn-taking under zero-shot prompting. We then propose a supervised fine-tuning approach with reasoning traces, improving balanced accuracy by up to 23 percentage points. Our findings suggest that context-aware turn-taking is not an emergent capability; it must be explicitly trained.

Speak or Stay Silent: Context-Aware Turn-Taking in Multi-Party Dialogue Read Post »

AI, Committee, 新闻, Uncategorized

Measuring Intent Comprehension in LLMs

arXiv:2506.16584v2 Announce Type: replace Abstract: People judge interactions with large language models (LLMs) as successful when outputs match what they want, not what they type. Yet LLMs are trained to predict the next token solely from text input, not underlying intent. Because written language is an imperfect proxy for intent, and correlations between phrasing and desired outcomes can break down in training data, models that rely too heavily on surface cues may respond inconsistently to semantically equivalent prompts. This makes it essential to evaluate whether LLMs can reliably infer user intent-especially in high-stakes settings where robustness and generalization are critical. We introduce a formal framework for assessing intent comprehension in LLMs: whether a model demonstrates robust understanding of user intent by producing consistent outputs across semantically equivalent prompts while differentiating between prompts with distinct intents. Our evaluation approach is based on a variance decomposition of model responses into three components: variability due to user intent, user articulation, and model uncertainty. Models that understand what users want, and are not overly sensitive to textual cues, should attribute most output variance to intent differences, rather than articulation style. Applying this framework across diverse domains, we find that, within the five LLaMA and Gemma models we evaluate, larger models typically assign a greater share of variance to intent, indicating stronger comprehension of intent, although gains are uneven and often modest with increasing model size. These results motivate moving beyond accuracy-only benchmarks toward semantic diagnostics that directly assess whether models understand what users intend.

Measuring Intent Comprehension in LLMs Read Post »

AI, Committee, 新闻, Uncategorized

Google AI Introduces ‘Groundsource’: A New Methodology that Uses Gemini Model to Transform Unstructured Global News into Actionable, Historical Data

Google AI Research team recently released Groundsource, a new methodology that uses Gemini model to extract structured historical data from unstructured public news reports. The project addresses the lack of historical data for rapid-onset natural disasters. Its first output is an open-source dataset containing 2.6 million historical urban flash flood events across more than 150 countries. The Hydro-Meteorological Data Gap Machine learning models for early warning systems (EWS) require extensive historical baselines for training and validation. However, hydro-meteorological hazards like flash floods lack standardized, global observation networks. The Impact of Flash Floods: According to the World Meteorological Organization (WMO), flash floods cause approximately 85% of flood-related fatalities, resulting in over 5,000 deaths annually. Limitations of Existing Data: Satellite-based databases, such as the Global Flood Database (GFD) and the Dartmouth Flood Observatory (DFO), are limited by cloud cover, satellite revisit times, and a bias toward long-lasting events. Scale of the Deficit: The Global Disaster Alert and Coordination System (GDACS) provides an inventory of roughly 10,000 high-impact events. This volume is insufficient for training global-scale predictive models. The Groundsource Methodology To build a larger training corpus, Google’s research team developed a pipeline that processes decades of localized news reports to synthesize a historical baseline. Semantic Parsing with Gemini: The LLM is deployed for entity extraction. It processes unstructured, multilingual text to identify specific hazard events, classify their severity, and filter out irrelevant noise. Geospatial Mapping: The extracted text descriptions of flood locations are integrated with Google Maps APIs to assign precise geographic coordinates and polygonal boundaries to each event. This pipeline successfully converts qualitative journalistic reporting into a highly structured, machine-readable dataset. https://research.google/blog/introducing-groundsource-turning-news-reports-into-data-with-gemini/ Application: Flash Flood Forecasting Historically, Google’s Flood Forecasting Initiative focused on riverine floods, which develop slowly and are easier to track. Flash floods require distinct predictive approaches due to their rapid onset. Using the 2.6-million-record Groundsource dataset, the research team trained a new AI model to predict urban flash flood risks up to 24 hours in advance. Empirical studies note that even a 12-hour lead time can reduce flash flood damage by 60%. These forecasts are now live on Google’s Flood Hub platform. The underlying dataset has been open-sourced to allow the broader data science community to train their own localized predictive models. Key Takeaways LLM-Driven Data Pipeline: Groundsource uses the Gemini model for semantic parsing to extract structured historical disaster data from unstructured, multilingual public news reports. Massive Dataset Generation: The pipeline successfully produced an open-source dataset containing 2.6 million historical urban flash flood records across more than 150 countries. Overcoming Sensor Limitations: This NLP-based approach addresses the historical ‘data desert,’ bypassing the physical constraints of remote sensing (such as cloud cover or satellite revisit times) and the limited volume of existing traditional databases like GDACS. Geospatial Integration: Extracted natural language descriptions of hazard locations are integrated with Google Maps APIs to assign precise geographic coordinates and polygonal boundaries to each event. Predictive Model Deployment: The resulting dataset was utilized to train a new AI model capable of predicting urban flash flood risks up to 24 hours in advance, which is now actively deployed on Google’s Flood Hub platform. Check out Dataset, Pre-Print Paper and Technical details. Also, feel free to follow us on Twitter and don’t forget to join our 120k+ ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. The post Google AI Introduces ‘Groundsource’: A New Methodology that Uses Gemini Model to Transform Unstructured Global News into Actionable, Historical Data appeared first on MarkTechPost.

Google AI Introduces ‘Groundsource’: A New Methodology that Uses Gemini Model to Transform Unstructured Global News into Actionable, Historical Data Read Post »

We use cookies to improve your experience and performance on our website. You can learn more at 隱私權政策 and manage your privacy settings by clicking Settings.

Privacy Preferences

You can choose your cookie settings by turning on/off each type of cookie as you wish, except for essential cookies.

Allow All
Manage Consent Preferences
  • Always Active

Save
zh_CN