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

标签:#m

找到 10843 篇相关文章

开发者

British Columbia, Time Zones, and Postgres

British Columbia has recently made some time zone changes —- but you have a few months until you feel the impact. That gives an opportunity to deep dive into time zones, timestamp storage, and more. submitted by /u/winsletts [link] [留言]

2026-06-17 原文 →
AI 资讯

From Invoice to Owner: A Practitioner's Guide to Request-Level AI Cost Attribution

TL;DR Provider invoices aggregate by model and billing period. They cannot tell you which team, product, or agent caused a cost spike. Request-level AI cost attribution links every API call to structured owner metadata (team, product, environment, trace ID) so investigations take minutes, not days. Three approaches exist: provider dashboard, gateway log enrichment, and application trace attribution. They differ sharply in setup cost and query granularity. Gateway log enrichment is the highest-leverage first step for most teams. It requires no changes to application code and covers all traffic behind the gateway. Real example: a platform team at a 60-person AI company discovered that 31% of their $18k/month spend came from a misconfigured retry loop in a background job, identified in under 20 minutes once request-level logs were searchable. Why Your Invoice Is Lying to You Your OpenAI invoice for last month shows $22,400. Your Anthropic invoice shows $6,800. Total: $29,200. Your CFO wants to know which business unit owns each line. You forward the invoices to your finance partner, who forwards them to three engineering managers, who reply with estimates that sum to $24,000 and do not match any real allocation. This is the standard state of LLM spend governance at companies between $5k and $50k per month in AI API costs. The invoices arrive, the spend is real, and attribution is a spreadsheet exercise done with guesses. The problem is structural. Provider billing aggregates by model and by billing period. It has no concept of your internal ownership model, your product boundaries, your tenant hierarchy, or your agent topology. A single gpt-4o line in your invoice might represent spend from a customer-facing chat feature, an internal summarization service, a nightly batch job, and three developers running experiments against production endpoints. You get one number. You have four or more owners. Request-level AI cost attribution is the practice of enriching every API c

2026-06-16 原文 →
AI 资讯

The Reference Check Questions Nobody Asks AI Vendors

I have done this process wrong more times than I would like to admit. You call the references the vendor sends you. Three customers, all happy, all articulate, all saying roughly the same things. You hang up feeling good. You sign. Six months later you are dealing with a support team that responds every 72 hours and a renewal quote that is 40% higher than year one. The reference check told you nothing useful. Not because the customers lied. Because you asked the wrong questions. Here is what I ask now. "How many people at the vendor have you spoken to in the last six months?" One contact who handles everything and is sometimes slow — that tells you something. A team of people across sales, technical support, and leadership — that tells you something different. Enterprise AI vendors with thin account teams show their limitations at exactly the moment you need them most: when something breaks at the worst possible time. "Tell me about the last time something broke in production." Not IF something broke. Something always breaks. I want to know what happened next. Did the vendor show up? Did they communicate clearly while the issue was live? Did they follow up after closing the ticket, or did they close it and disappear? The answer to this question tells me more about a vendor than any product demo. "What do you know now that you wish you had known before signing?" This question works because it is framed as advice, not criticism. Reference customers who would never say "this product has problems" will happily answer this one honestly. Listen for anything about pricing surprises, scope limitations that only appeared after deployment, or feature gaps the sales team glossed over. "When you renewed, did you evaluate alternatives?" Renewal is the honest signal. A customer who renewed without looking elsewhere is genuinely satisfied. A customer who looked at three other options and came back is someone who chose this vendor over real competition. A customer who is approachin

2026-06-16 原文 →
AI 资讯

Fast Automatic ML Hyperparameter tuning Using Optuna (w. MLflow model registry and IRIS DB)

This article presents a straightforward approach to automatically and efficiently tune hyperparameters for machine learning models using Optuna as the optimisation framework. We explore how to use both Optuna’s native storage options and InterSystems IRIS as a database backend to track the progress of hyperparameter searches. We also show how MLflow can be used to monitor experiments and manage models through its tracking and model registry UI. This article is based on this Kaggle Notebook , which you can run and directly edit yourself. When training ML models, the choice of hyperparameters can strongly influence performance. They are not the only factor, but they can significantly affect both convergence and generalisation. Tuning hyperparameters manually takes a lot of effort. This is especially true because hyperparameters interact with each other, so tuning them independently is usually not enough. For example, higher regularisation may require a lower learning rate for more stable optimization. A more complex model may require stronger regularization to avoid overfitting, but at the same time, a very small learning rate on a complex model can make learning too slow. Optuna is an MIT-licensed open source library, which allows commercial use, that automates hyperparameter search for ML models developed with the most popular frameworks such as scikit-learn, PyTorch, TensorFlow, and LightGBM. It works by defining a search space and an objective metric to either minimize or maximize. Optuna then explores the search space efficiently to find well-performing configurations. Here we use Optuna to tune a LightGBM model on a dummy dataset and show how to scale the search using shared database storage. We will also use MLflow for experiment tracking and model registry, and IRIS DB as a possible Optuna storage backend for concurrent studies. We will use the California Housing dataset, commonly used in ML examples, to populate IRIS tables and run the tuning workflow. Note:

2026-06-16 原文 →