标签：#learning

If your Azure Pipelines eval gate runs on pushes to main but never on a pull request, the YAML is not the problem. Microsoft’s documentation is explicit: for an Azure Repos Git repository you cannot configure a PR trigger in the YAML file, and the functionality is implemented by a branch policy instead. Why your pr trigger does nothing The pr: key exists in the Azure Pipelines YAML schema, and it works — for GitHub and Bitbucket Cloud repositories. For Azure Repos Git it is inert. The Azure Repos Git documentation states that pull request triggers are implemented using branch policies, and that to enable PR validation you configure the Build validation policy on the target branch. A pr: block in the file is not an error and produces no warning; it simply never causes a run. Two related things surprise people once the policy exists. Draft pull requests do not trigger a pipeline even with a branch policy configured, so a gate that seems not to run may be running against a draft. And you must be a project administrator of the project to configure validation builds at all, which is why this is often the step that a developer cannot complete themselves. This is a product behaviour rather than a version detail, but it is the kind of thing that changes. Check the Azure Repos Git page in Microsoft’s Azure Pipelines documentation before assuming it still holds. The pipeline A single-stage pipeline is enough. The CI trigger below covers pushes; the pull request path comes from the policy in the next section, and no pr: key appears at all because on Azure Repos it would only be misleading to a reader. trigger : branches : include : - main paths : exclude : - docs/* pool : vmImage : ubuntu-latest variables : - group : llm-eval-keys - name : EVAL_MODEL value : gpt-4.1-mini-2025-04-14 steps : - task : UsePythonVersion@0 inputs : versionSpec : ' 3.12' - script : pip install -r evals/requirements.txt displayName : Install eval dependencies - script : | python -m evals.run \ --cases

HTTP 429 from Azure OpenAI is four different problems sharing one status code. Three of them are fixed by backing off and one is not, and the response headers distinguish them in about a line of code. Most teams skip that line and file a quota increase for a condition that would have cleared on its own. The error The SDK surfaces it as a rate-limit error — openai.RateLimitError in Python, a RequestFailedException with Status == 429 in .NET. The message text is the first discriminator, and Microsoft documents the indicator phrases rather than a single fixed string: "Requests to … have been limited" or "Rate limit is exceeded" "The service is temporarily unable to process your request" or "System is experiencing high demand" Those two groups mean opposite things. The first is your allocation; the second is Azure’s capacity. Log the message body on every 429 — without it you are guessing. Microsoft, Manage Azure OpenAI quota . Four causes wearing one status code Rate limit exceeded. Your traffic genuinely passed the deployment’s TPM or RPM allocation. Remedy: raise the deployment’s TPM, rebalance quota from an underused deployment, or request an increase. System capacity throttling. Backend capacity is constrained. Documented as often transient. Remedy: retry after the delay the service gives you. A quota increase does nothing here. Temporary rate limit adjustment. The one worth knowing about. Standard and Global Standard deployments share a resource pool across customers, and Microsoft documents that when demand approaches capacity limits the system may temporarily reduce your deployment’s effective rate limit to keep the pool reliable. Your configured quota has not changed. The adjustment typically resolves within a few hours. Token budget consumed by parameters. The rate-limit calculation includes max_tokens and the prompt estimate, not the tokens actually generated. A request with a large max_tokens spends that budget whether or not it uses it. Two more mechanics e

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

Distributed Tracing: Following a Request Across Microservices A practical guide to distributed tracing as an architectural discipline — why single-service logging and metrics stop being sufficient once a request crosses many services, how a trace actually reconstructs a request's journey, trace analysis techniques for diagnosing latency and failures, and the specific propagation challenges microservice systems built from this series' REST, gRPC, and messaging guides need to solve. Table of Contents Introduction The Problem Distributed Tracing Solves Anatomy of a Distributed Trace Propagation Across Every Boundary a Request Crosses The Span Tree as a Diagnostic Tool Root Cause Analysis Using Traces Service Maps and Dependency Discovery Latency Analysis Patterns Sampling Strategy for Production Systems Tracing Across Synchronous and Asynchronous Boundaries Tracing Third-Party and Uninstrumented Dependencies Trace-Driven Testing and SLOs Common Pitfalls Quick Reference Table Conclusion Introduction Distributed tracing is the practice of reconstructing a single logical request's complete journey as it travels across every service, database call, and message it touches in a microservice system — not just observing one service in isolation, but stitching together a coherent, end-to-end picture of what actually happened, in what order, and how long each part took. This guide builds directly on this series' OpenTelemetry guide (which covers the mechanics of spans, trace context, and instrumentation) to focus specifically on distributed tracing as an architectural discipline: why it becomes necessary the moment a system splits into multiple services, and how to actually use traces to diagnose real production problems. Trace: "Checkout" (poor total latency: 1,840ms) ├── API Gateway (5ms) ├── OrderService.PlaceOrder (1,820ms) ← the vast majority of the time is HERE │ ├── SQL INSERT (12ms) │ ├── gRPC call to InventoryService (45ms) │ └── HTTP call to PaymentService (1,740ms) ←

The next evolution of software developers: from implementation to intent, orchestration, and...

Certification prep often stops at notes and multiple-choice questions. Copilot Studio makes more sense once you actually build something. So I added a free AB-620 hands-on lab to Examplar. It covers creating an agent, writing clear instructions, testing in-scope and out-of-scope prompts, publishing it, and cleaning up afterwards. Each step includes something learners can check before moving on. The public Preview also has 25 original practice questions. No exam dumps. Examplar is my independent, open-source side project. The Preview and lab are free, and the page also links to optional paid packs. Try the free lab: https://examplar.app/exams/ab620/#labs-h Blunt feedback is welcome. Which hands-on scenario should I add next?

Most of what I write about here has something to do with software: systems, architecture, tools, failures, and the occasional attempt to understand why something that looked perfectly stable suddenly isn’t. This one is different. Over the past few months, several of the things I considered stable parts of my life have either disappeared or started to move at roughly the same time. Not all of them are technical problems. In fact, most of them cannot be fixed with a better abstraction, another test, or a carefully planned migration. Still, I noticed that I kept thinking about what was happening in the language I know best: systems, dependencies, redundancy, cascading failures, architecture and rebuilding. So this is not really a software article. But it might be an engineer’s way of thinking about what happens when the system in question is your own life. What happens when life does not collapse all at once, but loses its structural support one pillar at a time? There are things in life that we rarely think about as long as they work. A relationship, a career, a home, family, friendships, health, plans for the future. They form the structure around us so naturally that after a while we stop seeing them as separate things. Together, they simply become what we call my life. It is only when one of them disappears that we notice how much weight it was carrying. When that happens, the first reaction is usually not to question the whole structure. We compensate. If a relationship ends, work suddenly becomes more important. It provides routine, purpose, people, problems to solve and a reason to get up in the morning. If work becomes difficult, perhaps home and family become the safe place instead. If the future becomes uncertain, familiar routines keep the present predictable. In other words, we redistribute the load. As a software engineer, I cannot help seeing a familiar pattern in this. We design systems with the assumption that components will fail. A resilient system is

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

Okay Okay, I've used the Rust book online and W3 schools mostly to learn most of what I know. Plus a video or two, but I can't focus on them as of well. Alright, first time putting this to text, but I'll try and explain the concepts, how I myself understand them. From Ch 3 of the Rust book. So in CH 3 it essentially focuses on variables )your x's, y's etc. etc.( and how variables in rust are by def not able to changed, "immutable" by the book. The gist of why is that it guarantees the variable isn't changed when it's not supposed to be or by another function. It also just serves like a safety blanket of sorts, say if you were to have a huge program. You use "let x = 5" you'll know that x = 5 EVERYWHERE. It won't change because the program won't run, you won't even get past the compiler if you try and change the value without saying it can change. This helps in stopping bugs from cropping up, specially since it's how malactors get in. helps debugging by knowing what can and can't flip a bit. Plus if you're building robust code, less stuff changing is better, cuz less stuff fails.. Like a car. fn main () { let x = 5 ; x = 20294 ; // you can't change this, it'll show as an error since you "x" isn't "mut" mutable, or changeable. } simple, right? Roast me if wrong. 08.10.26 -Tyr

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] [留言]

From Learning to Teaching: Building Bitcoin Tools in Rust Susan Githaiga Susan Githaiga Susan Githaiga Follow Aug 10 From Learning to Teaching: Building Bitcoin Tools in Rust # rust # bitcoin # opensource # buidl4africa 1 reaction Add Comment 3 min read