Tito Chan Blog

“升级”了，但我的图变丑了：Google Nano Banana 2 引发的信任危机 📅 2026-02-27｜约3800字｜阅读约10分钟 昨天，Google DeepMind 官宣了新一代 AI 图像生成模型——Nano Banana 2。 发布稿写得很漂亮：**”将 Pro 的能力带到 Flash 的速度上。”** 听起来是两全其美，左手质量右手速度，全都要。 但发布后不到半天，社区里已经炸锅了。 付费用户打开 Gemini，发现自己明明选的是 Nano Banana Pro 3.1，但出图的水印却写着 Nano Banana 2。反复切换，还是一样。Reddit 上那个帖子的标题非常直白——**”Gemini Nano Banana Pro 3.1 不工作了”**。 这不是 bug 汇报，这是在控诉。 一、先搞清楚：Nano Banana 2 是什么在讲争议之前，先对齐一下信息。 Nano Banana 这个名字来自去年 8 月 Google 发布的一个 Gemini 图像生成更新，当时效果惊艳，被大量用户疯狂传播，尤其在印度市场掀起了一波创作热潮。Google Tr ...

AI 物联网控制系统技术方案 这学期学习了物联网控制技术颇有感悟，此处为趁着物联网控制复习时写一篇小文章 一、介绍相关技术背景，描述与本发明技术最相近的现有技术，并说明该现有技术存在的缺点1. 现有技术1.1 边缘计算的现状定义与应用：边缘计算是将数据处理移近数据源的计算架构，其目的是减少延迟和带宽占用，常用于物联网设备中。 1.2 物联网控制技术现状 定义与应用：基于普通电子电路或者一定程序所形成的一套反馈控制系统，其目的是实现简单的自动化控制。 2. 现有技术存在的缺点2.1 边缘计算的挑战高成本问题：尽管边缘计算能够提升实时性，但由于需要专门的边缘计算网关，导致系统整体建设成本较高，尤其是在服务人类的地方，如家庭、办公室和公共场所等，普遍具备网络条件的环境中。 模型单一性：边缘计算通常依赖于特定的算法或模型进行数据处理。这种单一的模型限制了系统的灵活性和智能决策能力，无法像人类一样进行复杂的判断与感知，导致在处理变化和异常情况时表现不佳。 2.2 物联网控制技术现状物联网控制系统虽然在很多领域获得应用，但普遍存在以下问题： 系统灵活性不足，无法应对复杂的场景变化。数据处理能力有 ...

基于 DeepSeek + OpenAI Agent 构建 Agent 实战 本文档基于 openai-agents 官方文档，详细介绍了一个支持异步调用的多智能体系统，实现了各个智能体的明确分工协作。其实在我看来，这个框架的本质是：把 Swarm 改进成支持异步调用，并把手写 Agent 传递变成 Handoff 的封装，可能也做了增加稳定性的优化。 安装指南使用以下命令安装依赖包： 1pip install openai-agents 基础使用流程系统使用包含以下两步： Agent 定义 Agent 执行（输入用户问题） 基础示例代码如下： 1234567891011121314151617181920from agents import Agent, Runner, set_default_openai_client, set_default_openai_api, set_tracing_disabledfrom openai import AsyncOpenAI# 配置 API（请替换为实际的 API Key）custom_client = AsyncOpenAI ...

背景随着 AI 领域中 USB 协议 —— MCP 协议的火爆，越来越多的人希望体验这一协议，但往往由于需要本地部署而止步。我们可通过集成 MCP 服务，在 API 调用中实现“开罐即用”，免去本地部署的繁琐步骤。接下来，将详细说明如何实现该集成。 API 调用示例在标准的 OpenAI API 调用方式基础上，新增最外层的 mcps 字段（标准接口会忽略无效字段，仅在我们的服务中生效），每个 MCP 协议工具对应一个 name 字段，该字段必须与 MCP SERVER 中对应工具的 Name 保持一致。 示例 1：使用时间工具1234567891011121314151617181920curl --location 'http://localhost:8094/api/v1/chat-with-mcp' \--header 'Content-Type: application/json' \--header 'Authorization: Bearer sk-xxxx' \--data '{ & ...

Swarm 框架配合 deepseek 搭建 Agent 先构建基本角色第一步：安装必要的库在开发环境中安装以下库： swarm openai langchain logger 1pip install swarm openai langchain 第二步：导入依赖在代码顶部导入所需的模块。 12345from swarm import Swarm, Agentfrom openai import OpenAIfrom langchain.memory import ConversationBufferWindowMemoryfrom logger import loggerfrom env import DEEPSEEK_API_KEY, DEEPSEEK_BASE_URL 确保 env.py 文件中包含以下内容： 12DEEPSEEK_API_KEY = "your_api_key"DEEPSEEK_BASE_URL = "your_base_url" 第三步：初始化 Swarm 客户端配置 Swarm 客户端以与 API 通信。 ...

上一篇我们了解了向量知识库的常见技术，这篇我们聊聊使用分割文档来优化向量知识库的性能。 分割文档在 chunk 向量化嵌入知识库之前，文档的分割是非常重要的，因为如果分割的粒度太粗，那么向量嵌入的维度会非常大，导致计算量增大，如果分割的粒度太细，那么向量嵌入的维度会非常小，导致信息丢失。 但实际上的应用中，文档的分割粒度需要根据具体的业务场景来确定，比如在问答系统中，对准确性要求较高，那么分割的粒度需要细致，而在百亿级文档的搜索引擎中，对召回率要求较高，那么分割的粒度需要粗粒度。 Langchain 里面已经集成了很多分割文档的方法，如 CharacterTextSplitter、NLTKTextSplitter、SpacyTextSplitter、RecursiveCharacterTextSplitter、MarkdownTextSplitter、LatexTextSplitter。 固定大小分块这是最常见、最直接的分块方法： 我们只需决定块中的 tokens 的数量，以及它们之间是否应该有任何重叠。一般来说，我们会在块之间保持一些重叠，以确保语义上下文不会在块之间丢失。在大多 ...

市面上有多种开源或闭源项目可用于 RAG 的搭建，我在一一了解之后写下这篇总结 常见可用于搭建知识库的技术： 技术 存储占用 查询速度 适合数据规模 适用场景 事务支持 FAISS 低（优化存储） 🚀🚀🚀（最快，支持 GPU） 百万 ~ 十亿 高吞吐向量搜索 ❌ 无 Milvus 中等（支持磁盘索引） 🚀🚀（适合分布式） 百万 ~ 十亿 企业级向量数据库 ✅ 有 Elasticsearch (ES) 高（倒排索引开销大） 🚀（适中） 百万 ~ 十亿 关键词 + 向量混合搜索 ✅ 有 pgvector 高（受 PG 事务影响） 🚀（适中） 10 万 ~ 百万 轻量级 RAG 应用 ✅ 有 我整理的大概表格，呈现比较表面，他只根据这些技术的配置支持说明大概阐明如 FAISS 可以用 GPU 加速、Milvus 可以水平拓宽…实际上运用中查询速度快慢其实和底层使用的知识库索引方式有着巨大相关性。 常见的底层索引技术： 索引技术 存储占用 查询速度 查询准确性 适合数据规模 适用场景 备注 Flat 低（存储完整向量，无额外结构） 线性扫描 ...

开源 AI 模型实际部署以及后端搭建环境配置 本文是博主zzzzz想要综合多个开源AI模型分布式部署,以及分布式后端反馈的搭建日记 技术栈python 与 golang Gin框架,grpc,Redis等等 基础环境搭建算力平台 ( cuda , conda ) 基本需求显卡支持调用cuda且满足后续所提项目的显存(最好>=12GB) 若搭建在虚拟机上需独占内存 对于一台新开的Linux机子, 一开始不少困扰大家的就是环境搭建, 我看过周围的人搭建环境卡了两天都没搭好(请不要让apt或者pip等工具自己匹配版本下载), 于此,我在这里写详细一些. 接下来,我以本人的Ubuntu Linux 22.04 + NVIDIA RTX 5000 架构:Turing 举例 (T4可以照抄,其他更多型号要留意适配cuda版本) 以我的举例 ( PS:我们需要在英伟达官网找到对应卡支持的版本!!! ) 1wget https://developer.download.nvidia.com/compute/cuda/12.3.1/local_installers/cuda_12.3 ...