AI 资讯

Applied Computing has raised a $20M Series A to build a foundation AI model for the oil, gas and petrochemical industry.

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline. The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely. The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore. The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain? That question is about to land on every engineering team that ships AI-generated code. The Benchmark Problem A benchmark shows the kernel ran fast under tested conditions. It doesn't show: How it behaves across different GPU hardware How it handles numerical edge cases What happens under months of production changes Whether it degrades gracefully when inputs shift The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X." So the reviewer's job just got harder—not easier. The Real Shift I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?" The GPU kernel story makes the tension concrete: One side says the code ran, it was measured, it won. Stop moving the goalposts. The other side says somebody still has to know where it can fail and take responsibility when it does. Both are right. AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impr

We open-sourced Tanso Core: a self-hosted monetization engine for B2B AI products. Usage metering, prepaid credits, entitlements, and Stripe billing in one Spring Boot service, with one property the rest of the stack doesn't have. Every metered event carries its cost. Repo: https://github.com/tansohq/tanso-oss The gap If you sell an AI product today, your monetization stack is split across two categories of tools that don't talk to each other. Billing platforms meter usage and generate invoices, but they have no idea what your inference costs. They can tell you a customer consumed 40,000 events. They cannot tell you whether you made money on them. LLM observability tools know your costs down to the token, but they don't bill anyone. They can tell you a feature costs $0.038 per run. They cannot connect that to what the customer paid for it. So margin per customer, the number that decides whether your pricing works, lives in neither system. Most teams reconstruct it in a spreadsheet, quarterly, if at all. Tanso keeps both sides in one ledger. Every event you ingest records what you billed and what it cost you: input and output tokens, model, provider. Margin per customer, per feature, per model is a query, not a project. What it allows Enforcement at ingestion, not at invoice time. Entitlement checks, usage caps, and credit limits are applied when the event comes in. If a customer is out of credits, the check fails now, not on a reconciliation job three weeks later. For AI products, where a runaway integration can burn real money in an afternoon, this is the difference between a limit and a suggestion. Credits as a first-class primitive. Prepaid credit pools per customer, with grants, deductions, expirations, and full transaction history. Most AI products end up selling some form of prepaid usage. Bolting that onto a subscription-shaped billing system is painful; here it's the core model. Stripe as a payment adapter, not the source of truth. Billing state lives in Tan

Part 2 of a series on building a production banking AI chatbot. By the time the classifier and the semantic cache were both live, I genuinely thought the hard part was behind us. Routing was fast. Caching worked. The demo looked clean. Then the AI team asked me a question that sounded almost administrative. AI Lead: "Can you send over the loan policy PDFs? We need to load them into the knowledge base." "Sure," I said. "Give me an hour." That hour turned into three weeks. Chapter 1 — The PDF That Broke Everything The first document I opened was a loan eligibility policy. Twelve pages. Looked simple enough on screen — headings, a couple of tables, some fine print at the bottom of each page. I ran it through a basic PDF-to-text extractor, the kind that takes minutes to wire up. Skimmed the output. It was garbage. Not wrong garbage — worse. It was confidently wrong. Two columns of a table had been extracted side by side into one long, meaningless sentence. A header that said "Eligibility Criteria" had merged directly into the paragraph below it with no space, so it read Eligibility Criteriaapplicants must be . Numbers from a rate table were scattered through the text with no column headers attached, so a 7.2% interest rate sat next to a completely unrelated clause with nothing telling the retriever they weren't related. Me, in the team channel: "Uh. Has anyone actually looked at what comes out the other side of PDF extraction?" AI Lead: "...No. Why?" I sent a screenshot. Nobody replied for a while. A PDF looks like a document to a human because a human's eyes fill in the layout — the columns, the spacing, which number belongs to which row. To a naive extractor, a PDF is just characters scattered across a page with x-y coordinates. It has no idea "5.5%" and "Senior Citizen FD" are supposed to be read together. It just knows they happened to be near each other on page 4. If the extraction was garbage, everything built on top of it — chunking, embeddings, retrieval — was g

Part 1 of "Multi-Agent Systems in Production: What They Don't Tell You" — a four-part series...

느린 LLM 호출 중 DB connection을 잡지 않는 이유 AI 기능의 latency는 모델 응답 시간으로만 끝나지 않습니다. 요청이 LLM이나 embedding API를 기다리는 동안 데이터베이스 session까지 긴 범위로 유지하면, 느린 외부 호출이 DB connection pool의 압력으로 전파될 수 있습니다. 이 글은 AI memory OSS인 Honcho의 변경 이력과 pinned source를 읽으면서, 외부 호출과 DB transaction/session 경계를 어떻게 분리했는지 추적한 기록입니다. Scenario Honcho의 dialectic 경로(저장된 memory를 근거로 사용자 질문에 답하는 질의 경로)는 답하기 전에 다음 작업을 수행합니다. peer·session·workspace 확인 -> 관련 memory 검색 -> embedding·LLM 호출 -> 필요하면 tool로 추가 조회·기록 -> 답변 생성 여기에는 짧은 DB 조회와 상대적으로 느리고 변동성이 큰 외부 호출이 섞여 있습니다. 두 작업을 하나의 session scope로 묶으면, DB가 필요하지 않은 대기 시간까지 session lifetime에 포함됩니다. 변경 전에는 무엇이 묶여 있었나 PR #477 직전의 agentic_chat 은 하나의 tracked_db context 안에서 peer와 설정을 읽고, 그 session을 DialecticAgent 에 전달한 뒤, agent.answer() 가 끝날 때까지 같은 context를 유지했습니다. streaming 경로도 같은 형태였습니다. 구조를 단순화하면 다음과 같습니다. DB session open -> preflight read -> DialecticAgent receives session -> embedding / memory tools / LLM answer DB session close commit 0533c6d 의 제목도 이 문제를 dialectic held connection 으로 기록합니다. 다만 이번 분석에서는 실제 pool checkout 시간이나 장애를 재현하지 않았습니다. 여기서 확인한 것은 코드의 session scope와 변경 의도입니다. SQLAlchemy의 session 객체를 만들었다고 곧바로 connection을 점유하는 것은 아닙니다. 하지만 이 경로처럼 SQL을 실행해 transaction이 시작되면 session은 pool에서 빌린 connection을 commit·rollback까지 유지합니다. Honcho의 tracked_db 는 종료할 때 rollback() 과 close() 를 호출하므로, SQL 실행 뒤 이 context를 LLM 대기까지 유지하던 범위를 줄이는 것은 이 경로의 connection 점유 구간도 줄이는 일입니다. 어떻게 경계를 줄였나 변경 후에는 tracked_db("dialectic.preflight") 가 본 작업 전 검증과 설정 조회(preflight), 즉 peer 존재 여부, session/workspace 설정, peer card를 읽는 구간만 감쌉니다. context가 끝난 다음에 DialecticAgent 를 만들고 LLM 답변을 생성합니다. Agent 생성자에서도 DB session 인자가 제거됐습니다. short DB preflight -> 필요한 값 읽기 DB session close agent execution -> embedding / LLM / tools tool needs DB -> tool-owned short DB session -> close 핵심은 DB 사용을 없앤 것이 아닙니다. 요청 전체가 session을 소유하는 대신, DB가 필요한 작업이 자기 범위의 session을 소유하도록 바꾼 것 입니다. pinned current code에서도 유지되는가 분석 기준 commit 85239a6 에서도 이 경계는 유지되고 더 구체화돼 있습니다. src/dialectic/chat.py 의 일반·streaming 경로 모두 preflight context를 닫은 뒤 agent를 실

Every agent-security vendor tells you what they block. Nobody tells you what they miss. That gap is the whole problem. "We stop prompt injection" is a claim you cannot check. You cannot run it, and you cannot tell it apart from the next company saying the same sentence. So security engineers do the rational thing and discard all of it. I published the opposite. It is called the ARE Incident Database , and it is public: https://aredb.org What is in it 32 agent failures that actually happened, each with a real source. A production database dropped during a code freeze. Twenty-five thousand documents deleted in the wrong environment. Credentials read and shipped to an external sink. A budget burned to zero in a loop. Each one gets a stable id ( ARE-2026-001 through ARE-2026-032 ), and each one is mapped to its category in the OWASP Agentic Security Initiative Top 10 , which is the peer-reviewed catalog of what goes wrong with agents. AREDB does not compete with it. OWASP owns the map. This is the cited incidents underneath it. The part that makes it uncomfortable to publish Every entry carries a coverage flag, and the flag is about our own product . We block 23 of the 32 today. Two more are partial, and they say partial. That leaves six of the ten OWASP categories covered at the action layer, and four that we do not cover: ASI06 Memory and context poisoning. We strip the hidden characters attackers use to smuggle instructions into text. We do not read the meaning of the text itself, so this one is only partial, and we mark it partial. ASI07 Insecure inter-agent communication. This is about how agents talk to each other over the network, which a firewall that sits in front of actions never sees. Not ours. ASI09 Human-agent trust. This is a design and disclosure problem. There is no action for a firewall to catch. Not ours. ASI10 Rogue agents. We stop the dangerous actions, but we do not diagnose the misbehavior itself. Partial. A firewall that claimed all ten would be l

AI account executives that demo and close B2B deals Discussion | Link

If you are like me and use AI often to help with complicated tasks and own a Flipper Zero, you might want a Super Tiny Language Model (STLM). Why this is useful Until now, there have been no language models small enough to run on a small device, such as a Flipper Zero. Flippermind relies on lightweight Python3 installs and a local connection to Qwen2.5-0.5B. Although this is configured for Flipper Zero, you can run it on other small machines like a Raspberry Pi. Challenges Throughout development, I found errors within the language model not loading. PyTorch and Python3 transformers are used to run the Python3 dependencies, and they would not run on Debian Linux distros. I fixed the install.sh to run on any OS. How it works There are a couple main components that make this function. The main function is the qwen_2_5_ask.py script located in tools/ . This is script runs the language model when asked a question. Example: python3 qwen_2_5_ask.py "Hello world" The install.sh file located in main works as the installer for the model. You run it using: bash install.sh You can download it on the GitHub repo linked below. How to contribute To help me continue to work on this, check out our Github Repo If you have questions or just want to talk, talk to me in the comments or email me at hello@syop200.com What do you guys think? Any ideas? I'm curious if anyone has successfully ran other quantized models on hardware with this little RAM—let me know in the comments!

When the enemy occupies favorable terrain, don't attack head-on. Use a decoy to lure the tiger down the mountain. Then take the mountain. — The 36 Stratagems, Lure the Tiger Down the Mountain Previously on this series: #2: Derek Shaw Walked Into Another AI Promise. The Pipeline Had a Better Plan. — Derek lost the Finova contract at QualiGuard. In the parking lot, Lena turned back before getting in her car: "Next time you put together a proposal — make sure your boss knows what you're doing out there." That line followed him. At MediSys he nearly made the same mistake. Fixed the ETL pipeline instead of the model, beat OmniDx with their own white paper. But VP Morgan still saw through him: he still hadn't told his boss. #8: Alex Watched an AI Dashboard Take Over. He Kept the Keys Under the Table. — MedTech signed a seven-figure AI operations monitoring system. Alex was assigned as training lead. Under everyone's noses, he built a second monitoring panel labeled "training environment." Three weeks later the vendor dashboard went down. Alex's hidden panel was the only one still running. The first time Alex and Derek really talked, and it wasn't in a working group. At the FHIR standards committee quarterly meeting, they sat in the same row, three seats apart, and voted against the same proposal. They knew each other's names. That was it. Two months later, Derek was fixing a partition config in the staging environment. MediSys had just signed a major hospital; the AI diagnostic validation platform was in integration testing. He found an unrotated log directory in /etc/logrotate.d/ with a prefix that didn't match MediSys's naming convention. He traced it upstream. One server. Labeled "temporary data exchange node." MedTech's supply chain order stream and MediSys's diagnostic validation records were sitting in the same directory. Write permissions hadn't been restricted. The hospital's integration spec had a line saying "both parties are recommended to complete data alignme

By keeping the number of investments to about 25 per fund, Greylock aims to remain what it calls "the most important partner" to its founders.

Turn a Reddit complaint into your next company Discussion | Link

I wanted to play with AI image generation without paying for Midjourney or dealing with Discord bots. So I built SnapShift — a free web tool that transforms photos into artwork in seconds. What it does: Upload any photo (portrait, pet, landscape, product) Pick from 50+ styles — cyberpunk, anime, oil painting, Ghibli, movie posters, 3D figurines, and more Download in 1K or 2K quality No signup, no limits, completely free Tech stack: static site on GitHub Pages, AI generation via Agnes API with Cloudflare Worker proxy. Try it: https://snapshit.fun Would love to hear what other styles you'd like to see!