标签：#machine

The substitution is three lines of client code. The part that costs an afternoon is that the most powerful-looking Azure OpenAI role is explicitly unable to make an inference call. What a key cannot do An Azure OpenAI resource key is a bearer secret with no identity, no expiry and no scope narrower than the whole resource. Every deployment on the resource is reachable with it, every caller looks identical in the audit trail, and rotating it means coordinating every consumer at once. A managed identity replaces it with a short-lived Microsoft Entra ID token issued to a specific workload identity. The credential is never stored, the token expires on its own, and the grant is a role assignment you can scope to a resource group, a resource, or nothing at all. Combined with a private endpoint, it removes the two things an attacker needs — the network path and the static secret. The role that permits inference Microsoft documents four roles for Azure OpenAI, and the summary table on its RBAC article makes one distinction that is worth reading twice: Cognitive Services OpenAI User — can make inference API calls with Microsoft Entra ID. Cannot read or regenerate keys, cannot create deployments, cannot create guardrails. Cognitive Services OpenAI Contributor — everything the User role has, plus creating and editing deployments, fine-tuning and stored completions. Cognitive Services Contributor — can create resources, read and regenerate keys, and create customised guardrails, but is listed as unable to make inference API calls with Microsoft Entra ID . Cognitive Services Usages Reader — quota visibility only, and only at subscription scope. That third entry is the trap. Granting an application the Contributor role because it sounds broader produces an application that can rotate the keys it is no longer using and cannot call the model at all. The role you want for a workload is Cognitive Services OpenAI User , and nothing else. Microsoft also notes that subscription-level Ow

Global Standard is the default for a reason and the reason is not performance. It is a routing behaviour with quota consequences, and both halves surprise people who chose it because it was preselected. What the type does The SKU name in code is GlobalStandard . Microsoft describes it as using Azure’s global infrastructure to dynamically route traffic to available datacenters, and lists three concrete consequences: it provides the highest default quota , it eliminates the need to load balance across multiple resources for throughput purposes, and it is the type new models arrive on first. The launch order is documented and it is a planning input. New deployment types become available Global first, then Data Zone, then single region — and single-region types arrive last, have no guaranteed availability date , and depend on capacity that frees up as older models retire. A design that requires a model pinned to one region is a design that may wait indefinitely for that model. Microsoft, Understanding deployment types in Foundry Models . Global Standard also supports priority processing on a pay-as-you-go basis, which is a separate rate for faster responses on the same deployment. Routing and data residency The distinction Microsoft draws is between data at rest and data in flight, and only the second one varies by deployment type. Data stored at rest remains in the designated Azure geography for every type. Inferencing data is processed differently: Global types: may be processed in any Azure region . Data Zone types: processed only within the Microsoft-specified data zone — US, EU or Asia Pacific. The EU zone follows the Azure EU Data Boundary, which can include EFTA countries such as Norway and Switzerland in addition to member states. Standard (single region): processed in the deployment region. “Any Azure region” is the phrase to take to a compliance conversation before you deploy rather than after. Microsoft also notes it can add regions to a data zone without pri

Everyone is building AI memory systems. But how do we know which ones actually work? As AI agents...

On August 12, 2026, xAI released Grok 4.6, the successor to Grok 4.5 that shipped in July. The positioning is different from the last release. This is not pitched as a raw intelligence jump. It is a model built for long-running agents and ambitious interactive and visual work: researching a topic across many steps, working through a codebase, or turning a rough product idea into a polished first version. The headline claim is measured. xAI says Grok 4.6 matches GPT-5.6 Sol on the Artificial Analysis Intelligence Index, a composite of nine benchmarks. Across the rest of the published evals it trades leads with GPT-5.6 Sol and Anthropic's Fable 5, winning some and losing others. Pricing starts at $2 per million input tokens and $6 per million output tokens, with a faster variant at double that. I build AI agents with Spring AI for a living, so the agentic framing is what I read first. Here is what the release actually contains, where the numbers hold up, and what it signals for the frontier race. What's new in Grok 4.6 The official announcement is short on scale and long on training. It never states a parameter count. Earlier reports disagreed: some pointed to the same 1.5T V9 base as Grok 4.5 with heavy post-training, others to a larger 2T model. Either way, xAI's framing is that this release is about the training recipe, not the model size. What the company did describe: A longer supplemental training run than Grok 4.5, with curated model-generated data for reasoning and advanced technical concepts, high-quality engineering data, and an improved optimizer and training recipe. A supervised fine-tuning stage where Grok 4.5 itself regenerated the SFT trajectories across reasoning efforts, agent harnesses, and domains like STEM, software engineering, and knowledge work. Problematic traces were filtered out with model-based checks. Reinforcement learning across a wide range of agentic tasks: general coding, knowledge work, and domain-specific environments for kernel opti

Imagine working as a Data Analyst in a healthcare Non-Governmental Organization (NGO) implementing HIV and AIDS programmes across several communities. The organization has limited resources. There may not be enough funding, healthcare workers, testing kits, transport, outreach teams, or community programmes to serve every community at the same intensity. This creates an important question: How can we use data and machine learning to direct limited programme resources to communities with the greatest need? This is where Machine Learning (ML) can become valuable. Rather than distributing resources equally across all communities, an NGO can use historical programme data to identify communities experiencing greater HIV-related service gaps or higher levels of need. Resources can then be prioritized based on evidence. What Is Machine Learning? Machine Learning is a branch of Artificial Intelligence that enables computers to learn patterns from data and use those patterns to make predictions or support decisions. Instead of manually creating rules for every situation, you provide the algorithm with historical data and allow it to identify relationships within that data. For example, the NGO could have this information about different communities: Community HIV Testing Coverage ART Coverage Missed Appointments Outreach Activities Community A 85% 90% 5% High Community B 52% 61% 25% Low Community C 70% 75% 15% Medium Community D 40% 55% 32% Low Looking at this data, Community D appears to have greater programme gaps than Community A. However, in a real programme, the decision should not be based on one indicator alone. Machine learning can analyse many variables simultaneously to identify communities that may require greater attention. Why Resource Allocation Matters in HIV Programmes HIV programmes operate in environments where resources are often limited. An NGO may have: A limited number of community health workers A fixed outreach budget Limited HIV testing supplies Limi

Classic Machine Learning Through the Eyes of an SRE — Part 4 When a computation is too hard, don't compute harder. Change coordinates until it becomes easy. Every engineer has made this move. Pick the right data structure and the impossible query goes O(1). Re-index the table and the report that took an hour takes a second. Move the problem into a space where it's trivial, solve it there, come back. That's the kernel trick. SVM's famous move isn't building a curvy model — it's finding a FLAT cut in a transformed space, which corresponds to a curved boundary back in your original features. The separator stays linear in the transformed space. The space did the work. And here's the part that makes it a trick rather than just a projection: the data never actually goes up there. The optimization only ever needs inner products between pairs of points, and a kernel function computes what that inner product would be in the high-dimensional space, directly from the original coordinates. You get the geometry of a space you never built. Some kernels correspond to infinitely many dimensions, which would otherwise be an awkward amount of memory to allocate. The bet it makes SVM bets that the most ROBUST boundary is the one with the widest margin — maximum distance from the nearest points on each side. And here's the part that rewired me: only those nearest points matter. They're the support vectors. The non-support-vector points don't directly determine the final boundary at all. Compare that to the forest, which averages over EVERYTHING. SVM is the opposite extreme: the borderline cases that become support vectors define the decision boundary. In delivery-risk terms — the projects that teach you where the line is aren't the disasters or the easy wins. They're the borderline ones that barely breached and barely survived. SVM formalizes that. Everything old returns After trees and forests threw away gradient descent, SVM brings some of the regression toolkit back: an explicit los

Hello, I wanted to share the work my colleague and I have been doing, which has just been published in Software X journal . We developed a Rust-based implementation of Random Forest. It has bindings for both Python and R . Fru is highly optimized, offering competitive runtime performance and better scalability than popular implementations on these platforms. For Python, Fru outperforms the scikit-learn implementation by several factors, and in some scenarios it can be hundreds of times faster. In R, Fru is typically a few dozen percent faster than the ranger package, though the speedup can reach several times faster depending on the use case. The model also includes a novel implementation of permutation importance, which provides an additional performance boost. Thanks to its layered design, we were able to easily create bindings for both Python and R. In Python, we use Arrow PyCapsule, which allows the model to work seamlessly with any compatible library, including pandas, polars, pyarrow, and many others. paper R package Python package submitted by /u/kpiwonski [link] [留言]

Obviously nobody needs a transformer that's good at multiplication. I wanted to know whether a stock transformer could do exact arithmetic if I chose its weights directly. I implemented the grade-school algorithm as a computation graph and compiled it into an ordinary Phi-3 Hugging Face checkpoint using Torchwright, a compiler I wrote. No training. The three-digit calculator gets all 3,000,000 supported expressions right. I've published checkpoints to Hugging Face that support up to 12 digit x 12 digit multiplication. For fun, I also disabled reasoning and tested six frontier models. Accuracy falls off a cliff as the numbers get longer; at seven digits, five scored 0/500. Mine stays at 100%, although it has the considerable advantage that I put the multiplication algorithm directly into its weights. I ended up building four versions: grade-school, hardware-style, scratchpad, and brute-force memorization. They compute the same function while spending layers, width, generated tokens, and parameters very differently. Write-up: https://ood.dev/posts/calculator/ Repo: https://github.com/physicsrob/torchwright Checkpoint: https://huggingface.co/physicsrob/torchwright-calculator-simple-max-digits-3 submitted by /u/notforrob [link] [留言]

Hi, I would like to file a complaint about an accepted and published CVPR 2026 paper that its main contribution is a dataset but it was never released, and honestly I don’t know who to contact. The dataset was never released prior to the conference, or during the conference or after the conference. I personally feel there was a lack of proper checking that the dataset was gonna be available before the conference since this is a requirement. I’ve tried contacting the authors without any success (which tbh I wouldn’t even need to because it has to be released anyways). The authors even point a GitHub link in the paper but the repo is empty (and it was always empty). submitted by /u/ElPelana [link] [留言]

I spent six months trying to make v2 work. Then I built a small thing on the side that worked better than v2 ever had. The decision that followed wasn't whether to change architectures. It was how fast. Part 22 ended on a pattern I'd been seeing without quite seeing. PropertyCircuit and RelationalCircuit had each landed a capability the brain layer couldn't reach, at a fraction of the parameter count, in seconds of training, with zero impact on anything else in the system. The implications sat in the session notes for a couple of days while I ran the numbers in different ways trying to find a reason they didn't mean what they obviously meant. I couldn't find one. The pattern was real. The reason it was real was structural. A monolith optimized for one thing tends to be worse at every other thing. A small circuit optimized for one thing tends to be better at that one thing than any general-purpose model would be, and the cost of building it is small enough that you can build a lot of them. I sat down at my computer staring at the screen, running the design through my mind. I had been doing the engineering work in a collaboration for months. I held the design vision and the final say on what shipped. The conversation about v3 had to be the two of us together, because nether one of us would have noticed the pattern alone. The conversation took most of a day. The output was a file in the v3 repo called TRUTH.md with ten rules in it. Two-way agreement required for any architectural change. No regex patterns in dispatch unless they used what Origin already understood. Sandbox before shipping. Trace impact before shipping. Honesty floor: Origin only says what it knows. Modularity all the way down. A few others. The rules weren't aspirational. They were the patterns we'd already learned the hard way over fifteen blog posts of failures. We'd just never written them down in one place where they could constrain the next decision. The architecture that came out of the conversat

Today the most important factor in AI is cost. My idea is to split ML models inference (closed ones, proprietary) across server and edge computing on clients, and I would like to hear what do you think about this thing. For example some of model weights/modules would be on client, and some on the server side (where user has no access to them). This could potentially un-load some processing from datacenters, moving part of the cost to the client hardware. Probbably the most important question here will be how to achieve this - and I believe one hypothetical option will be to train like two separate models - client model and server model, and they will communicate through tensors/latent representations across network protocol. Secondly such split of server side and client side model ends, can provide later some beneficial outcomes I hope (because in between "talk" protocol can be maybe kind of standarized one in some future development, but this is only more like brainstorm now). Such split might not only be one-to-one, but one-to-many, many-to-many etc. What do you think about this idea? submitted by /u/komorra [link] [留言]

Say you want to swap out your embedding models, for instance from ADA to Titan. Are these embedding models comparable? How do similarity score ranges compare? Where to put a threshold for minimum match when doing retrieval? Or more from a research point of view how can we relate and fundamentally understand these embedding spaces better? This is what we aim to solve with Synthetic Query Probing, a fancy name for essentially (and intentionally) a very simple approach: embedding spaces are not directly comparable by definition, so compare similarity spaces instead, similarity match scores for pairs of content (synthetic question, chunk for instance) across multiple embedding models. For example, similarity scores of Titan models of different dimensionalities are related, whereas the relation between Titan and Ada scores is non-linear, with different ranges, see figure. https://preview.redd.it/eauhd4hdyiih1.png?width=4767&format=png&auto=webp&s=e424c836c48962928d9505cf747e7cd9fb0b719f See https://arxiv.org/pdf/2608.05857 , Marcin Rozmus and Peter van der Putten. Similarity Spaces across Embedding Models with Synthetic Query Probing. Discovery Science 2026, October 5-9, 2026, Mainz, Germany submitted by /u/pppeer [link] [留言]

We’ve all been there: hunched over a keyboard at 3 AM, neck craned forward like a turtle, debugging a race condition. "Tech neck" isn't just a meme; it’s a productivity killer. As developers, our spine is our most underrated hardware. In this tutorial, we are going to build a Real-Time Spine Posture Monitor . We will leverage real-time human pose estimation and MediaPipe Python libraries to track your posture via your webcam. By the end of this guide, you'll have a system that detects when you're slouching and sends a system notification to keep your ergonomics in check. This project is perfect for those looking into OpenCV computer vision and developer ergonomics solutions. The Architecture 🏗️ The logic is straightforward: we capture video frames, process them through a pre-trained neural network to find body landmarks, and apply some basic geometry to determine if your posture is healthy. graph TD A[Webcam Feed] --> B[OpenCV Frame Processing] B --> C[MediaPipe Pose Landmark Detection] C --> D{Extract Shoulder & Ear Coordinates} D --> E[Calculate Neck Inclination Angle] E --> F{Angle > Threshold?} F -- Yes --> G[Trigger System Notification] F -- No --> H[Continue Monitoring] G --> B H --> B Prerequisites 🛠️ Before we dive into the code, ensure you have the following installed: Python 3.9+ MediaPipe : Google’s framework for cross-platform ML. OpenCV : For video stream handling. PyObjC : (For macOS) to trigger native system alerts. pip install mediapipe opencv-python pyobjc Step 1: Initialize the Pose Engine MediaPipe makes pose estimation incredibly easy. We’ll use the Pose solution, which provides 33 3D landmarks for the human body. import cv2 import mediapipe as mp import math # Initialize MediaPipe Pose mp_pose = mp . solutions . pose pose = mp_pose . Pose ( static_image_mode = False , model_complexity = 1 , enable_segmentation = False , min_detection_confidence = 0.5 ) mp_drawing = mp . solutions . drawing_utils Step 2: Calculating the "Slouch" Angle 📐 To detect

I spent two weeks building a computer vision component to estimate how full a plastic container is from drone imagery. Translucent white containers, whitish chemical product inside, shot obliquely from a drone during field inspections. The headline number looked good: mean absolute error of 0.055 on fill fraction, Pearson correlation of 0.97. Then I audited my own evaluation and found that 38 of my 46 test crops had the same physical container sitting in the training set. The arithmetic was fine. The problem was the sentence I had wrapped around it: I was presenting 0.055 as the error on containers the model had never seen before. What makes this worth writing about is that I had the guardrail in place from day one, and it failed three separate times for three unrelated reasons. Each one is easy to reproduce in any project that trains on frames extracted from video. Why grouping matters here at all A drone flies over a site and captures a burst. In my case, 12 frames over 12 seconds. The same physical container appears in every frame of that burst, from slightly different angles and distances. If you shuffle those crops randomly into train and test, you are asking the model to recognize a container it has already memorized. The metric you get back describes interpolation between frames of one burst. It says nothing about a container the model has never seen. This is the most common failure in applied ML and everyone knows about it. Which is exactly why the next part is worth reading. The guardrail I wrote on day one My dataset module reads the grouping column from config and does not offer a random option at all: split : group_column : skid_id # never random The code path for a random split does not exist. You cannot pass a flag to get one. I wrote it that way on purpose, on the first day, before there was any data to split. I still leaked. Three times. Leak 1: the group column held the wrong ID group_column was set to skid_id , which is what you want. Group by phys

Hi everyone! 👋 I recently developed LoanAI , a real-time credit risk assessment platform that predicts loan default probabilities using machine learning models. Key Features Instant Risk Scoring: Real-time credit risk assessment for loan applicants. Explainable AI: Transparent prediction logic for financial decision-making. Clean UI: Built with Flask, Bootstrap 5, and Python. Live Demo Check out the live web app here: LoanAI Web Application I would love to hear your feedback on the project structure and prediction engine!

I keep seeing the same local LLM sizing mistake: "The model file is smaller than my GPU, so it should fit." That is only the first check. A 24 GB GPU does not give your model a clean 24 GB memory budget. The display stack, runtime, temporary buffers, model weights, and KV cache all compete for the same space. Here is the worksheet I use before I download a model or rent a GPU. 1. Start with the weight floor The simplest weight estimate is: weight_memory_gib = parameters * bits_per_parameter / 8 / 1024^3 For a simple 4-bit estimate: Model size Weight floor 7B 3.3 GiB 13B 6.1 GiB 70B 32.6 GiB These are floors, not promises. Real quantized files can also contain scales, metadata, and layers stored at higher precision. If you know the exact checkpoint size, use that instead of the simple bits-per-parameter estimate. Also use total parameters for a sparse mixture-of-experts model unless your runtime really offloads inactive experts. Active parameters describe compute per token. They do not automatically describe how many weights must be stored. 2. Reduce the physical capacity to a usable budget I normally start with 90 percent usable VRAM for planning: usable_vram = physical_vram * usable_fraction For a 24 GB card: 24 * 0.90 = 21.6 GiB usable The exact reserve depends on the OS, display use, driver, runtime, graph capture, allocator behavior, and other processes. The important part is to stop treating the number on the box as fully available. 3. Add the KV cache The KV cache is where context length and concurrency become expensive. A useful planning formula is: kv_cache_bytes = 2 * layers * kv_heads * head_dimension * context_tokens * concurrent_sequences * bytes_per_kv_value The factor of two stores keys and values. Take a model with: 32 layers 8 KV heads 128 dimensions per head 8,192 cached tokens 1 concurrent sequence 16-bit KV values, which use 2 bytes The KV cache is about 1 GiB. Raise the context to 32,768 tokens and it becomes about 4 GiB. Keep that context and ru

Originally published on tamiz.pro . The promise of AI-assisted coding is seductive: velocity, reduced boilerplate, and the elimination of context-switching fatigue. Tools like GitHub Copilot, Cursor, and various IDE plugins have transitioned from novelty to necessity in many modern codebases. However, a subtle but dangerous drift is occurring in our development practices. We are witnessing a shift from "writing code" to "reviewing AI output," and in doing so, we are ceding our most valuable asset as engineers: agency. When we stop asking how a system works and start accepting what the machine says it does, we degrade our ability to debug, architect, and innovate. This article argues that maintaining developer agency in the age of automation is not just a philosophical stance, but a critical engineering requirement for building robust, secure, and maintainable systems. The Illusion of Competence The primary threat to developer agency is the illusion of competence. When an AI generates a complex React component, a sophisticated regex, or a multi-join SQL query in seconds, it creates a cognitive shortcut. The human mind, prone to efficiency, often skips the deep verification step because the output "looks right." This is known in psychology as the fluency heuristic—the ease with which information is processed is mistaken for its truthfulness. Consider the following scenario. You are tasked with implementing a rate-limiting middleware for an API endpoint. Instead of reviewing the existing express-rate-limit library or writing a simple in-memory counter, you ask your AI assistant to "create a custom rate limiter using Redis." It provides a snippet using ioredis with a sliding window algorithm. The code compiles. It runs in your local environment. You merge the PR. Three months later, under load, your Redis connection pool exhausts. The AI-generated code did not handle connection errors gracefully, nor did it account for the latency spikes introduced by the network round-

submitted by /u/katxwoods [link] [留言]

submitted by /u/ImaginaryRea1ity [link] [留言]

Reasoning alone cannot predict the chaotic physical world. Without a sensory and motor interface to reality, non-physical AI will not deliver the scientific and technological breakthroughs we expect. submitted by /u/dontkry4me [link] [留言]