AI
很多系统一开始都靠关键词匹配。 用户搜“车载腰靠”，数据库里有“汽车腰枕”“lumbar support pillow for car”，如果只做 LIKE 或倒排词，召回很容易断掉。Embedding 解决的是这个问题：把文本变成向量，让“意思接近”的内容在向量空间里靠近。 阿里云百炼里的 text-embedding-v4 很适合做这件事。它接入简单，兼容 OpenAI 风格接口，价格也低，适合拿来做搜索召回、RAG 知识库、商品词聚类、类目匹配、相似标题推荐。 本文只讲一件事：怎么把 text-embedding-v4 接进自己的系统。 一句话结论 如果你要给文本做语义召回，可以这样设计： 业务文本 -> 清洗/去重 -> text-embedding-v4 -&
MCP
最近我一直在思考一个问题：传统 SaaS 到底应该怎么转向 AI？ 一开始很容易想到的方向是：给原来的系统加一个 AI 助手。 比如在页面右下角放一个聊天框，让用户可以问数据、生成报告、总结内容、解释指标。这个当然有价值，但我现在越来越觉得，这只是比较表层的一种转型。 真正的变化，可能不是“在 SaaS 里面加 AI”，而是 SaaS 本身的能力形态发生变化。 过去的 SaaS，核心是给人使用。 人登录系统，看页面、点按钮、筛选数据、导出报表、判断问题，然后再去做决策。数据库是给 Web 页面供数的，后端 API 是给前端页面服务的，整个产品的中心是“人如何操作软件”。 但 AI 时代，尤其是 Agent 逐渐发展之后，
AI
最近把一套 Embedding 服务完整落地了一遍：4 张显卡分别启动 vLLM 实例，用 Nginx 做统一入口和故障切换，再在上层挂一个 FastAPI 网关，把原始向量统一裁剪成 256 维并归一化，最终形成一套比较完整、可直接对外提供服务的 Embedding 架构。 这篇文章把整个过程完整整理一下，包含环境准备、离线模型部署、多卡启动、Nginx 配置、systemd 开机自启，以及业务网关设计。 整套架构的目标很明确： * 提供标准 HTTP Embeddings API * 支持四卡并行 * 支持统一入口与负载均衡 * 单实例故障时自动 failover * 支持开机自启 * 保留日志，便于运维与统计 一、整体架构 先看整体结构： Client │ ▼ FastAPI Gateway（8681） ← 推荐对外入口 │ ▼ Nginx（
AI
最近在给这套商品图提示词服务接入新的 OpenAI-compatible 供应商时，我们踩了一个很典型、也很容易误判的坑： * 同样是 /chat/completions * 同样是 OpenAI 兼容请求格式 * 旧供应商 qwen3-vl-plus 跑得很正常 * 新供应商 gemini-3-flash-preview 却频繁只返回半句话 最开始看现象，直觉很容易往这几个方向怀疑： * 这个供应商的 OpenAI 兼容实现不完整 * 多模态图片传递格式不对 * 响应解析逻辑没兼容到位 * 模型本身不稳定 但最后复盘下来，真正的主因比想象中直接很多：我们显式传了 max_tokens，而这个第三方 OpenAI-compatible 供应商上的 gemini-3-flash-preview 组合，很可能把图片理解和推理消耗也算进了输出预算里，导致最终文本阶段只剩下一小截。 这篇文章就把整个问题、排查过程和最终处理方法完整记录一下。 背景 我们的服务很简单： 1. 前端提交商品标题、图片 URL、模型配置 2. 后端调用 Op
MCP
Agent 的工作方式 我们以为 MCP 服务只是查数据的管道，拆开一看，发现服务端已经把分析结论都算好了。这个发现改变了我对 Agent 架构的理解。 起因：一次对 MCP 服务的逆向探索 最近在研究 MCP（Model Context Protocol）的实际应用，我选了一个真实的商业 MCP 服务 —— 某电商卖家流量分析平台作为研究对象。该服务提供了 27 个工具，覆盖关键词分析、流量运营、广告洞察等领域。 最初的预期很简单：MCP 服务就是一个数据接口，Agent（LLM）调用它拿到原始数据，然后自己分析、得出结论、给用户建议。 实际拆开一看，完全不是这么回事。 第一个发现：返回数据里藏着完整的分析结论 我写了一个 Python 脚本，绕过所有 AI 客户端，直接用
MCP
一次从"会用"到"理解原理"再到"能优化"的完整探索记录。 本文记录了我通过实际动手连接一个远程 MCP 服务（SIF —— 亚马逊卖家流量分析平台），一步步深入理解 MCP 协议机制、LLM 上下文管理、注意力资源分配、以及工具编排优化方案的全过程。 一、起点：连上一个真实的 MCP 服务 什么是 MCP？ MCP（Model Context Protocol）是 Anthropic 主导设计的一个开放协议，目的是标准化 AI 应用与外部工具/数据源之间的通信方式。你可以把它理解为"AI 世界的 USB 接口"
AI
阿里的新发的版本，用同样的图+同样的提示词进行两个模型的测试 三联图： 输入图-banana图-wan2.7pro 图
AI
先把结论放前面：LTX-2.3（22B）这条 pipeline 在 4×RTX 3090（24GB）这套硬件上，按官方默认推理方式基本跑不起来。我最终得到的不是“没跑通”，而是一个更有价值的结果：把它为什么跑不起来、卡在哪、该怎么判断“物理不可行”，完整验证了一遍。 这篇文章是一次本地部署的工程复盘：从模型文件下载、依赖链补齐、环境和代码层踩坑，到显存拆分、多卡 device 规划，再到最终 OOM 的边界判断。希望你在遇到类似“看起来只要把权重放进去就能跑”的大模型工程时，可以少走很多弯路。 TL;DR（1 分钟读完） * LTX-2.3 不是单模型，而是一个多组件 pipeline：文本编码器（Gemma）+ 视频 diffusion 主模型（
AI
市面上几乎没人聊这个模型，反倒让我很好奇，我决定全面测评使用一下 StreamLakeStreamLake溪流湖是快手toB视频云平台，提供领先的音视频AI解决方案。包含KAT-Coder智能编程助手、万擎大模型平台、视频云服务、直播云、点播云、实时音视频RTC等产品。基于前沿AI技术和音视频算法，为企业提供智能代码生成、视频处理、内容理解、智能审核等全链路服务，助力数字化转型。StreamLakeStreamLake 付完款发现上下文只有256K , 到今天来说 已经落后了 而且不支持视觉，也没有mcp接入 联网搜索之类的东西 确实是远远落后了 时隔半年再次看快手模型的官网，发现现在几乎就主打这一个模型了 coding plan用这个，然后api 调用这个是， 接入openclaw 也是这个，总之一个模型走天下，看上去太穷了，像是随时跑路的状态，但其实我很喜欢这种方式, 一个模型通杀所有场景 哈哈哈 接入 opencode 中使用 开了一个新的项目，决定保守一点，先让写文档， 之后再生成代码 下面是实际的体验 1. 不断 chat
AI
这篇记录的是我在一台 Mac mini（中国大陆网络环境）上安装并跑通 OpenClaw 的全过程：从一键安装开始，接入阿里 DashScope 的 OpenAI 兼容接口（Qwen），一路踩到 Node TLS 证书链问题，最后用 nvm 彻底解决，并成功进入 openclaw tui。 背景与目标 我想在本机快速体验 OpenClaw（一个可执行工具调用的 AI Agent 框架）。目标很明确： * 在 macOS 上装起来 * 不依赖海外大模型（尽量不需要外网） * 用 Qwen（DashScope 的 OpenAI-compatible 接口）作为模型后端 * 最终能启动到交互界面（TUI） 环境 * 设备：Mac mini
agent
这篇写什么 聚焦 pi-ai 的统一输入输出协议：为什么要把输出分成“事件流”和“最终消息”，以及为什么“可重放性”是 agent 系统的关键约束。 先说结论 pi-ai 的核心价值是：把多厂商模型调用统一成一套对 agent 友好的输入输出协议。 对 agent 友好意味着它要覆盖： * 多轮上下文 * 工具调用 * 流式增量输出 * thinking/reasoning * usage/cost * 失败与中断 * 跨模型继续对话 统一输入：上层真正需要表达的只有四类 1. 用哪个模型 2. 当前上下文是什么 3. 这轮可以用哪些工具 4. 这轮调用的运行参数是什么 模型输入不是字符串 模型对象应携带能力与调用语义：provider、协议类型、上下文窗口、是否支持 reasoning/多模态、成本与兼容配置等。
agent
这篇写什么 只讲 packages/ai（pi-ai）的设计动机与职责边界：它到底统一了什么、为什么对 agent 很关键、它和 pi-agent-core 的分工是什么。 先说结论 pi-ai 的本质不是“又一个模型 SDK”，而是：一个面向 agent 场景的多模型统一抽象层。 它的目标是把不同厂商、不同协议、不同风格的大模型调用方式，收敛成一套统一输入输出标准，让上层系统稳定工作。 为什么值得单独做一层 如果没有这一层，上层会直接面对： * 不同厂商的 API 结构、消息格式、流式协议差异 * tool calling 表达差异 * reasoning/thinking 支持差异 * usage / cost 统计差异 最终会导致： * agent 层被 provider 细节污染 * 每加一个
陕公网安备61011302002223号