OpenAI 如何为 ChatGPT 构建兼顾用户信任与相关性的广告技术栈
OpenAI 详解 ChatGPT 的广告技术栈:由 LLM 驱动理解对话意图,并将广告与回答内容分离,从而在大规模下投放相关广告。该方案以用户信任与相关性为核心设计目标。
OpenAI 详解 ChatGPT 的广告技术栈:由 LLM 驱动理解对话意图,并将广告与回答内容分离,从而在大规模下投放相关广告。该方案以用户信任与相关性为核心设计目标。
作者用 Claude Mods 定制 Claude Code 的工作流,并解释 mod 是运行在 Claude Code 内的 TypeScript 或 JavaScript 插件,可响应提示词、工具调用和界面渲染等事件,修改渲染或接管默认行为。
爱范儿 APPSO 用 21499 元的 iPhone Duo 搭配 86749 元的 Mac Studio,搭建了一套手机远程指挥本地 Agent 的工作流,并专门做了适配折叠屏三种形态的 App。
AWS 在 vLLM 中实现双向 KV 传输,让 decode 节点在后续轮次把已计算的 KV 块回传给 prefill 节点,避免重复计算对话历史。在 Amazon EC2 P5en 实例的 1P1D 部署上,该功能使 Qwen3-32B 的 TTFT 最多降低 1.6 倍、zai-org/GLM-5-FP8 最多降低 3.3 倍。
vLLM 新增 push 模式的 NIXL connector,把 prefill 后的传输协调与建立过程移出首 token 关键路径。在 AWS EC2 P5en 1P1D 部署、EFA 互联的测试中,Qwen3-32B 的 TTFT 最高改善 3 倍,TPOT 最高改善 30%。该功能先在 AWS Trainium 集群验证,再作为与加速器无关的特性贡献给 vLLM。
Deepgram 与 AWS 合作将 Nova-3 语音转文本模型移植到 Trainium2,用于联络中心分析、医疗转写等离线批处理场景。最终配置在单台 Amazon EC2 trn2.3xlarge 实例上运行 8 个模型副本,按评估时实例价格计算,每美元处理的音频量比原有算力方案高 11%–70%。
AWS 博客演示用 AtScale 作为语义层、配合 Amazon Bedrock AgentCore 托管 Strands 智能体,构建 Customer 360 分析模式。
该教程演示如何用 Strategy Mosaic 作为语义层,在 Amazon Redshift 与 Amazon Aurora 上以两个链接模型建模 C360 域,无需 ETL。
本文演示如何用 Denodo Platform 作为语义层,通过 Denodo MCP Server 向托管在 Amazon Bedrock AgentCore 上的智能体暴露受治理视图,并联合查询 Amazon Aurora、Amazon Redshift 与本地 PostgreSQL 构建 Customer 360 视图。
Eon 基于 Amazon Bedrock AgentCore 的 MCP Gateway 搭建了统一的多云调查入口,用单一认证网关替代逐工具凭证和本地 MCP 进程,让开发者和自主智能体统一访问 AWS、GCP、Azure 三朵云上的调查工具。
i14 与 AWS 团队用 TorchNeuron Native 原生 PyTorch 将线性注意力模型 Laplace 3B 移植到 AWS Trainium2,保留 GLA 架构与 Muon 优化器。
New blog post 🎉: How To Use Decision Models For Evals In this post, we show you how to choose a decision model for your task, tune its threshold (don't assume the 0.5 default is good!), and interpret its scores. Lots of cool interactive charts here. https://x.com/i/article/2112552453422104576
Simon Willison 发布 vibe coded 即时战略游戏 Battle Drones,经 12 个大版本迭代、321 次由 Claude Code 等编码智能体提交的 commit,可在手机和桌面浏览器运行。游戏含 9 种建筑、7 种地面载具、6 种空中载具和 3 种步兵单位,并支持两台邻近设备通过麦克风范围内的音频消息同步游戏状态实现多人对战。
AWS 展示用 Amazon Quick 作为交互界面、Amazon Bedrock AgentCore 作为智能层,通过 MCP 服务器把 ERP、监控、采购等系统串成可组合工具层,让供应链管理者用自然语言跨系统提问。
在 Amazon SageMaker HyperPod 上对 GPT-OSS-20B 做多语言推理微调,基座模型在 50 例测试中仅 22% 用目标语言推理(法语、西班牙语、意大利语均为 0%)。
Octave 在 Amazon Bedrock 上为质量管理平台 Reliance 构建了多租户 AI 基础平台,用 Cohere Embed v4 完成 20 亿份文档的嵌入,并将单用例部署时间缩短 50%。该平台以每租户独立向量存储、AgentCore Gateway 隔离执行和 Guardrails 双向过滤三层架构,确保客户数据不跨租户边界。首个落地应用为投诉摘要与分诊助手。
AWS 介绍 Agent Registry 的运行时工具发现方案,让编排器不再把工具硬编码进智能体,而是按请求检索已批准的 MCP 服务器和 A2A 智能体记录。
GitHub 博客采访了 Vlad Mihalcea、Patrick Baumgartner 和 Frank Delporte 三位 Java Champion,分享他们在生产与开源项目中使用 GitHub Copilot 的具体做法。
AWS 与 Keyfactor 联合发布参考架构,用 Keyfactor EJBCA 的 X.509 PKI 为 AI 智能体建立可验证、可撤销的加密身份。
GitHub Copilot 应用中的会话可直接在 VS Code 中打开并继续,对话、代码改动和工作上下文均保持不变。VS Code 会以该会话关联的 worktree 打开项目,并在 Copilot 侧边栏显示原会话,便于逐行审查 diff、手动编辑、本地运行测试,最后提交并推送到会话对应的 pull request。
本地 AI 202:用投机解码获得大幅加速 https://x.com/i/broadcasts/1NGaroZveLVJj
以下是我们 OpenAI 的工程师如何使用 Codex 深入我们的代码库、找出需要关注的地方,并逐步清理维护积压:
Software maintenance is changing. A few months ago, I had to tell Codex exactly where to look for dead code. Now it can find candidates in Slack, check them against production telemetry, and draft cleanup PRs. Here’s how we do this at OpenAI. https://developers.openai.com/blog/maintaining-software-with-the-gpt-6-family
Benefit Street Partners 的 Anant Kumar 借助 Codex 进行代码审查并加快后续跟进,从而更快回答客户问题。他用 Codex 构建了用于比较贷款估值和分析信贷协议的工具。
这篇指南讲解 3D Gaussian Splatting(3DGS)如何把拍摄场景转为机器人的空间记忆,并介绍机器人如何检索、更新该记忆,以及从“记住世界”走向“理解物理”所需的条件。
GitHub 用微调的 ModernBERT 分类器替换原有 LLM 流水线来识别通用密钥,用户接受率提升 11.5%,推送后扫描中位执行时间缩短 86%,服务成本降低超 98%。该方案先用正则高召回生成候选,再由分类器结合文件路径、变量名和上下文判断是否为真实凭据,并已把通用密钥检测扩展到推送保护阶段。
GitHub Copilot 新手指南介绍了四种让 Copilot 适配项目的方式:用 .github/copilot-instructions.md 定义仓库级约定。
GitHub 博客提出开发者应对 AI 工作流的三项技能:学会指挥 AI 智能体而非只使用工具,用第二个模型审查 AI 输出,并把省下的实现时间投入判断与决策。文中以 GitHub Copilot 内置的 Rubber Duck agent 为例,说明其用第二个模型审查计划、代码和测试。
GitHub Copilot 应用中的 canvas 是一种用户与智能体共享的可定制界面,可以是看板、问题分诊板、发布清单或仪表盘,双方都能实时修改。创建时只需打开智能体会话,输入 /create-canvas 技能并用自然语言描述要支持的工作流、用户可做的操作和智能体可做的操作,智能体就会生成界面并显示在右侧面板。
训练智能体 3:学习如何通过强化学习训练一个本地/开放权重智能体 https://x.com/i/broadcasts/1PKqrrbanaZGb
LLM Knowledge Bases Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So: Data ingest: I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them. IDE: I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides). Q&A: Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale. Output: Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base. Linting: I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into. Extra tools: I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries. Further explorations: As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows. TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.