周日志

汇报前

汇报PPT已经准备就绪，只等一个合适的时机。与此同时，团队这边也在同步推进几项核心工作：研究开源私有大模型的部署、微调和配套工具；探索基于知识库构建的向量检索方案，并结合RAG技术路线进行通盘考虑；搭建AI工作流的工具；以及安排与外部厂商的合作交流。

在内部推动新技术和外部搞事情，策略确实不太一样。内部做事讲究“论证优先”，你得把逻辑讲透，让决策者产生共鸣，项目才有机会立项。而外部更强调“行动优先”，不用过度纠缠于论证，关键是把作品做出来、发出来，哪怕短期看不到商业回报，也值得一试。

比较好的做法，是把两者结合起来：一边持续发布作品，一边同步验证它未来有没有成为产品的潜力。这样一来，作品难免会被上层反复审视甚至批判，但这其实没那么可怕——真正重要的是，从这些反馈里听出弦外之音。

埋头做作品当然没问题，但除了死磕，也得想想怎么放大它的影响力。比方说，在即刻、B站这些平台找到合适的圈子去发布；或者参加一些比赛，刷点存在感；又或者上Product Hunt……与其天天焦虑“别人都在做什么”，不如认准一个方向，至少先把里程碑立起来。期间该闭关就闭关，别的都可以耽误，但你的作品耽误不起。

放到组织内部，埋头做事的思路同样适用，只是“放大声量”的方式要换一换——用前所未有的频率，把阶段性成果摊开给大家看。这本身也是一种非常有效的向上管理。

通过官方教程文档，我们可以快速在4080单卡上部署一个ChatGLM3-6B的对话界面，单用户测试下来效果相当不错。ChatGLM的官方文档比较齐全，这里就不多展开了。

RAG检索增强生成的方向上，我们已经把刚起步的向量检索方案纳入了整体工程解决方案的考量，后续都会统一归到RAG的范畴里来。

RAG已经被反复证明能够显著提升答案的准确性、减少模型幻觉，尤其适合知识密集型任务。通过引用来源，用户能直观验证答案的可靠性，从而提升对模型输出的信任度。它还能帮助模型跟上知识更新的节奏，并引入特定领域的知识。简单说，RAG把LLMs本身的参数化知识与外部的非参数化知识库做了有效结合，如今已经成为实现大型语言模型最重要的技术路线之一。

所以我们的判断是，RAG应该从一开始就作为大模型的主要基础配套组件，并且采用与微调相结合的模块化方案。模块的划分原则，面向的是RAG过程的各个环节：搜索、记忆、额外生成、任务适应、对齐、验证等。

AI工作流这东西，跟以前玩过的ETL还真有几分相似。模型在里面就像是一个通用算子，可以完成各种类型的操作——拿ETL来类比，它差不多相当于一个“transfer”组件。其他组件也可以用ETL的概念来理解：比如ETL里的Source，对应的是结构化或非结构化数据源；在Flow类工具中，这些Source可能是搜索引擎的接口、文档读取器，或者是用户输入。Transfer这一层，则对应了各种Tool或Plugin。最后Target，就是你想要的最终输出。

这类低代码/无代码工具，在某些场景下很容易陷入尴尬境地：小白嫌门槛太高不愿意学，程序员觉得不如直接写代码。所以，对这个方向需要保持谨慎，或者至少低成本介入。对于小白用户来说，除非你能用一句自然语言就让大模型生成一个完整的工作流，否则学习成本实在太高——看一眼那个界面，多半就劝退了。而对程序员来说，工具必须提供足够的透明度，让他们能灵活地进行微调。从这个角度看，GPTs目前的形态反倒是更理想一些。

市场上已经有一些产品，比如DataCrunch做的takomo.ai，还有据说是字节出品的coze.com。开源方案方面，有langflow和FlowiseAI/Flowise可以关注。

汇报后

汇报终于结束，心里一块石头落地，效果比预期还要好，得感谢团队一起扛过来的日子。也挺庆幸当初没被反对意见带偏，坚持在汇报的同时把团队做出的小产品发了出去。GPT时代，产品小没关系，关键是能不能切中要害。任何一个人都能给你的产品提一大堆意见，但如果产品经理自己没有定力、不会做判断，最终只会搞出一个四不像。真正的好产品，更多是在思考“不做什么”，而不是一味追求“要做什么”。就像生物进化里，两个变种之所以成为两个不同的物种，不是因为有一样东西存在，而是因为有些东西不存在。你需要识别的，是反馈意见中那些隐藏的“中间过渡类群”（也有人管它们叫垫脚石），但最终，这些过渡形态都会灭绝，留下来的才是两个真正分开的物种。

团队因为被其他有合同的现生产项目调走了不少人，说实话心里不太舒服，但也只能硬扛。不过好在，大模型这东西确实凝聚人心，小伙伴们还是倾向于主动找事做，而不是等着被安排。

我选人用人的逻辑一直是这样：不是看这个人被安排了什么任务，而是看他自己主动去做了什么。前一种人哪怕做得不够好，也仍然值得重用；后一种人即便任务完成得很漂亮，也可能是违心之举。主动做事的人，往往能拿到更多的主动权，可以选择自己真正想做的事。而那些总等着被安排的人，要么是自己没想清楚要干什么，要么是过于被动，总想着有人带着走。但在一个创业团队里，几乎没有人有闲工夫去“带人”，所以被动的人往往只会被安排到那些看似更擅长、实则他们压根不想干的活计。

最近团队经常讨论数字化与大模型的关系。争议最多的莫过于：到底该先完成数字化，还是先用上大模型？其实这事真没什么好争的。大模型本身就是IT基础设施的一部分，理应包含在数字化的整套工具集当中。而且“数字化”这件事，从来不存在所谓的“完成”节点。它本来就是渐进式的，只要资源到位，数字化没有绝对的上限，只有相对的高低。

那是不是用上了大模型，就意味着数字化程度高？也不一定。除了组织内部系统的数字化程度，更关键的，是组织里“人”的数字化程度。如果一家公司的员工还是习惯打电话、发邮件，办公文档来回传，所有流程和成果都靠人工完成，那么你上再花哨的系统，对他们来说也只是个摆设。

但恰恰是这一点，大模型的自带多模态属性，可以让某个内部数字化产品/系统的用户学习成本无限趋近于零。所以我的观点很直接：如果把数字化理解成企业内部的自动化和智能化，那么大模型技术其实是所有数字化进程的“翻跟斗”，而不是最后才拿来锦上添花的东西。

记录周期：2023/12/27 ~ 2024/1/13