周日志

汇报前

汇报PPT已经做好了，一直在等待汇报的时机。与此同时，团队正在进行的工作有：

• 研究开源私有大模型部署、微调、配套等工具的使用；

• 研究知识库构建的向量检索方案实现，结合RAG技术路线同步考虑；

• 研究搭建AI工作流的工具；

• 安排后续与其他厂商的合作交流事项。

内部推动新技术发展与外部的行动策略大有不同。内部以论证为优先，论证得足够清晰，并往上能引发更多共鸣才有可能立项推进。外部以行动为优先，无须过度论证要做的事，而是要尽快形成作品并发布出来，能否赚到钱都是无所谓的。

我希望可以将两者结合起来一起做，既要持续发布作品，又要持续论证作品是否有潜力成为未来的产品。这会引发作品不断被上层各种judge or criticize，但其实不要紧，更重要的是从这些评论里面听到更多的潜台词。

个人埋头做作品，除了使劲儿干，还要稍稍考虑如何放大你的作品。比如在即刻找到发布作品的圈子，或者小破站也可以。又比如参加比赛去赢得荣誉。又比如上product hunt……等等。相比于天天FOMO搞这搞那，还不如做个愣头青，想好了要做就至少干出来一个里程碑，期间尽可能让自己“闭关”。什么都能耽误，你的作品耽误不起。

而放到内部而言，同样可以埋头干作品，但也要放大声量，以前所未有的方式去将「成果」更加频繁地展示出来，这同时也是一种有效的向上管理方式。

通过官方教程文档就可以快速部署起来一个ChatGLM3-6B的聊天对话框，4080单卡单用户测试效果非常不错。ChatGLM官方文档相对齐全，因而也无需在此过多分享。

RAG检索增强生成已将刚起步的向量检索方案纳入整体工程解决方案考虑之上，因此后续都将统一归于RAG范畴。

RAG已被证明可以显著提高答案准确性，减少模型幻觉，特别适用于知识密集型任务。通过引用来源，用户可以验证答案的准确性，并增加对模型输出的信任。它还促进了知识更新和引入领域特定知识。RAG有效地将LLMs的参数化知识与非参数化的外部 知识库相结合，使其成为实现大型语言模型的最重要方法之一。

因此RAG应作为大模型主要的基础配套组件来考虑，并且从一开始就采用与微调相互结合的模块化RAG。模块的划分原则是面向RAG过程定义的，分别要搜索，内存，额外生成，任务适应，对齐，验证等。

AI工作流看起来跟以前玩得很多的ETL有很多相似之处。模型在其中就像是一个通用算子，可以用来完成各种各样的操作，如果类比过来理解，应该算是其中一种transfer组件。而其他的组件则一样可以借用ETL的概念来理解，比如说ETL中的Source通常指的是结构化/非结构化数据源，那在Flow类工具中，这些Source就有各种搜索引擎的接口，文档读取器，或者是用户输入。Transfer类对应了各种各样的Tool或被称为Plugin的东西。Target类则对应了你所需要的最终输出物。

这是一种低代码/无代码的工具，而这样的工具在某些场景下很容易会陷入小白不愿意学，程序员干脆写代码的尴尬局面。因此我认为这是一个需要谨慎介入，或者是低成本投入的领域。对于小白而言，除非你可以直接通过文字让大模型生成一个完整的工作流，否则学习成本就太高，看着就不愿意学。对于程序员而言，需要提供足够的透明度，让他们可以对其进行各种微调。因此，可能像GPTs目前的形态是更为理想的。

市场产品：

• DataCrunch做的takomo.ai

• 据说是字节做的coze.com

开源方案：

• langflow

• FlowiseAI/Flowise

汇报后

终于汇报完毕了，悬在心上的石头落地，效果超出预期，要感谢团队的通力合作。也庆幸当初没有被反对意见驳倒，坚持在汇报的同时发布了团队干出来的一个小产品。GPT时代，产品虽小，但要切中要害更加重要。任何人都可以给你的产品提一大堆的意见，如果产品经理没有定力，不会自己去做判断，那只会做出来一个三流作品。真正好的产品，往往思考的是不做什么，而不是一味地追求要做什么。就好像使两个变种成为两个物种的，不是存在某种东西，而是不存在某种东西。你需要辨识出来，许多反馈意见中所隐含的，往往只是中间过渡类群（通常也会被称作垫脚石），但这些中间类群最终也都会灭绝掉，只留下事实上永远分隔开的两个类群。

团队因为其他已有合同生产项目的影响，被调走了大量劳动力，我心里当然是不太好受的，但也只好硬扛着。幸而大模型才是人心所向，所以小伙伴们依然倾向于主动做事，而不是等待安排。

我选人用人的标准也是如此，往往是看这个人到底主动做了什么事情，而不是看TA被安排了什么任务。前者即便做得不好仍可继续重用，后者即便是做好了也可能是违心之举。因而那些主动做事的人也能拿到更多主动权，他们可以选择想做之事。那些被安排的人，可能是自己没想好要干嘛，也可能是过于被动，总想要别人带着做。但在一个创业团队之中，每个人都有自己的一摊子事，几乎没有带人的余裕。所以被动者没得选择，就只会被安排到那些看似他们更擅长，实际上他们并不愿意干的事。

我们经常在讨论数字化与大模型之间的关系，其中争论最多的是到底是要先完成数字化，还是先用上大模型。然而我认为这其实没什么好讨论的。大模型作为IT基础设施之一，本来就应该包括在数字化的一整套工具集当中。而且数字化压根就没有什么“完成”的时间节点，因为本来就是渐进式的，只要你有钱，数字化没有绝对的上限，只有相对的高低。

那么，用上了大模型技术就意味着数字化程度较高吗？这么说也不对。除了组织内部系统的数字化程度，隐含的还是这个组织的人本身的数字化程度。如果一家公司里面的人沟通习惯依然是打电话和发邮件为主，工作习惯依然是Office文件发来发去，所有的过程/结果文档依然是通过大量人工完成。那即便上多么fancy的系统，对他们来说也是没有意义的。

但大模型本身所自带的多模态属性，却可以让某一个内部数字化系统/产品的用户学习成本无限接近于零。因此，如果你也认为所谓数字化无非就是企业内部工作自动化/智能化的话，那么大模型技术实际上是所有数字化进程的加速器，而不是一个最后才拿来锦上添花一下的东西。

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