自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(130)
  • 收藏
  • 关注

原创 不同模态的模型会收敛到同一个世界表征(三)

选型会吵起来,通常不是因为数据不够,是因为大家在比不同的东西。有人比分数,有人比训练成本,有人比「社区有没有人踩过坑」。所以先把维度钉死,五个,每个都有明确的度量方式:维度怎么量为什么必须有这一维对齐质量mutual 10-NN / 跨模态 R@1这是路线存在的理由,没有它其余免谈数据形态成本需不需要配对?配对要不要人工标?决定项目能不能启动,比分数更硬训练成本同预算下的墙钟时间 + 显存决定能不能迭代,迭代不了就没有第二版事后可拼接性两个独立训练的模型能不能接上。

2026-11-08 20:20:30 170

原创 不同模态的模型会收敛到同一个世界表征(二)

上一篇拆了「good view / bad view」的机制。

2026-11-08 20:19:13 259

原创 不同模态的模型会收敛到同一个世界表征

10 月 29 日,Balestriero 与 LeCun 在 arXiv 挂出一篇论文(2610.39302),把「不同模态的模型会收敛到同一个世界表征」这个 2024 年提出的假说,在 JEPA 框架下证成了定理:只要正样本对是。

2026-11-08 20:17:14 281

原创 同档开源大模型怎么选:ERNIE 5.5 Flash Base 对比 DeepSeek V4 Flash、混元 Hy3、MiMo V2.5、Kimi K3.1 Pro

6 款开源权重模型在一周内集中发布,参数从 280B 到 2.8T,许可证从 MIT 到定制协议。本文按能力、长上下文账本、部署门槛、许可证四个维度硬碰,用三段可跑代码算出缓存增长阶、许可证闸门和帕累托前沿,最后给出一棵能直接用的决策树。

2026-11-06 22:46:02 219

原创 280B 的 base 模型能用在哪些场景?ERNIE 5.5 Flash Base 的 6 个落地路径与一本真实成本账

ERNIE-5.5-Flash-Base 是预训练终点的检查点,不能对话、没有 chat template、权重 288GB。本文不谈跑分,只回答三个问题:它能接什么活、第一步怎么搭、账算不算得过来。文中给出显存预算、数据打包、单任务成本三段可跑代码,并得出一个不太讨喜的结论——自建的单任务成本是调用 API 的 3 到 4 倍。

2026-11-06 22:44:38 160

原创 一文读懂 ERNIE 5.5 Flash Base 的效率设计:37 层只缓存 1/128 的 KV,凭什么敢开 1M 上下文

百度 11 月 5 日开源的 ERNIE-5.5-Flash-Base(280B 总参、14B 激活)把 43 层里的 37 层改成「每 128 个 token 只缓存一条」,只留 6 层看全文。本文拆开这套混合稀疏注意力、多路由器 MoE、ECHO 投机解码,并用四段可跑代码算清楚:128:1 的压缩比在整模型上到底剩下多少、为什么必须留 6 层、多路由器为什么不多花 FLOPs 却能选得更准。

2026-11-06 22:43:07 209

原创 原生 SVG 和 GIF 到底该选谁:GPT-Image-2.6、Recraft、代码模型、自动描边五路横评

素材生成这个赛道的对比特别容易被带偏,因为「谁画得好看」是个无法收敛的问题,而各家发布时又都在强调自己的强项。所以我先把维度定死,并且说明为什么是这五个而不是别的。维度为什么必须比怎么量化可编辑性决定这份资产能不能进设计系统,是「素材」还是「截图」有无viewBox、路径指令数、能否改色、能否分层一致性决定要不要返工;素材是成套交付的,单张好看没用多轮编辑漂移、帧间稳定度、同风格批量价格决定能不能规模化,但必须换算成「交付价」单次成本 ÷ 合格率 + 人工分钟延迟与吞吐。

2026-11-05 21:15:30 178

原创 GPT-Image-2.6 的 GIF 和 SVG 能用在哪些场景?5 个能上线的工程模式与一张成本账

图标有客观验收标准(网格、颜色数、路径指令数),可以自动打分。这也是唯一一个我敢让机器自己判合格与否的素材类型。

2026-11-05 21:13:39 356

原创 我把 GPT-Image-2.6 的 GIF 和 SVG 输出拆开看了一遍:它其实没做视频,只画了一张精灵图

原文大意是:生成一张用于无缝循环 GIF 的单张动画序列图(sprite sheet),严格包含 6 个连续帧,按 3 列 × 2 行网格排列,从左到右、从上到下阅读,每个面板尺寸完全一致,固定前侧四分之三机位,同一角色、同一书桌、显示器、服装和背景,第六帧平滑过渡回第一帧,无字幕、无边框、无留白。如果你要的是 10 秒带镜头运动的短片,它帮不了你,还是得回到视频模型。它做的是把两种「格式」变成两个「可编程的输出通道」,然后用一个特别朴素的工程手段(画一张格子图再切)绕开了视频模型的成本。

2026-11-05 21:11:33 224

原创 Hy4、Claude Opus 5.5、Kimi K3.1 Pro 该选谁?

Hy4 发布当天,"最强开源"和"仍落后闭源"这两句话同时出自官方。

2026-11-04 23:14:02 409

原创 5 条落地路径 + 一份可复用的工程骨架

官方提到的"人机双写"——模型可以和用户实时协作编辑 Word / Excel / PPT——是办公场景里最实用的一个设计点。原因是办公文档的本质是共创,不是生成。用户要的不是"给我一份报告",而是"我改一段,你补一段,我们同时在一份文件上推进"。冲突怎么解。模型在 B 列插了一行,用户同时在 C 列删了一行,两份修改怎么合并?现实中的可行做法有三档:策略做法适用区域锁模型只写指定区域,其余只读报表、模板类文档操作变换(OT)把双方操作转成可交换的操作序列需要精细合并的协作文档。

2026-11-04 23:12:23 288

原创 腾讯混元 Hy4 的 Computer Use 是怎么实现的:把「看屏幕」拆成一次状态机推理

2026 年 11 月 4 日,腾讯混元发布 Hy4 正式版,770B 总参数 MoE,第一次给主力模型装上了视觉理解和电脑操作(Computer Use)。

2026-11-04 23:10:26 283

原创 跨境电商竞品报告工作流搭建流程(三)总结篇

环节时间难度下载登录 WorkBuddy2 分钟零创建文件夹、确认路径1 分钟零写提示词并手动测试15—30 分钟(含调整)低,但需要耐心创建自动化任务2 分钟零每周维护(路径 B)30 秒零每周维护(路径 A)0零,但数据精度低三个最重要的判断:第一,数据源决定一切。没有付费插件,WorkBuddy 只能读到页面上的标题和价格,读不到销量。你的周报质量上限,在你选择数据源的那一刻就基本确定了。如果预算允许,Helium 10 或卖家精灵的订阅是这个工作流里。

2026-11-03 23:33:42 231

原创 跨境电商竞品报告工作流搭建流程(二)

以下配置可直接复制调整。

2026-11-03 23:30:42 154

原创 跨境电商竞品报告工作流搭建流程(一)

用 WorkBuddy 直接“抓取亚马逊销量前 10”有一个现实限制:WorkBuddy 的浏览器自动化能力可以打开页面、滚动、点击、读取内容,但亚马逊的销量数据并非直接展示在页面上,需要依赖插件(如 Helium 10)或第三方数据工具来推算。(精度有限,适合起步)和(精度更高,推荐)。

2026-11-03 23:28:31 162

原创 实战篇——知识库 Agent“产品客服助手”与发布上线

第三篇练的是知识库的“边界意识”——RAG 的效果一半靠文档质量,一半靠 Prompt 中的“禁止编造”约束。这个项目创建一个产品客服 Agent,知识库中放入一份虚构的“智能水杯产品手册”,要求 Agent 只基于手册内容回答用户问题,手册中没有的信息必须明确说“暂未收录”。Agent 调试通过后,点击右上角“发布”,在渠道列表中选择“飞书”。回到扣子发布页,粘贴这两个值,勾选“消息接收”和“发送消息”权限,点击验证并保存。用管理员账号登录飞书开放平台,创建“企业自建应用”,类型选“内部应用”。

2026-11-02 23:22:18 158

原创 进阶篇——工作流实战“新闻早报生成器”

单靠提示词只能做“文本进、文本出”的任务。当需要获取实时信息 + 结构化处理 + 生成图片时,必须上工作流。这个演示项目的效果是:用户在开始节点输入一个新闻主题(如“人工智能”),工作流自动搜索当天新闻、提炼摘要、生成一张带日期和摘要的早报图片,并在结束节点返回图片。完整节点链路:开始 → 新闻搜索 → 大模型(提炼摘要)→ 获取当前时间 → 画板(排版图片)→ 结束。开始节点:设置一个输入变量 ,类型为文本,描述写“新闻主题关键词”。在试运行时,这个变量的值就是用户输入的词。新闻搜索节点:从插件库添加搜索

2026-11-02 23:21:30 233

原创 扣子入门篇——从零建一个“工作日志精灵”Age

如果输出格式不符合 Markdown 结构,把提示词里的“不要添加额外段落”改成更硬的指令:“输出必须以‘## 今日完成’开头,以‘## 明日建议’下的最后一条建议结尾,前后不得有任何其他文字。登录扣子后,在 Agent 区域点击“+”。这个项目选择“定义专属 Agent”,名称填“工作日志精灵”,描述写“将零散工作记录整理为结构化日志”。如果 Agent 在“今日完成”里把“吃拉面”也写进去,说明提示词中“工作事项”的边界不够清晰,需要补充排除规则:“社交、用餐、休息等非工作内容不计入完成事项。

2026-11-02 23:20:43 263

原创 RDMA 文件传输踩坑(五):READY 发送成功后,为什么出现 Work Request Flushed Error?

完成 READY/ACK 初步改造后,我在主机先插入约 5 万条数据,再启动从机进行 AOF 同步。主机只打印了“master listening”和“master connection established”;从机打印“slave connection established”“SEND type=3, length=0”,随后出现:。这个日志特别容易被误读为“READY 消息发送失败”。但结合代码, 的打印位置在 成功等待 SEND CQE 之后,说明它更可能是在随后等待 DATA 的接收完成时,拿

2026-10-31 23:51:40 229

原创 RDMA 文件传输踩坑(四):从固定延时改造为 READY/ACK 协议

关键词:停等协议、READY、MARKER、FINISHED、应用层 ACK、STAR。

2026-10-31 23:50:33 230

原创 Ubuntu 配置 Samba 共享文件夹并映射到 Windows 完整指南

在日常开发中,我们经常需要在 Windows 宿主机和 Ubuntu 虚拟机(或物理机)之间互相传输文件。虽然可以使用 VMware Tools 或第三方工具,但通过协议将 Ubuntu 的文件夹直接映射为 Windows 网络驱动器,是最高效、最原生的做法。以下是完整的配置流程记录,适用于 Ubuntu 20.04 / 22.04 / 24.04。

2026-10-31 13:40:46 164

原创 第三期:结果解读、复核与异常处理

Codex 返回的异常列表和数字,。这一期讲怎么判断哪些可以用、哪些必须回原始数据对账,以及当工具本身出问题时怎么办。

2026-10-30 23:38:41 120

原创 第二期:向 Codex 提出有效的出货异常查询

接入跑通后,员工面对的不再是“怎么连”,而是“怎么问”。Codex 本身不会主动知道你们 LangGraph 里封装了哪些排查逻辑,它需要被明确告知。这一期解决的就是这个问题。

2026-10-30 23:37:51 194

原创 第一期:把 MCP Server 接入 VS Code 与 Codex

启动 MCP Server 后,在 Codex 的聊天窗口(Agent 模式)里,员工应该能看到可用工具列表中出现了你们 MCP Server 提供的工具(比如。(即 VS Code 直接执行一条命令来拉起进程),员工还需要有对应的运行时(如 Python/uv 或 Node/npx)。你们用 Docker 做容量隔离,MCP Server 大概率跑在容器里,或者需要 Docker 提供运行环境。(FastAPI 暴露的 MCP 端点),则只需要 URL 和鉴权信息。如果你们的 MCP Server 是。

2026-10-30 23:36:08 274

原创 RDMA 踩坑(三):多个 RECV 指向同一块内存,为什么会丢数据?

多个 ibv_post_recv 指向同一内存(cm->rbuffer)会导致接收数据被后续写入覆盖,引发“完成事件与实际数据不一致”问题。尽管提交了16个接收请求,但因所有WR共享同一缓冲区,后到达的MARKER消息会覆盖前一条DATA消息内容,造成从机仅读到12字节异常。根本原因在于:注册MR不等于自动隔离缓冲区,多WR不等于多独立槽位。修复方案为:单缓冲区需严格顺序处理(完成→消费→重投),或多缓冲区使用独立内存+wr_id绑定槽位,确保完成事件与对应缓冲区正确关联。

2026-10-29 23:31:36 53

原创 RDMA 文件传输踩坑(二):为什么 `sleep()` 不能保证接收端准备好了?

在RDMA文件传输中,依赖sleep()等待接收端就绪不可靠,因时序竞争无法保证。正确做法是通过协议层明确同步:从机先提交接收WR并发送READY,主机收到后才发送数据,形成显式背压。此举将“时间猜测”转为“状态确认”,提升可靠性。同时需注意控制消息超时、重连与重复READY防御,确保高负载下稳定传输。

2026-10-29 23:30:10 346

原创 RDMA项目踩坑(一):为什么最后一块数据必须使用实际长度?

在RDMA文件传输中,最后一块数据必须使用实际读取长度,因SEND/RECV为消息语义,非字节流。若固定使用缓冲区大小发送尾块,会传输未读取的无效内存。发送端应根据fread()返回值设置SGE长度,接收端以wc.byte_len推进偏移,确保每条消息真实有效。三者长度(SGE发送、SGE接收、WC实际)不可混淆,否则导致越界或数据污染。

2026-10-29 23:28:08 93

原创 第三期:LangChain + Ollama 本地 RAG 应用(从模型到产品)

如果检索效果不够好(尤其是查具体数字、专名时漏检),可以引入混合检索:稠密向量(Chroma)加稀疏检索(BM25),用 RRF 融合排序。有测试数据显示,在事实型查询上,混合检索的 recall@3 从纯稠密的 73.3% 提升到 93.3%。第三期的验收标准:上传一份 PDF,问一个文档中明确有答案的问题能正确回答,问一个文档中没有的问题能说“未提及”而不是编造。这个提示词中的“只根据文档回答,没有就说未提及”很重要。如果文档中没有相关信息,直接说“文档中未提及”,不要编造。# 带反幻觉约束的提示词。

2026-10-28 16:40:08 226

原创 第二期:API 调用与 OpenAI 兼容对接(把模型接入代码)

json={"model": "qwen2.5:7b", "prompt": "写一段 100 字的产品介绍", "stream": True},:用两种方式从 Python 调用本地模型——Ollama 原生 API 和 OpenAI 兼容接口,理解何时用哪种,并掌握流式输出的基本写法。{"role": "user", "content": "Ollama 和 vLLM 有什么区别?{"role": "system", "content": "你是一个简洁的技术助手。,OpenAI 兼容接口走。

2026-10-28 16:38:52 165

原创 第一期:安装部署与模型管理(让本地大模型跑起来)

模型文件磁盘占用:7B 量化版约 4–5GB,14B 约 8–10GB,32B 可达 20GB 以上。Ollama 的核心价值是降低本地运行开源大模型的门槛:一条命令完成模型拉取和启动,数据完全留在本机,断网也能用,并且原生兼容 OpenAI API 风格,后续接入代码几乎不用改原有逻辑。:在 Windows/macOS/Linux 上装好 Ollama,拉取一个中文模型,用终端完成第一次对话,并理解模型大小与硬件的关系。模型参数越大,推理能力越强,但内存和显存消耗也越大。是否在 PATH 中。

2026-10-28 16:37:59 165

原创 第三篇:函数、文件与异常处理 / Functions, Files & Exception Handling

中文:用def定义函数。参数可以有默认值,调用时可使用关键字参数。return返回结果,无返回值时返回None。EnglishdefreturnNonepython"""返回问候语 / Return a greeting message."""print(greet("Bob", greeting="你好")) # 你好, Bob!中文:继承Exception定义业务异常,便于上层代码精确捕获。

2026-10-27 23:32:46 229

原创 第二篇:列表、字典与流程控制 / Lists, Dictionaries & Control Flow

labels = ["偶 / even" if n % 2 == 0 else "奇 / odd" for n in numbers]fruits.insert(1, "blueberry") # 指定位置插入 / insert at index。print(student.get("gpa", "N/A")) # N/A 默认值 / default。print(f"分数 / Score: {score}, 等级 / Grade: {grade}")print("发现奇数 / found odd")

2026-10-27 23:31:44 191

原创 第一篇:变量、数据类型与基础运算 / Variables, Data Types & Basic Operations

变量名区分大小写,建议用蛇形命名法(snake_case)。print(f"{name} 的分数是 {score} 分 / {name}'s score is {score}")radius = float(input("请输入半径 / Enter radius: "))print(a // b) # 3 整除 / floor division。print("{} 得分 {}".format(name, score))print("%s 得分 %.1f" % (name, score))

2026-10-27 23:28:21 195

原创 融合策略与生产化——让主题词“更稳、更干净、可落地”

有研究对比了 TF-IDF、TextRank、LDA 两两交集与并集的效果,发现“先两两相交再取并集”既能过滤单一算法产生的噪声词,又能弥补交集造成的信息损失。真实语料里,“用户”“问题”“进行”这类词在统计上可能权重不低,但对主题表达没有价值。domain_stopwords = {"用户", "问题", "进行", "一个", "没有", "可以", "这个"}:单一算法各有噪声,把多种结果交叉验证或合并,再接入停用词、词性过滤和批量处理,形成可用的主题词提取流程。,补充语义相关但词频不高的主题词。

2026-10-26 11:32:47 61

原创 TextRank 与 LDA——从“词频重要”到“结构重要”和“主题重要”

TextRank 把文本看作一个词图:每个词是节点,词与词如果在滑动窗口内共现就连一条边,迭代传播权重后,处于核心位置的词就是关键词。LDA 是主题模型,它不直接给单个文档排关键词,而是假设每篇文档由若干主题混合而成,每个主题又对应一组词的概率分布。要提取主题词,需要先有一个文档集合,训练 LDA 后查看每个主题下概率最高的词。LDA 的局限也很明显:主题数需要人工设定,短文本(如单条评论、标题)上效果不稳定,且输出的是“主题词”而非“文档关键词”。text = """这里放入需要提取主题词的长文本。

2026-10-26 11:31:28 132

原创 TF-IDF 基线——用词频与逆文档频率跑通第一条提取链路

TF-IDF 的核心思想是:词频(TF)越高、逆文档频率(IDF)越大,词的权重越高。新闻关键词提取的研究中,TF-IDF 也是三类主流算法之一,常被用来与 TextRank、LDA 对比或融合。print(f"文档{i}:", [(feature_names[j], round(row[j], 3)) for j in top_idx]):理解“一个词在本文档中重要,但在整个语料库中不常见,才可能是主题词”,并用。text = """这里放入你的中文文本,可以是新闻、评论或文档段落。

2026-10-26 11:30:34 196

原创 批量处理与结构化输出(从脚本到可用工具)

OCR 返回的文本块往往不是按人眼阅读顺序排列的。EasyOCR 的 bbox 是四个点的坐标,可以取左上角 y 坐标进行行分组,再按 x 坐标排序,从而恢复“从上到下、从左到右”的顺序。:坐标排序、置信度过滤、按业务规则校验(如金额用正则提取、日期格式统一)。# bbox 格式:[[x1,y1], [x2,y1], [x2,y2], [x1,y2]]:处理文件夹里的多张图片,把 OCR 输出的“一堆文字”变成按坐标排序、可导出为表格的结构化数据。

2026-10-25 23:18:32 165

原创 预处理与参数调优(让识别率从“能看”到“可用”)

OCR 输出里的置信度分数是调优的重要信号。低于阈值的识别结果,与其硬用,不如标记出来交给人工复核。参数控制页面分割模式。如果只识别单行(比如身份证号、金额),用 psm 7;如果图片是稀疏的界面截图或小票,psm 11 往往更稳。灰度化、去噪、二值化是最基础的预处理组合,能显著提升 Tesseract 等传统引擎的识别率。:解决第一期遇到的“明明人眼能看清,OCR 却认错”的问题。# 放大:小字变大字,对 Tesseract 尤其有效。同一张图,预处理前后、PSM 不同取值下的结果可能天差地别。

2026-10-25 23:16:50 195

原创 选型与快速跑通(Tesseract / EasyOCR / PaddleOCR)

Tesseract 是老牌开源引擎,pytesseract 只是 Python 封装,需要先安装系统级的 Tesseract 可执行文件。Windows 上安装后如果不在 PATH 中,需要手动指定路径。如果主要处理中文文档、票据或表格,PaddleOCR 在中文场景下的准确率通常更有优势。如果不想折腾系统级依赖,EasyOCR 是更省事的选择。第一期先跳过预处理,直接调用封装好的库,感受原始输出。第一期建议先用同一张图在三个库上都跑一遍,直观感受速度与准确率的差异,再决定后续深入哪个。

2026-10-25 23:11:33 133

原创 从零到可用的txm记忆库——完整工作流与长期维护(三)

这里有一个容易踩的坑:项目设置中的“记忆库最低匹配率”和预翻译设置中的“最低匹配率”可能不一致,系统以两者中更高的值为准。的源句段,如果记忆库中存储的译文丢失了对应的占位符或标记,应用该译文后,生成的文档会出现变量不填充、加粗范围错误等问题。建议在导入后、正式使用前,专门筛选出包含标记的TU,人工确认译文中的标记位置与原文对应。更隐蔽的情况是:自动对齐算法基于标点符号和段落结构工作,当原文和译文的段落切分习惯不同(英文倾向长句,中文倾向短句),或者存在大量列表项、表格单元格时,自动对齐的准确率会显著下降。

2026-10-22 09:19:33 81

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除