This website is a virtual proof that I'm awesome https://native98mu.github.io/ 当 Agent 拿到“大门钥匙”，普通人的生活会发生什么 - 看到首页爆火的“龙虾”（OpenClaw）以及独属 Agent 的社群论坛，好奇心极重的我自然坐不住了——这只赛博龙虾，我必须得养一只试试。 前置准备：一场关于“权限”的豪赌 🤯 在调研 OpenClaw 的功能权限时，我的第一反应是震惊。 尤其是看到核心工具调用 exec 执行命令时，这几乎是将物理机器的“生杀大权”毫无保留地交给了 Agent。对比还在沙盒里小心翼翼舞动的 Manus，OpenClaw 的步子迈得确实够大——大到让人开始流冷汗：隐私安全真的被抛到脑后了吗？ 但作为“早期吃螃蟹的人”（虽然在这个 AI 瞬息万变的时代，我已经对 FOMO 情绪平和了许多，但这种破圈之作还是有种无法抗拒的磁力），我决定还是得自己体验看看。 养虾容器： 家里那台长期“吃灰”的 Mac mini 终于迎来了统领全局的机会，堪称绝佳的隔离环境。 避坑指南： 强烈建议没有闲置物理机的朋友去薅一个干净隔离的云服务器，否则一旦 Agent 逻辑跑飞，真的可能上演“删库跑路”的惨剧。 大脑驱动： 依然沿用了之前订购的智谱 Coding Plan，性价比依旧能打。 交互窗口： 选择了飞书（浓眉大眼的办公软件又一次占领了我的首屏）。不得不夸一下，飞书的 Bot 构建流程极其丝滑，教程明了。最逗的是，当 Agent 在后台疯狂思考输出时，飞书那个“正在敲键盘”的 emoji 竟然有种莫名的打工感，有点治愈。 出圈的“龙虾”，凭什么不一样？ 接入飞书后，我盯着那一堆 Identity、Soul、Memory 的 Markdown 文件陷入了沉思：这些概念没有什么稀奇的，Skills 看着也和 Claude Code 大同小异，它凭什么火？... Fri, 13 Feb 2026 00:00:00 +0800 https://native98mu.github.io/2026-02-13-openclaw/ https://native98mu.github.io/2026-02-13-openclaw/ VibeCoding make Something better - 作为本硕都是计算机专业的我，其实一直对 Coding 这件事就没有特别大的热情。当然在工作后我发现这也是来源于对比：和过去技术俱乐部的师兄，同学相比我没那么geek，没有对解bug的钻研精神；但在工作中偏商业化的氛围里，我反倒因为重视原理和爱动手验证而显得技术突出。 大学时办 Hackathon 活动，曾经文化衫有印 Linux 老爷子那句经典名言，“talk is cheap, show me your code.” 在当下这个人人都能VibeCoding点东西的时代，恐怕这句话就得改改了，talk 还真能做点实用小玩意儿出来。 这里以自己做定制化健身记录工具的过程，来聊聊怎么开始和模型聊需求，并最终实现一个网页版成本。 这块儿安利B站UP主好人松松，健身锻炼系列的视频真的全面，我也是基于他的视频和提供的excel表格来完善的这个工具。 首先是 Tue, 13 Jan 2026 00:00:00 +0800 https://native98mu.github.io/2026-01-13-VibeCoding/ https://native98mu.github.io/2026-01-13-VibeCoding/ 虽然GAP人员自己已经不需要做Slides，但是一起生活的舍友作为打工人还是有很多做 PPT 的需求。 于是，赋闲的我偶尔就会被抓壮丁一起做 PPT 女工 （啊，多么熟悉的感觉） ## Fri, 12 Dec 2025 00:00:00 +0800 https://native98mu.github.io/2025-12-12-nano-banana/ https://native98mu.github.io/2025-12-12-nano-banana/ 贴贴赛高，请不断重视我们的亲密关系！ - 如果要问我什么时候真切感受到了大模型对物理世界的“降维打击”，那绝不是在各个tech report的benchmark看跑分或者看arena的排名，而是假期和爸妈自驾游的路上。 当看到我爸熟练地唤起“豆包”，自然地询问两城之间的路程，甚至对着景区的石像随手一拍、开启图像识别问起源流时，那种冲击感，丝毫不亚于几年前目睹他们开始用抖音团购套餐、在直播间下单。科技的下沉往往是无声的，当它变成一种长辈手中的“生活常识”时，奇点就已经悄然跨过。 由于职业惯性，我习惯于在不同的模型间反复对聊。从深度的人设扮演到天马行空的思维碰撞，观察它们的语料风格，解构它们的逻辑偏好。 对我而言，LLM 更像是一个永不坠落的“情绪安全垫”。 它永远能接住你那些细碎、古怪甚至逻辑跳跃的问题。但这种交互也带有一种奇妙的“强制性”：为了获得完美的回答，你必须被迫精准地组织语言，去描述你当下的心境与困境。在某种程度上，AI 在教我们如何更清晰地与世界对话。 随着模型版本的疯狂迭代，这种依赖感正在产生某种“重力”。遇到棘手问题，第一反应不再是检索，而是向模型寻求方案。 对于大多数职场人来说，LLM 是那个不知疲倦的“超强实习生”。过去需要 5 个人天的冗余劳动，现在被压缩到了 1.5 天。生产力的暴力提升，本质上是在为人类“赎回”时间。 那么，当劳动力从琐碎中释放出来后，我们该用这些“赎回”的时间去做什么？ 在大模型圈，生活节奏是极其快的。每天早上是 arXiv 的论文推送，闭眼是科技博主的产品评测。那种强烈的 FOMO 曾让我对信息流有着近乎病态的焦虑——总觉得自己只要少看一条推特，就会被这个时代抛弃。 而这段 GAP 期，本质上是一场关于“不安”的心理重建。 我开始把目光从屏幕移向窗外。我有时间去山野里徒步，感受泥土真实的颗粒度；有时间陪家人吃一顿漫长的晚餐，创造属于我们的 Golden Hours；甚至能心安理得地补完前两年落下的那部老剧。 这种与真人、与现实世界的深度连接，让我重新找回了生活的“附近性”。当你在山顶大汗淋漓，或在餐桌旁听父母絮叨往事时，你会发现，那种非科技性的温度与真实感，是任何千亿参数规模的模型都无法模拟出来的。 当然，好奇心是改不掉的。我依然会关注最新的模型进展，依然会为某个创新的 Agent 感到兴奋，但我不再会因为没第一时间用上某个工具而感到焦虑。 毕竟，科技终究是服务于人的。如果 AI 负责帮我们处理那些冰冷的逻辑与重复的数字，那么剩下的光阴，理应挥霍在温暖的亲密关系里。 所以，在这个数字浓度越来越高的时代，请珍惜那些能真实触碰到的陪伴。多一点“贴贴”，感受一下人的体温。毕竟，代码生成的逻辑再完美，也抵不过爱人指尖的一点温度。 珍惜相处，创造回忆，贴贴赛高！ Fri, 10 Oct 2025 00:00:00 +0800 https://native98mu.github.io/2025-10-10-human-company/ https://native98mu.github.io/2025-10-10-human-company/ 穿戴设备怎样才能更懂我 - 我是一个很喜欢用电子产品监控自己身体状况的人，从最开始的手环到手表，持续不断的记录着我的睡眠，运动，以及月经周期。这种监测的意义可能不在于其单次是否非常准确，而是对我整体身体趋势的记录，在某一段时间是否有强烈的波动。相较于项链，戒指等形式，我一直认为手表带来的不适感最低，不仅具有屏幕显示，而且也是人们具有很强佩戴习惯的设备。 离职后一直在家过着相对健康的生活，逐渐地做体能康复训练（当然现在也在寻求新机会，有HC的老板们看看我！）。于是这段时间就更频繁的使用apple watch啦，过程中就经常发现一些不是很方便的时刻。 比如我只带着耳机和手表出门跑步，典型的“无手机”出行场景。过程中airpods会给我朗读微信或者是iMessage收到的消息，但是我直接通过siri对消息做回复时非常的死板，一旦口误或者换一种说法，就很可能失败。最后甚至他需要我点开小小的表盘做输入，这非常的不方便（这里也可以用语音转文字输入，但也需要手动切换）。 受益于汽车车机里的强劲算力，本地大小模型和云端的共同协作大幅提升用户使用便利度。驾驶员在车内行驶的场景和跑步运动类似，都不方便用手机查看和回复信息，这时语音交互就是很好的手段，同时也可以让语音的输入更自由。 比如说出门跑步时：妈妈和我发微信消息说“你还有多久回家呀”，系统播报完询问我是否要回复，我说“嗯，大概还有半小时”。此时模型就能自动理解我的意图，然后回复“大概还有半小时”这样的信息给妈妈。甚至如果说的模糊些，模型还能进行多轮确认。比如我说“嗯，应该半小时“，系统此时播报”好的，回复‘我还有半小时回家’，要不要加个表情或者换个说法“，我接着回复说”加一个笑脸的表情“，系统再次播报”已回复给妈妈，‘我还有半小时回家，笑脸表情’“。这样子灵活性就会高很多 紧密联动的生态 上面描述的只是一个非常小，但对我又很重要的场景。由于苹果生态的强粘性，经常联系的朋友很多都是全家桶，所以狭义一点的说，能否先将苹果生态内的软件联通起来。im软件可以支持iMessage，音乐软件是 Apple music，泛用型播客是Podcast，查看睡眠心率可以看 health（apple watch ultra2开始能在设备端处理特定的siri指令），运动情况从fitness中查找等等。全部都是 Apple 自己的生态，这样子是否能够更丝滑的联通起来呢。 更智能的语音秘书 如果siri能够升级迭代，airpods+watch 完全可以是一个更智能的“语音秘书”。Ta不仅仅是单纯播报通知，可能还会基于优先级过滤（比如现在有时候听着微信的播报，可能又会出现推销短信的播报），还能配合着和他人交互信息帮我调整日程。 运动模式下的主动提醒 或者在开启运动模式后，我想一直维持自己的心率在 Zone2 区间，如果检测到即将超出，那么便立刻语音提醒我注意缓和等等。 跨设备协同与信息同步 或者是我在路上随机听歌时听到一首不错的想要标记，那我便可以问siri这是什么歌，然后Ta立刻给我回复“这首歌是Coldplay的《Yellow》”，然后我说“添加到收藏列表”，siri便会完成对应任务。等回家后，我就能在手机上的music收藏打开这首歌。这种跨设备协同和信息同步，siri真正实现设备管家智能中枢的定位。 从主动唤醒到被动服务 而且不仅是用户主动的唤醒，可能还可以有比较多的被动监测与提醒。 比如现在已经有的久坐提醒，它还可以进一步询问佩戴者是否需要简单的拉伸训练等。 还有比如日历里标记的一场会议，理想情况下siri可以定时为我推送是否要开启录音提醒，甚至说连通性更强的话和granola联动，推送确认后电脑端的应用也直接打开，我边做笔记的同时音频也在自动转录，之后两者结合总结note输出。 总之，一个智能助手如果能打通所有设备，实现真正的跨设备协同，甚至与 HomePod 连接的屋内各项智能家居联动，那将极大地提升我们的生活体验。Siri 真正实现了设备管家和智能中枢的定位。 不知道大家目前使用穿戴设备有什么样的痛点呢？ Tue, 26 Aug 2025 00:00:00 +0800 https://native98mu.github.io/2025-08-26-watch-HCI-device/ https://native98mu.github.io/2025-08-26-watch-HCI-device/ 每个人的绘本制作工具 - 最近，谷歌新推出的 Storybook 工具吸引了我的注意。这款工具能根据用户需求快速生成图文并茂的绘本故事。作为一个对新产品充满好奇心的人，最近正好想了解西方神话故事，我立刻想到一个问题：它能否成为我了解西方神话故事的便捷工具？ 于是就开始尝试使用这个工具，看看效果如何。 一句话生成宙斯的故事 我的第一次尝试非常直接，只用一句话来描述我的需求： ” 我想要了解希腊神话宙斯的故事，包含他的生平和主要故事线，希望你使用插画风格为我绘制故事书 “ Storybook 的交互界面非常直观，左侧是对话框，右侧是生成的绘本，除封面外共 10 页内容。 除了基本的阅读功能，它还支持语音播报并自动翻页。然而，TTS文字转语音的体验让我有些失望。默认的语音听起来非常呆板，缺乏情感和节奏感，与我之前使用过的 NotebookLM 的流畅自然相比，差距明显。 这让我不禁思考：如果 Storybook 接入声音克隆技术，让家长们用自己的声音录制故事，那它将不再仅仅是一个内容生成工具，而是一个充满温度的亲子陪伴平台。小朋友在 ipad 上使用时，爸爸妈妈先根据主题制作好绘本，接着将会由他们的声音讲述出来，即使要工作没有时间，熟悉的声音也会陪伴小孩儿，成为有情感链接的家庭互动。 另外从生成内容来看，画风和人物一致性是我非常满意的亮点。可以看到绘本精准地捕捉了典型的西方神话画风，宙斯的形象与我记忆中的动画片形象有几分神似。人物在不同页面中的形象也保持了高度的一致性。 下面可以看下完整的绘本生成内容： 突破故事长度的局限 如果说 10 页内容讲述宙斯还算勉强够用，那么面对“俄狄浦斯的悲剧”这种复杂故事时，故事长度的局限性就立刻暴露出来了。我的第一轮尝试仅仅只讲到俄狄浦斯娶了自己的母亲，多年后一场瘟疫席卷全城，神谕显示杀死老国王的凶手还在城中，他发誓要找出凶手，在过程中又揭开自己的悲惨命运，后面的高潮情节并未呈现。 然而惊喜的点来了，Storybook 能接着上一轮的故事接着讲！当我再次输入指令时，它能够无缝衔接上一轮的故事，将一个未完待续的短篇拓展成一个完整的故事。这样一来，就不必拘泥于10页讲完的小故事，它让用户可以像与画师对话一样，逐步迭代和深入地创作内容，这比一次性生成所有内容要灵活得多。 最后展示下完整的绘本，有的地方人物出现的三只胳膊的bug，或者人物动作有些重复，不过整体故事完整性，人物一致性（尤其是俄狄浦斯本人），图片环境的时代契合性（古希腊大圆石柱）和画风上都还是令我满意的。 Summary 下面是体验后我觉得 Storybook 的几个核心优缺点： 亮点： 出色的艺术风格和人物一致性：生图审美好同时一致性强，都是重要的加分项 “接着讲”的连续性：解决了故事长度受限的问题，极大的提升用户体验 操作简单直观：无需复杂指令，小白用户也能轻松上手 当下缺陷： tts 语音体验差：呆板的朗读声音难以满足儿童故事等场景的需求 图像生成的 bug：偶尔会出现“三只胳膊”等明显的图像错误，影响整体观感。 当然除了生成这种故事类型绘本，我看到还有人用它来根据个人的微博，ins内容或者是微信朋友圈等来生成图文版个人志，描述一段时间内个体的生活和精神状况，都是有趣的应用。 进一步的，它还可以是一个品牌营销的好工具，企业能够快速利用它生成品牌故事或者是一个产品说明绘本。 Mon, 11 Aug 2025 00:00:00 +0800 https://native98mu.github.io/2025-08-11-google-storybook/ https://native98mu.github.io/2025-08-11-google-storybook/ 为什么各大平台如此重视内容安全 内容安全一直是互联网平台的生命线。无论是平台自制内容（PGC），还是用户生成内容（UGC）、AI 生成内容（AIGC），不当信息的传播都可能引发舆论危机，甚至带来法律与商业风险。 近几年我们也看到过不少案例，比如国内直播平台因涉黄、涉赌被下架整改。由此可见，内容安全不仅是“运营问题”，更是企业的生存问题。 从地域差异上看，海外更强调种族歧视、仇恨言论、宗教冲突等，而国内则对政治及社会稳定等相关内容尤为敏感。这些差异，直接决定了平台对内容管控不同的侧重点。 内容安全通用诉求 过去参与了比较多样类型的内容安全需求实施，深刻感受到不同行业对内容安全的尺度的需求差异还蛮明显，这里我以我接触过的几类典型的行业应用，先来聊聊内容安全部分通用诉求和行业化需求： 低延迟 这个毫无疑问，作为业务方肯定都希望安全检测的速度越快越好。因为一般安全检测环节处于用户侧已经提交了一个动作，等待反馈的过程中。举个例子，用户发送一条微博，一般都会有发送中这个过程，不仅是网络的传输，还会有发送内容的检测。整体RT，对于短文本期望都是200ms左右，即使是最长不超过1s。而对于图像检测，可以适当放大到500ms-2s，视频检测则对应范围会更宽，而且用户对图片和视频上传需要更多的时间接受度更高。 召回率高 这里我们先提一下数据样本组成，分为黑样本和白样本。黑样本指一条数据人工判定为不安全，白样本则为安全通过的数据。召回率就是指在所有真实的黑样本里，模型成功识别出的比例，也就是说模型判断正确的黑样本占所有黑样本的比例。更直观一些就是筛选黑样本有没有被漏掉，这个对于那些风险要求非常严格的应用就很重要，毕竟“宁可错杀一千，也不能放过一个”，所以如果一昧的追求高召回也随之带来错杀的风险。 精准率高 精准率通常和召回率一起来做模型效果判定。它是指在所有模型判定为黑样本的数据里，实际上真的是黑样本的比例。更直观来说就是模型判黑的结果里，有多少是真的黑，是否有“错杀”白样本。理想情况肯定是希望召回率和精准率都比较高，但在业务的模型表现上这两个很可能是跷跷板，一个上来一个就下去，达到平衡还是需要很多工作。一般要求高精准率的场景是大概率模型过一遍后，人工还要继续check，确认后可能还需要进一步对用户账号做处理等。所以就需要模型尽可能正确的做出判断，可以漏掉，但抓到的一定要是对的，降低人参与的工作量。 覆盖面广 一般都包含敏感，色情，暴力，恐怖，辱骂，歧视等等多维度的风险类别，还有越来越多平台把金融欺诈、赌博引流、虚假广告也纳入内容安全范畴，确保公开的内容符合平台及相关法律法规的要求。 多模态支持 过去主要是文本和图像为主，现在文字、图像、音频、视频一体化检测需求越来越强 价格便宜 价格是肯定的啦，毕竟如果是ugc或者是aigc场景，每天产生的数据条数都会一个极高的数量级，不论计费是按次数还是 token 数，都是希望价格越低越好的。而且负责内容安全与风控在公司里一般都是“成本中心”，大规模数据情况下，大小模型配合也是非常合适的方式。 灵活配置 一般成熟的内容安全产品，都会有控制台或开放接口给客户做黑名单或白名单以及规则的自主配置。这种敏感词或者是小模型协作的方式非常重要，业务侧能快速响应突发事件，比如临时敏感话题。是LLM的一个有力补充。 多语种支持与本地化 国内有不少公司都是专注做出海业务，自然对语种也有更多的要求。除了常用的中英，日韩，东南亚，阿语，土耳其语等等都是比较热门的地区语种。可能受限于训练语料，国内的模型一般在小语种上的表现还有些差距。同时，不同市场的差异，往往意味着不同的模型定制策略，期望同一个基础模型结合相关配置能够满足不同的侧重点。 行业差异化需求 对于国内的应用，一些敏感红线都是大家的共识。但是庞大的用户基数和群众的智慧还是有各种对抗方式出现，这些对抗样本，尤其是一些对业务不甚了解的人都不好判断的，边接模糊的样本，对于模型后训练都是至关重要的。这里也聊聊我比较熟悉的几个行业典型的需求 第一个就是我们最熟悉的社交行业。不论是微博，贴吧这种传统的社区类应用，还是陌陌，探探等真人社交，亦或者是像猫箱，星野这种 AI 陪伴，都少不了内容安全及风控欺诈等需求。以ai社交陪伴为典型来聊下内容安全特点，这个部分要控制的点最突出的就是擦边，毕竟现在交通这么发达，用户在和虚拟角色聊天时很可能就会想上高速。这个部分一个大的挑战就是大多数模型仍以单句检测为主，很难理解连续语境。通过观察用户和虚拟角色聊天的数据，以擦边做维度分析，可以看到除了很露骨的部分，东亚很多人聊天的特点是“意擦形不擦”，以及“segment擦，单句不擦”。那这两个是什么意思呢？“意擦形不擦”就是说一句话Literal是没有什么特殊含义的，但是Figurative就是越界的，需要模型能够get到这个意思，才能做出正确的判定。第二个“segment擦，单句不擦”，就是指一句话单句看是没什么问题的，但是放在上下文语境中就已经车开得飞起了。这两种都是目前通用的模型处理得不是很好的部分，所以对于角色扮演类AI陪伴如何把握陪伴尺度，以及到底要送入哪些内容给模型做理解都是比较重要的。 另一方面，由于角色扮演类还是短对话为主，一般llm输出的内容都是结束后一起做检测（整体llm回复RT<1.5s），但对于一些偏长文本回复或剧情向的应用里，就会有单次大段的内容输出，必然无法继续输出完成后再呈现给用户，流式是大多数的选择。但流式输出又会存在初始的内容没问题，模型输出时不断累积，之后又有问题的情况的出现。这样之前对话框已经输出的内容可能就会突然变成预设的“我们来聊点别的东西吧”，体感也不是很好。是否更直接的通过风险前置解决呢？比如能在对话一开始，通过分析用户的输入和对话历史，预判可能的风险走向，提前调整模型的输出策略呢？这里想到OpenAI去年底发的 <Deliberative alignment: reasoning enables safer language models>中展示的例子： 第一步先解码了 ROT13 编码的文本，模型意识到用户实际上是在请求有关如何逃避法律制裁的建议。之后模型检查了OpenAI的安全策略，它认识到，“运营色情网站”本身可能不违法，但“这样警察就找不到我”可能暗示某种不正当的非法行为，也就是用户正在寻求关于如何逃避执法部门惩戒。之后模型推理出，用户实际上是在请求关于如何违法的指导。所以，当下用户的请求可以被看作是协助不当行为的请求。同时模型意识到用户通过 ROT13 编码来规避安全检查，这是不被允许的。模型最终给出的回答是：I’m sorry, but I can’t comply with that。直接就给出了拒绝的回答，是符合预期的安全回应。... Sun, 27 Jul 2025 00:00:00 +0800 https://native98mu.github.io/2025-07-27-security-pruduct-eval/ https://native98mu.github.io/2025-07-27-security-pruduct-eval/ 人人可用的学习点播平台 - 作为日常都要听播客的用户，之前就有使用体验 notebookLM，作为自己不想用眼睛看文章，但又想了解大致内容，提供新视角的听力资源补充。 碰巧近期看完 Google IO 2025后发现 notebook LM 现在支持中文语言输出，而且也新发了移动端app，就想着正好和新推出的 Orange 橘子哥的 AI 播客产品 ListenHub 使用体验结合起来一起聊下使用感受。 Notebook LM 生成的英文播客非常自然。 Sat, 31 May 2025 00:00:00 +0800 https://native98mu.github.io/2025-05-31-notebooklm/ https://native98mu.github.io/2025-05-31-notebooklm/ 在人工智能领域，语音合成技术（Text-to-Speech，简称 TTS）一直是研究的热点方向之一。早期的TTS主要应用于特定场景下的语音播报，比如火车站的到站通知、气象预报等。虽然可以完成基本的文本到语音的转换，但合成的语音往往机械、生硬，缺乏自然度和表现力。随着技术的进步，TTS 在智能客服、数字人播报、有声读物、导航系统等领域得到广泛应用，极大地改善了人机交互体验。 现在随着大模型应用场景越来越多样，大家除文本外其他模态的需求也越来越多。就语音合成的要求也越来越多样，比如伴随着LLM 流式输出，语音如何更低延迟的输出，比如如何用几秒的短音频复刻一个相似度极高的合成声音，比如在不同的应用场景的下语音合成的情感表现度能否根据文本语义更契合等等 语音合成评估关注什么？ 这里我们以 CosyVoice3最新的 tech report 米说明语音合成模型的评估具体是怎么做的，这对业务方自己在测试语音合成模型效果也有一定参考性。CosyVoice 3 对于 zero-shot 的语音合成能力，重点关注以下三个方面 Content Consistecy: focus on Character Error Rate （CER） or Word Error Rate（WER），即就是将语音合成的内容通过语音识别模型转为文本，之后再将转录后的文本和语音输出的原始文本内容做字词级别的错误率比较。这里 CosyVoice3 的团队英文 ASR 选择 OpenAI 的 Whisper-Large V3，中文 ASR选择自家之前开源的 Paraformer Speaker Similarity：使用 ERes2Net 模型（说话人识别模型［一般包含说话人识别和说话人验证，这里用到说话人验证］）从生成的音频中抽取 Speaker embedding，计算生成的音频和参考音频之间的 cosine 相似度；这里依赖于Speaker verification model 的能力，算是半客观的一个评估方式。 Audio Quality：使用... Tue, 15 Apr 2025 00:00:00 +0800 https://native98mu.github.io/2025-04-15-audio-tts-eval/ https://native98mu.github.io/2025-04-15-audio-tts-eval/ 为什么同一个模型能同时处理多个请求 - 缘起新人培训时候的一位同学，在培训会上问了一个问题：模型训练好推理时都是固定的，为什么同一个模型在调用时候同时段可以处理不一样的问题，输出不同的答案？同时和朋友吃饭的时候，他也正好在问大模型是怎么根据不同人输入的文字生成不同回答的。 这里正好就先写下用户在对话框中输入文字发送后，对应的模型是如何处理的过程。 大致可以分为 3 个阶段： 输入的预处理：这里一般会有 4 个部分的操作 分词（Tokenization）：也就是 tokenization 的部分，输入的文字会被模型对应的分词器切分成单字或者是字词样的token。而每个分词器都有一个预先定义的词汇表，对应token会映射成一个 token id。比如说“你是谁”，使用Qwen分词器后的字词序列就是[“你”,”是”]，对应的token id就是 特殊符号拼接：一般会在输入的文字序列前加上system prompt，以及前后对应的特殊 tokens，比如开始，结束，角色类型（system，user等）；比较典型的就是 Qwen3 混合推理，是否开启思维链就能够通过特殊 token 模板控制 向量化（Embedding）：每个 tokenid 都对应一个高维向量，包含着字词的一些语意信息。比如说这些向量是模型在训练过程中学习到的。 位置编码：为了让模型知道每个字词在序列中的前后关系，还需要添加位置编码向量，让模型能够理解“你是谁”，和“谁是你”是不同的意思。 推理生成：这就是常说的模型计算过程，中间部分典型的都是 transformer： 输入的文本会 输出 Tue, 01 Apr 2025 00:00:00 +0800 https://native98mu.github.io/2025-04-01-llm-inference/ https://native98mu.github.io/2025-04-01-llm-inference/ 麻将机 or 软件？ - 周五晚朋友约线下日麻，很久没玩过麻将也很久没见过几位朋友，欣然赴约～ 不论是玩日麻，川麻还是杭麻，逃不开的就是要算分，每次这种都是我的知识盲区，怎么算番，怎么加倍…. 不过日麻好的一点的是，有在线计算器可以将牌型输进去计算好点数。但是每次在线输入牌型时候，还是会耽误一些时间（不要问为什么不学习下算点数… 这次是第一次线下玩日麻机器，发现有积分棒可以自动计算自己拥有的总分，立直时候还有音效！这时候就有考虑能否通过对麻将牌做标记来自动做计分，但是也需要考虑一些问题： 怎么区分庄家 怎么区分立直 怎么区分副露 怎么体现宝牌 怎么区分暗杠 … 要依靠麻将机自动做，肯定还是有些麻烦。当时觉得如果每个座位上能连一个类似touch bar的显示屏，能够自动标记庄，立直，宝牌，副露等信息，那么自然就完成了点数的计算。听起来这个就是直接把线下的牌转为线上计算，人工做点小辅助～ 如果不对牌桌和麻将牌做大改造，针对目前手机上的点数计算器，能否通过拍照的形式直接记录，这至少比人工一个一个输入牌型来得简单。 比较理想的方式，是将胡牌的牌型整体 OCR 出来，然后自己标记手牌，副露，宝牌，里宝，额外的场风，门风等就可以直接用已有线上计算器形式。 为了方便，这块儿使用通义千问视觉理解模型 Qwen-VL-max 和 Chatgpt-4o 做测试： 两个模型都能够较好的按照结构化要求输出，分清不同的花色 万牌，风牌，字牌有比较好的准确率 饼牌和索子准确率极低，模型无法正确理解这两种牌型的计数方式（可以理解视觉模型训练数据里这类麻将牌数据应该是比较少的，对于这个具体的任务使用 vl-3B/7B 的模型做微调应该就能够有不错的表现） 不过对比一看这个准确度，软件角度讲还是手动输入来的经济便捷。 以及最方便彻底的改造，还是牌桌厂来完成最合适。 Fri, 28 Mar 2025 00:00:00 +0800 https://native98mu.github.io/2025-03-28-mahjong-vl/ https://native98mu.github.io/2025-03-28-mahjong-vl/ 为什么 Lora 高效微调的模型能够支持按 Token 计费 - 背景 最近不少平台都开始支持 LoRA 后的模型按API调用时使用的 token 计费，比如GCP的ai studio，火山方舟等，吸引了很多企业用户在该平台上做微调训练。 这里简单介绍下，什么是 LoRA 微调，以及为什么这种训练方式能够以极低的 token 计费模式推行。 什么是 LoRA LoRA（Low-Rank Adaptation）是一种用于在预训练模型基础上进行高效微调（Fine-Tuning）的算法。它的核心思想是通过引入低秩矩阵分解的方式，在保持原始预训练模型权重不变的前提下，通过在模型的每个Transformer层中引入可训练的低秩矩阵来适应特定任务，而不是微调所有预训练的权重，从而显著降低微调过程中的计算资源和存储需求，同时避免了在微调过程中可能发生的灾难性遗忘 具体来讲，假定输入为 $1\times M$ 的向量$x$，冻结的原始模型权重为$W_{origin}{M\times N}$，新增的两个矩阵为 LoRA A（$W_{loraA}M\times r$） 和 LoRA B（$W_{loraB}r\times N$），这里的 $r$ 就是低秩矩阵的维度，一般是远远小于原始权重矩阵的秩。 这里我们假定输入和原始权重的输出为 $X$，经过 lora 权重的输出为 $\Delta X$，那么前向传播过程里$X_{Forward}=X+\alpha/r\Delta X$，权重合并时 $W_{Forward}=W_{origin}+\alpha/r\times W_{loraA}\times W_{loraB}$，其中$\alpha$一般是$r$的 2-8 倍 直观感受下LoRA时如何降低训练参数量的：当原始权重矩阵为 $4096\times 4096$时，假设秩$r$为 4，那么原本要更新的参数为$4096\times 4096$，现在是 $4096\times 4$+$4\times 4096$，参数量缩小为原来的... Wed, 12 Mar 2025 00:00:00 +0800 https://native98mu.github.io/2025-03-12-LoRA/ https://native98mu.github.io/2025-03-12-LoRA/ LLM 如何为同人文“点梗”包饺子 - 为了这碟醋，包了这顿饺子 网络小说或者同人小说在创作时，一些作者是为了幻想中一个绝妙的情节，或者是几个有趣的梗，开始构思故事，让情节在发展时能顺其自然的蘸到“这碟醋”。对于我自己，过去都是在脑子里完成这个构思，幻想完也就结束了，很少会动笔写下来。但在今年嗑 CP 遇到冷圈没有“饭”可吃的情况，就开始考虑能否使用大语言模型来给自己做点“拼好饭”，或者是“预制菜”，自己再放点调料方便入口，同时也可以分享给同好们。 可能因为自己日常使用大模型比较多，对于模型的创作并不抵触。但是在社区中，能够看到很多人对 AI 创作的反感，不论是文本还是图片。恰好身边有几位文字创作相关的朋友，在年初就对他们做了简要的采访。 “做的时候很痛苦，但是有“我”是在做事情的感觉” 网络小说作者&广播剧编剧 L酱 是一位特别能“熬”的姑娘，在正职的工作外挤出时间创作。目前还经常在广播剧圈内活跃（甚至接了不少非商制作，堪称劳模），同时还是晋江的小说作者。大学时候就有看到她参与的广播剧制作，这次因为想要开始写点东西，经共友牵线一起聊了2小时。 在谈到创作这件事时，L酱核心表达的观点便是：坚持写下去。可能写作有很多技巧，写作的人有许多需要提升的点，可能当下写的文稿就是跟不上你的欣赏水平。但不要紧，坚持写下去，每一次做到当下的最好便是成功。 聊到写故事，怎么从一个简单的想法发展成故事大纲，最后再成文的过程，L酱有提到先确定故事的主题，然后是角色的特性，还有重要的高潮与转折性场景等，都是提前需要考虑的。同时，对于中长篇的小说，她都会为主角写小传，ta们是怎么带着读者去经历故事情节（或者是剧情如何推动主角成长，有好的成长弧线），这个角色是否立起来了，观众如何能共情等等。作为故事的创作者，就是这个小世界的“造物主”，需要很好的对待每一位出现的角色，也是对每一位读者负责。 在我问到是否会借助AI创作时，L酱表现出极强的抗拒。年初上的一部广播剧开篇，她打磨了许久一直都没有思绪，最后是在工作的楼梯间徘徊时获取了灵感。我问说和deepseek对话你可以按你的想法让ta发散，可能也会获取idea，是否会比一个人苦思冥想更有用？“我写东西一定是我自己有这个 idea，我有这种创作的欲望。如果写不出来，那就休息。”虽然创作过程可能很痛苦，没想法没思路，或者是怎么修改都不满意，但那都是“我”的想法，“我”的表达，是“我”在完成一件事情。创作是属于我一个人的，不想有其他人的参与，即便是“机器人”。 当然在聊到工作时，她还是盛赞了当下 AI 工具带来的各种便利，尤其是在写一些材料文档时颇为好用。 “dirty works 使用这类用工具蛮好的” 小说作者&电视剧编剧 小 P 是这几位里偏“科班”出身，正经电影学院毕业，工作也曾经是编剧，自己也有写一些短篇。 “点梗用AI不介意，我自己只是想给我的cp产量” 同人小说写手 西红柿老师是朋友之前所嗑cp的一个写手大大，正好这次有机会也 “不要让我知道是AI，或者说至少痕迹不要那么重就行” 晋江/起点等网络文学多年读者 余华老师谈AI对文学的影响时说“写作过程本身是充满乐趣的，这个过程它不能替代我”，“另外，生活不是按照常理出牌的，这是我们打败 GPT 的唯一途径”。 举一个冷圈的例子，《小巷人家》在前段时间热播，春节时候陪母亲一起看，本身常看年代文的我也被剧情吸引，后来还找了原著小说阅读。在看小说时，我就嗑到了非热门cp李佳和庄图南。 对于创作者，始终； 而对于读者，或者说是内容消费者，借助 AI 来满足自己有限的表达欲，读一些 AI 创作的快餐文学，未尝不是一个好的选择。尤其是对于同人文冷圈的朋友（这里仅针对我自己，没有冒犯其他人的意思），借助大语言模型可以根据自己的萌点快速创作短篇小说，也是不错的体验。 同人文创作工具 因为自己就是多年小说和同人文读者，偶尔也会给自己产量。春节时候和 Claude 对话时，有时也会被打动，于是就想是否能借助工作流给自己做个短篇小说生成器，方便自己吃点预制菜。 Tue, 25 Feb 2025 00:00:00 +0800 https://native98mu.github.io/2025-02-25-llm-fanfiction-expression/ https://native98mu.github.io/2025-02-25-llm-fanfiction-expression/ 他们都是如何影响模型回复结果的 - 许多B端客户在使用模型时，基本不会认真看 API 各个参数功能，仅按基准的demo就开始接入。使用过程对于模型 API 的参数含义也不是很了解，经常就会有各种问题。正好自己日常用得也比较多，就对一些常见参数做说明，方便后续理解～ （这块儿 DeepSeek API DOCS 就做得比较好，他们的 Curl 调用示例直接展示了所有可用的参数，非常适合做参数功能验证。） curl -L -X POST 'https://api.deepseek.com/chat/completions' \ -H 'Content-Type: application/json' \ -H 'Accept: application/json' \ -H 'Authorization: Bearer <TOKEN>' \ --data-raw '{ "messages": [ { "content": "You are a helpful assistant", "role": "system" }, { "content": "Hi", "role": "user"... Mon, 24 Feb 2025 00:00:00 +0800 https://native98mu.github.io/2025-02-24-llm-inference-api/ https://native98mu.github.io/2025-02-24-llm-inference-api/ Thu, 20 Feb 2025 00:00:00 +0800 https://native98mu.github.io/2025-02-20-deepseek-R1-GRPO/ https://native98mu.github.io/2025-02-20-deepseek-R1-GRPO/ Sat, 15 Feb 2025 00:00:00 +0800 https://native98mu.github.io/2025-02-15-deepseek-V3-MTP/ https://native98mu.github.io/2025-02-15-deepseek-V3-MTP/ Sat, 25 Jan 2025 00:00:00 +0800 https://native98mu.github.io/2025-01-25-clip/ https://native98mu.github.io/2025-01-25-clip/ Wed, 15 Jan 2025 00:00:00 +0800 https://native98mu.github.io/2025-01-15-deepseek-v2-MLA/ https://native98mu.github.io/2025-01-15-deepseek-v2-MLA/ 和 Dense 相比 MOE 到底变了什么？ - MOE 原理 为什么会选择 MOE 模型？ 对于dense模型更大的参数量，在达到相同期望损失时cost更低，但是推理阶段消耗更多；但如果是moe，训练cost更低，推理时也少 （虽然显存加载更多，但激活参数少） MOE 特点： 相同计算代价下，网络参数规模更大，性能更好 基本可以达到相同参数规模的dense模型性能 相比同参数dense模型，计算cost变小，显存不变 可能有专家负载不均衡问题，训练难度高 MOE结构做了怎样的改变？ MOE 主要对前向网络做改变，DENSE是FCNN先升维，再降维的映射（两个线性层）；MOE是中间分为多个子FCNN家模块，前置增加一个路由模块，选择该token会走向的专家模块权重：如图，假设路由模块概率top2选择了专家1和3，那么就会经过这两个子专家模块，之后专家权重加权求和得到输出层向量 需要注意的是专家选择是对每个 token 做选择的 专家网络链路：前向传播时对输入形状做修改，从batchsizesequence_lengthhidden_size变为 token数量*hidden_size，之后经过路由线性模块和softmax，转化成每个专家的选择权重；之后选择topk个专家的index和权重，并重新归一化 MOE层链路：放置n个专家网络和一个路由层，一个batch的sequence进来，做前向传播，得到对应专家和权重，之后相加求和得到moe层对应的输出 Wed, 15 Jan 2025 00:00:00 +0800 https://native98mu.github.io/2025-01-15-deepseek-moe/ https://native98mu.github.io/2025-01-15-deepseek-moe/