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

标签:#ia

找到 1767 篇相关文章

AI 资讯

'"An LLM and a harness": Nvidia''s simple thesis on what agents actually are'

Nvidia's Nader Khalil — Director of Developer Technologies and co-founder of Brev.dev, acquired by Nvidia two years ago — sat down with The New Stack to talk agents, OpenClaw, and where enterprise AI is heading. His opening line is worth keeping: "An agent is an LLM and a harness. And if you think about that, it involves two things. It involves the loop and the LLM… Each loop should take us closer to our goal." That's not a complicated definition. It's also exactly right — and the fact that Nvidia's internal framing lands here matters more than the quote itself. What actually happened Nvidia has full-time OpenClaw contributors. Khalil: "We have a couple of developers at the company that contribute to OpenClaw full time." That's a real commitment, not a press-release mention. NemoClaw is their enterprise blueprint — a reference architecture for running OpenClaw (and Hermes) in production, with GPU routing, security policies, and a runtime called OpenShell. Khalil traces the harness evolution directly: from ChatGPT's system prompts → memory → file context → Cursor → Claude Code. All of it is harness, not model. The model is constant; the harness is where the product lives. On OpenClaw's PR backlog: "It got more stars than Linux in months… so I think you're gonna see a mountain of PRs." Their response — roll up their sleeves and start merging. Why this framing matters Nvidia makes money when AI compute scales. For that to happen, agents need to work reliably in enterprise environments — and the harness is the reliability layer. Their NemoClaw blueprints aren't a product play; they're an enablement play. Enterprise teams get a reference architecture that works on Nvidia silicon. Nvidia gets demand for the GPUs underneath. It's the CUDA X model applied to agentic AI. The microwave analogy Khalil uses is useful: "when it's your microwave at home, you just go 'Boop, boop. Done.'" Every enterprise will build specialized agents tuned to their domain — CrowdStrike, Cadence, P

2026-06-22 原文 →
AI 资讯

Query ধীর গতিতে চলছে, কিভাবে খুঁজে বের করবেন সমস্যাটা? (পর্ব ৩)

আমার colleague এখন প্ল্যান দেখতে পারছে। Scan types বুঝতে পারছে। Join types বুঝতে পারছে। Estimate আর actual এর gap দেখতে পারছে। BUFFERS ও দেখছে। কিন্তু সে প্রশ্ন করল। এসব দেখে কি করব? Step by step কোন পথে যাব? আমি বললাম। পাঁচটা step আছে। অর্ডার অনুযায়ী। পর্ব ২ এ আমি বলেছিলাম scan types, join types, estimate আর actual এর gap। BUFFERS কি। এবার আসি সমাধান এ। Diagnostic Workflow আপনার কাছে একটা slow query এসেছে। কিভাবে debug করবেন? এই পাঁচটা প্রশ্ন করুন অর্ডার অনুযায়ী। ৯০% slow query প্রথম বা দ্বিতীয় ধাপেই solve হয়ে যায়। ১. Deepest Seq Scan দেখুন Table বড় কি না? Filter selective কি না? Missing index থাকলে add করুন। আজই শুরু করুন যখন একটা Seq Scan দেখবেন big table এ, প্রথমে WHERE clause টা check করুন। Selective কি না? ৫% এর কম row return হওয়ার কথা? যদি তাই হয়, index missing। CREATE INDEX idx_name ON table(column) run করুন। ২. Join types দেখুন কোনো Nested Loop আছে কিন্তু দুই পাশেই বড় table? Hash Join force করুন বা ডান পাশে index add করুন। আজই শুরু করুন Nested Loop দেখলে ডান পাশের table এ index check করুন। যদি না থাকে, create করুন। Index থাকা সত্ত্বেও planner Nested Loop use করছে? SET enable_nestloop = off temporarily disable করে দেখুন। Hash Join আসবে কি না। ৩. Row estimates দেখুন Estimate vs actual ১০x এর বেশি difference? ANALYZE table দিন বা predicate rewrite করুন। আজই শুরু করুন rows=1 estimate কিন্তু rows=100000 actual দেখলে ANALYZE tablename run করুন। Statistics refresh হবে। তারপর plan আবার দেখুন। যদি তাও না আসে, WHERE clause rewrite করুন। Function call থাকলে remove করুন। Type mismatch থাকলে fix করুন। ৪. BUFFERS add করুন কোনো node এ অনেক disk reads? Caching investigate করুন। আজই শুরু করুন EXPLAIN (ANALYZE, BUFFERS) run করে দেখুন shared read high কোথায়। সেই node টাই bottleneck। Index add করলে reads কমবে। Pre-warm cache করতে পারেন। Data pre-load করতে পারেন। ৫. Sorts আর hashes দেখুন কোনো spill-to-disk আছে? work_mem raise করুন বা sort eliminate করুন। আজই শুরু করুন Plan এ external merge Disk: 421MB দেখলে spill-to-disk হয়েছে। SET work_mem = '256MB' temporarily rais

2026-06-22 原文 →
AI 资讯

Clean Architecture in .NET 8: A 2026 Starter Template with 4 Projects, EF Core, and JWT Auth

I joined a team where the controller was 800 lines long, the business rules were scattered between the controller and the DbContext , and "to run the tests, spin up a SQL Server in Docker" was a sentence I heard every week. The fix was Clean Architecture. The argument I had with the team lead was about how to actually structure it. We argued for two weeks. Then I built this template so the next person wouldn't have to. This is the Clean Architecture .NET 8 starter template I wish someone had handed me on day one. Four projects, strict dependency direction, domain entities that own their own invariants, and an Application layer you can unit test with Moq — no database required. The whole repo is on GitHub , MIT-licensed, runs with dotnet run , and ships with xUnit tests, JWT auth, Swagger, Docker, and CI. This post is the explanation of why each project exists, what goes in it, and what I learned the hard way about getting Clean Architecture right in .NET. The problem Clean Architecture solves The naive way to build a .NET Web API is one project, one folder structure, and "everything talks to everything": MyApp/ Controllers/ ProductsController.cs ← HTTP stuff OrdersController.cs ← HTTP stuff + business rules Services/ ProductService.cs ← business rules + DbContext.SaveChanges Data/ AppDbContext.cs ← EF Core, entities Models/ Product.cs ← POCO with public setters This works for the first 1,000 lines. By 5,000 lines, the controller is doing five things at once. By 10,000, "to test this, I need a database" is the answer to every test question, and your CI takes 20 minutes because every test run spins up SQL Server. Clean Architecture says: separate the business rules from the HTTP boundary, separate the database from the business rules, and enforce it with project references. A controller is allowed to call a service. A service is allowed to call a repository. A repository is allowed to know about EF Core. Nothing is allowed to know about anything "above" it in the chai

2026-06-22 原文 →
AI 资讯

Article: Understanding ML Model Poisoning: How It Happens and How to Detect It

In this article, the author explores data poisoning as a threat to machine learning systems, covering techniques such as label flipping, backdoors, clean-label poisoning, and gradient manipulation. The article reviews real-world incidents, discusses the challenges of detecting poisoned data, and presents practical defenses, tools, and operational practices for securing ML training pipelines. By Igor Maljkovic

2026-06-22 原文 →
AI 资讯

AWS Graviton5 Reaches General Availability with 192 Cores and Formally Verified VM Isolation

AWS made Graviton5-powered EC2 M9g and M9gd instances generally available with 192 ARM cores, formally verified VM isolation via the Nitro Isolation Engine, and DDR5-8800 memory. ClickHouse reported 36% better performance with zero code changes. Meta committed tens of millions of cores. On-demand pricing is 9% above Graviton4, translating to roughly 15% better price-performance. By Steef-Jan Wiggers

2026-06-22 原文 →
AI 资讯

Detect AI-Generated PDFs: What Works and What Does Not

Originally published at htpbe.tech . The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text. Accounts payable teams are receiving receipts generated by ChatGPT plugins. HR platforms are seeing payslips rendered by Python scripts. Insurance claims contain repair estimates that no shop ever issued. The documents look correct. The logos match. The numbers are plausible. The question is: what can actually be detected, and what cannot? The honest answer requires separating two things that are often confused under the phrase “AI-generated document detection.” Two distinct problems called "AI-generated document detection" When people ask how to detect an AI-generated document, they usually mean one of two distinct things: Content classification asks: was the text in this document written by an AI language model? This is what tools like GPTZero and Turnitin’s AI detector do. They analyze writing style, token probability distributions, and linguistic patterns to estimate whether a human or a model produced the text. Structural forensics asks: was this PDF file generated by a real institutional system, or did it come from a headless browser, a PDF library, or a consumer tool? This is what HTPBE does. It reads the binary structure of the file — producer metadata, xref patterns, font embedding, object numbering — and checks whether those patterns match how legitimate institutional software generates documents. These are not the same problem. A document can contain AI-written text and still come from a real corporate system. A document can contain entirely human-written text and still have been rendered by Puppeteer an hour ago. The structural check and the content check answer different questions. HTPBE does structural forensics. It does not classify text. This article explains what that distinction means in practice, what the structural approach reliably catches, and where its limits are. What structural forensics detec

2026-06-22 原文 →
AI 资讯

I Built a Tool to Track Which World Cup Players Are Blowing Up on Social Media

Every World Cup there's a moment. Some player nobody outside their domestic league had heard of scores an absolute screamer in a knockout match, and by the time they've finished celebrating, their follower count is climbing like a rocket. I always found that fascinating, but I could never see it happening. By the time the "X gained 3M followers!" tweets show up, the surge is already over. So this tournament I built a little tracker that snapshots player follower counts on a schedule and shows me the growth curve in near real-time. Here's how it works. The problem with doing this "properly" My first instinct was the official APIs. That died fast. Instagram's Graph API won't give you follower counts for accounts you don't own. TikTok's Research API is academics-only and takes weeks of applications. X's API now starts at $100/month and climbs steeply from there. I just wanted public follower counts — numbers anyone can see by opening the app. I didn't want a data partnership and a legal review. I ended up using the SociaVault API , which wraps public profile data from each platform behind one key. One request, one credit, JSON back. The shared client Everything runs through one tiny helper: // Node 18+ has fetch built in const API_KEY = process . env . SOCIAVAULT_API_KEY ; const BASE = " https://api.sociavault.com " ; async function sv ( path , params ) { const url = new URL ( BASE + path ); Object . entries ( params ). forEach (([ k , v ]) => url . searchParams . set ( k , v )); const res = await fetch ( url , { headers : { " X-API-Key " : API_KEY } }); if ( ! res . ok ) throw new Error ( ` ${ res . status } ${ await res . text ()} ` ); return res . json (); } Grabbing follower counts across platforms Each platform nests the count slightly differently, so I use fallback chains to stay defensive: async function instagramFollowers ( username ) { const data = await sv ( " /v1/scrape/instagram/profile " , { username }); const p = data . data ?. user ?? data . data ?? data

2026-06-22 原文 →
AI 资讯

How I Built a Developer Knowledge Base in Obsidian That I Actually Use

Every developer I know has the same problem: knowledge scattered across five places at once. Browser bookmarks they never re-read. Notion docs that become graveyards. Slack threads with critical context that disappear into the archive. README files that contradict each other. Stack Overflow answers bookmarked with zero recall of why. I tried most of the "second brain" setups and none of them stuck until I figured out why they kept failing: generic productivity systems are not built for how developers actually think and work. A developer's knowledge is fundamentally different from a writer's or a manager's. It is: Code-linked (a note about a library is useless without the actual code it explains) Decision-heavy (architecture decisions need context, rationale, and alternatives considered) Debugging-intensive (solutions to bugs need the exact error message, environment, and what you tried) Time-sensitive (that API migration note is only relevant for a 3-month window) Here is the structure that actually worked. The Core Structure 00-Inbox/ 10-Projects/ 20-Areas/ - Language: Python/ - Stack: AWS/ - Domain: Auth/ 30-Resources/ - Libraries/ - Tools/ - Patterns/ 40-Archive/ The key insight: Resources are evergreen, Projects are temporary, Areas are ongoing responsibilities. A note about how JWT works lives in 30-Resources/Domain-Auth/ . A note about implementing JWT for the current sprint lives in 10-Projects/Sprint-42-Auth-Revamp/ . When the sprint is done, the project gets archived. The JWT fundamentals note stays forever. The Templates That Made It Click Architecture Decision Record (ADR) # ADR-042: Use Postgres over DynamoDB for user sessions Status: Accepted | Date: 2026-06-22 ## Context We need session storage that supports complex queries for the audit log feature. ## Decision Postgres with connection pooling via PgBouncer. ## Alternatives Considered - DynamoDB: rejected (query limitations for audit log requirements) - Redis: rejected (not durable enough for complian

2026-06-22 原文 →
AI 资讯

Optimizing Django ORM Queries: A Practical Guide to select_related and prefetch_related

1. Introduction Django's ORM is one of its greatest strengths. It abstracts away raw SQL, lets you express database operations in clean Python, and gets you productive fast. But that convenience comes with a hidden cost: if you're not deliberate about how you fetch related objects, you'll silently generate far more queries than you intend — and you won't notice until your app slows to a crawl in production. The most common culprit is the N+1 query problem : a pattern where fetching a list of N objects triggers an additional query for each one, resulting in N+1 total round-trips to the database. At ten rows it's invisible. At ten thousand rows, it's a disaster. Django provides two tools to fix this: select_related and prefetch_related . This article explains how each one works internally, when to use which, and how to combine them effectively — with before/after examples and real query counts throughout. 2. Understanding the N+1 Problem Consider a simple blog with posts and authors. You want to render a list of posts, showing each post's title and its author's name. Models: # models.py from django.db import models class Author ( models . Model ): name : str = models . CharField ( max_length = 100 ) class Post ( models . Model ): title : " str = models.CharField(max_length=200) " author : Author = models . ForeignKey ( Author , on_delete = models . CASCADE , related_name = " posts " , ) The naive approach: # views.py from django.db import connection from .models import Post def list_posts () -> None : posts = Post . objects . all () # Query 1: fetch all posts for post in posts : print ( f " { post . title } by { post . author . name } " ) # ^^^ Query 2, 3, 4, ... N+1: one per post For 100 posts, this produces 101 queries . Django lazily fetches post.author the first time you access it on each object. Each access hits the database separately. You can verify this with django.db.connection.queries (requires DEBUG = True ): from django.db import connection , reset_queries

2026-06-22 原文 →
AI 资讯

Power BI Data Modeling Unleashed: Master Schemas, Relationships, and Joins for High-Performance Reporting

Whether you're brand new to Power BI or just getting started with data analytics, this guide walks you through everything you need to know about data modeling — from how tables connect, to the schemas that make your reports fast and reliable. What Is Data Modeling in Power BI? Imagine you have three spreadsheets: one with your customers , one with your products , and one with your sales transactions . Individually, each table tells you something. But together, they can tell you which customer bought which product, when, and for how much . That's exactly what data modeling is: the process of organizing your data tables and defining how they relate to each other so Power BI can combine them into meaningful reports and dashboards. A data model in Power BI has three core building blocks: Tables — your data sources (Excel files, databases, CSVs, cloud services, etc.) Relationships — the links between tables that tell Power BI how data connects Measures & Calculations — formulas (in DAX) that compute totals, averages, and other insights A well-designed data model is the difference between a report that loads in seconds and one that takes forever. It's also what keeps your numbers accurate and your dashboards easy to use. Why Does Data Modeling Matter? Here's a simple analogy: a city without roads is just a collection of buildings. Data modeling is the road system that lets you travel between your tables. Without a good data model: Your visuals may show incorrect or duplicated numbers Filters in one chart won't affect another Reports will be slow and hard to maintain With a good data model: Clicking on a customer in one visual automatically filters every other visual Calculations are accurate and consistent You can easily add new data sources without rebuilding everything Types of Tables: Facts vs. Dimensions Before diving into schemas and relationships, you need to understand the two types of tables that make up most Power BI models. Fact Tables A Fact table stores the ev

2026-06-22 原文 →