Saito: 大家好，欢迎收听硬地骇客。我是 Saito。 一啸: 我是一啸。 Saito: 我是归归。本期节目由 Podwise 赞助播出。Podwise 是一款为播客听众制作的 AI 学习软件。产品的 slogan 是 READ BEFORE LISTEN。Podwise 通过 AI 对播客内容进行转录、提取、总结、分析等一系列操作，帮你掰开了、揉碎了、硬核的播客内容。同时与 Notion、Readwise 等平台的打通，嵌入知识管理工作流，协助您的其他包括新闻、newsletter、blog 的内容帮你打造第二大脑。Podwise 也为本期听众准备了三个五折优惠码，针对本期在小宇宙与我们互动的精选回复，欢迎大家踊跃来玩。好的，那开始我们本期的节目吧。最近随着 Cursor 的爆火，Cloud 3.5 Sonnet 的能力也得到了大家的一致认可。现阶段使用大模型似乎有点三国争霸的意思了。你看像 GPT-4O,Gemini 1.5 Pro,Cloud 3.5 Sonnet，从各自公布的这个纸面参数上面来看， 有大家的能力感都在伯仲之间啊。但是从外界的观感上面来说的话，GPT-4.0 肯定是领头羊了，那这个不说了。那 Gemini 现在好像在主打的是长上下文，自己也在吹自己有两兆的 tokens。然后 Cloud 现在感觉上在主打宣传代码能力，对吧？它自己最近也推出了 Artifacts，然后现在对免费用户也开放了。对，那我们今天就来聊聊 Podwise 在使用这些 LLM 的一些最佳实践吧。那今天你可能不会听到什么 CEVAL，什么 CMMLU，然后我们来对比一些这些硬参数，你不会听到这些。对，你只会听到一些给予我们自己的一些经验分享。对，当然如果有任何问题的话也欢迎大家批评指正。好的，那开始我们本期的节目吧。上来我们要不然就开门见山吧。可以给大家分享一下我们 Podwise 当前在使用什么 LLM。然后可以给大家介绍一下我们的使用场景用途之类的。 一啸: 对，Podwise 的使用场景还是属于比较通用的，或者说叫比较大众化的那样的一些场景，主要还是偏向于总结为主嘛。我们的第一个阶段核心就是总结，就是今天大家如果有在使用 Podwise 的话，能看到的那些所有的功能，其实它们都可以被归属到总结这个范畴。那我们的总结其实大家也能看得见， 第一个总结就是能够去分章节，能够去总结章节，然后提取什么关键词，highlight, QA 这些，然后去生成 takeaway，还有生成最后生成 mindmap, 其实所有的这些东西都是总结范畴的，这也是我们第一个阶段，产品阶段完成的事情吧。当然还有一些看不见的地方，在第一个阶段里面，可能我们会用大模型 LLM 去给 Vispro 去生成 Prompt 相关的一些内容。对，这些有很多这种看不见的地方，它可能是属于后台产品的一些支撑能力，它们不是一个直接交给用户去面对的一个产品功能。所以第一个阶段还是以总结为主吧。那第二个阶段是我们正在做并且做得差不多的功能，就是我们想围绕今天的 Podwise 的场景去做一些搜索相关的功能，基于搜索，基于检索这样的结果，然后去回答用户的搜索提问，大家都知道这可能就是一个 podcast 的 perplexity 了，大概就是这样的一个味道。在这个里面其实也有很多就是用户可能会看不见的一些东西，对于查询质量的优化，涉及到什么 Query 的改写， 等等等等。这些可能都是大模型要去做的一些事情。对，但总的来说，用户能够看得见的地方就是基于大模型，然后能够基于 podcast，能够去直接去回答用户关心的一些话题，一些问题。这个角度是我们正在做的一个事情。对我们来说这也是一个很自然而然走到这一步你必须要去做的事情。其实我觉得基于 LLM 去做搜索也好，做检索也好，做问答这一类的产品的功能，我觉得是所有你只要有数据积累到一个程度的产品都一定会去做这件事。不管是企业也好，还是产品也好。这是关于 Podwise 的现有的使用 LLM 的场景和用途吧。大家反正应该也都能够理解得到。另外一个方面，其实我们还在做的一个场景，就是对播客的创作者，就是 creator，我们也打造了一条工作流。那这条工作流，它的主要就是基于音频能够去自动的帮创作者去生成、修 notes 所需要的一些内容，比如说帮你去生成 10 个标题供你选择，帮你生成几份介绍，创作者可以自己去选择。 因为我每次去发播客的时候，其实我要去思考那个标题怎么写，思考开头的那些介绍，特别是你去整理 outline, 这件事它其实是超级费时间的，特别是想标题，想介绍，这种你刚拿到一个音频文件，拿到一份内容，其实你要花大量的时间去思考这件事情。就像之前我和另外一个主播的交流，他每天去写这个介绍，写标题，可能就要写好几份，然后最后还要推翻了又重来又重写，大量的时间效率都花在了这种地方。如果这个时候基于大模型去帮我们去生成，其实很多时候生成 10 个标题的时候，你可能对每一个标题都没有那么满意，但是你会发现当你看过 10 个标题过后，很容易把它组合出来一个你想要的标题。对，就这件事你就会发现非常快，对，只要你给了我四个标题，那介绍也是一样的，我拿到一份介绍过后，它里面可能有个别的词语，或者说叫用词用语啊，语气啊表达，嗯，你不太满意，可能觉得说大模型可能帮你去写这个介绍的时候，在某一句话的一个词语上用的太矫情了，或者怎么怎么样的。那你其实只需要简单的修改一下这个词语它就可以用了。这个东西时间就从就是一两分钟甚至还要不了一两分钟就可以搞定这件事。所以我觉得这件事情对创作者是有很好的一个提效的。所以这是我们。在做的另外一个方面的一个事情，对，其实围绕着创作者，因为我们自己本身也是播客的创作者，所以说我们其实自己也知道，除了像这种发布播客的通电以外，他其实你播客后期去推广，也需要很多的素材去帮助你推广，比如你要有一些好的 highlights 啊，或者说里面有些好的 QA 啊，提问啊这些，如果能够帮助你在微博呀，推特啊， 等等这些社交媒体上去推广你的内容，它其实也是很方便的一件事。其实我们早期的时候自己去能启动去推广我们的播客的时候，那个时候我们每发了一个节目过后，可能都要自己去思考很长的时间去写一个所谓的小作文，然后再去推广节目，对，能启动阶段做了很多这种事情，那其实你去写这个小作文的时候， 嗯，还是挺费时间的，特别是当你没有素材的时候，要从零自己去思考的话，它其实很麻烦，对。另外一个还有一个比较大的场景就是我们其实所有的人都知道，比如我们把音频的转录的组织杆，其实这个转录的组织杆它本身是一个非常口语化的，就像我们现在的说话，它其实里有很多的噪音呢，不流畅的地方，对，那我们也可以通过大模型把这种地方给它优化，给它改写，改写成一些更加通顺了流畅的类似于文章的这样的一个模式。 文章的这样的一个版本出来了。这个就可以方便我们去写一些公众号了这样的一些长文的地方了。对，因为其实今天很多做播客的创作者，他们最终也会自己基于播客的内容去产出一篇长文出来。对，这个几乎是所有的人都会去做的一件事。对所以这也是我们一个很重要的一个场景吧。对针对创作者这件事。这个工作流程目前我们还没有产品化。如果最终我们就把它产品化的时候，这里面肯定除了弹幕型还有很多其他的工作，可能要去适配大多数的一些社交媒体平台，比如像国内的公众号或者说小红书，能够去产出这样的一些贴近他们的内容可能就会更好一些。这就是我们主要使用的一些场景了。 Saito: 对，我们当前等于是有总结，然后有搜索，搜索这部分应该马上会上线，对，还有一个针对播客创作者的一个工作流，然后当前是我们自己在使用，对，我们打磨好了之后可能也会去做产品化，这是我们整个的大的一个主线了，对，我其实想问一啸的是，因为我们是从 GPT-3.5 一路用过来的嘛，模型其实也迭代了很多轮了，那从使用体感上面，你觉得这些模型的能力有特别明显的变化吗？就是如果你觉得有变化的话，主要体现在什么方面？ 一啸: 对，我觉得我们算是吃 AI，吃大模型的螃蟹，还是吃的算比较早的一批人吧，我觉得。我们其实上来确实是在用 GPT-3.5, 那个时候我们其实因为有一个很重要的起点，就是因为我们面对播客内容的时候，这个播客的内容它一般来说都很长，哪怕一个小时的播客，它的内容都很长，所以说我们一上来就希望选的是 GPT-3. 5 的最长的那个上下文，叫 16K 的那个模型。那个模型其实还挺贵的，当然在那个时候觉得是最便宜的，今天回，我也不知道这种心理变化，在真的一年前那个时候觉得这是最便宜的模型，好像我们自己觉得很棒，但是今天回头看这个模型好贵啊，对，中间其实在这个 GPT-3.5 16K Turbo 的这个模型中间 OpenAI 其实还发布过一个更加便宜的一个 3. 5 的模型，对， 但是那个时候，用我们的场景去测试下来，它其实质量下降非常非常多。对，可能也是因为成本下降了，质量水准也下降了。对，所以说最后我们的整个历程的话，第一步的话，在 3.56KT 这个使用的时间其实是很长的。然后在后来的话就是 Google 出来了嘛，Google 出来发布了 Gemini 1.0。Google 发布 Gemini 过后，Google 的策略就很好，它直接出来就送了每分钟 60 次的这个调用商的免费调用嘛。所以说每分钟 60 次，对我们来说这个场景它其实已经很足够使用了，因为我们处理播客前面始终有一个语音转文字的过程，那这个过程其实已经把时间拉长了。对，所以说每分钟 60 次对我们来说总量已经不小了，对，所以足够我们用啊，这个时候我们就开始去测试 Gemini, 发现效果和 3.5 差不了太多，差不多就是说你靠人肉眼睛去判断的话，其实你很难找出他们的不同之处，对，所以说我们就换到了 Gemini 1. 0 上开始免费白嫖大模型了。所以这一路其实是很爽的一个过程，因为在 Gemini 1.0 之前，我们每个月那个时候，因为这个很早期，那个时候一个月还要给一两百刀，可能两百多刀的 GPT-3.5 的模型的钱，所以说换到 Gemini 1.0 之后几乎就不给钱了。好，这是我们的一个分界线。我现在是把 GPT-3.5 和 Gemini 1.0 这个称为上一代的模型。对，所以在这个上一代的这个模型里面，所有做应用开发的，他们应该都有一个非常大的一个共同的通点，那就是模型在遵循指令的能力其实真的非常一般。 对，那大家需要去写很长的一个 prompt, 各种去加强那个指令强调，强调各种地方，对，就是你需要反复的去写一条指令，说哎，比如我这个输出的长度保持在 100 个字左右，怎么怎么样的。光是这句话其实他不一定能够很好的遵循的。所以说很多时候很多人写 prompt, 就会在不同的地方去加强这一条指令，让他能够深刻的理解呀之类的。就做了很多这样的 prompt 的事情。对社交媒体上也有很多有实践经验的同学，大家也在分享。随着后面的模型的发展，大家的那个 prompt 都在变得越来越短，不需要那么长了。对，这是一方面。另外一方面当然就是那个结构化输出能力。这个我们之前也做过一些分享，然后在社交媒体上其实也有很多人花了很多的精力在这一部分上，对，就是那个结构化输出的能力是很弱的，是非常的不稳定，对，所以说就导致了很多开发者需要用各种方式去 hack 去处理这个结构化输出的问题，比如说有很多人会去定制自己的一个 JSON parser 去做容错，我们自己也定制了比如 markdown 的 parser 去做这样类似的一些事情，其实这些工作它本身在我看来它是没有价值的一些工作，只是因为大模型的能力不够强，在早期在上一代的这些模型里面，他们对输出这件事做得不够好，但是现在其实已经做得很好很好了，对。后面我们从上一代的模型就是 GPT-3.5 到 Gemini 1.0，我把它称为上一代，然后再转到下一代的话就是 GPT-4.0 这一代了嘛，当然 4. 0 里面伴随了一个成本比较低的就是 GPT-4.0 的 mini，然后 Gemini 这边可能就是 Gemini 1. 5 plus。就这两个模型我觉得就是当前这一代比较主流的模型了。对他们在指令跟随啊，结构化输出这两大问题上，那真的是有本质性的提升。对，我现在很少有遇到那种输出的结构不合法的情况。并且这些模型他们已经很好的专门针对阶层去调优了，已经对你要输出阶层结构其实也非常非常的稳定了。对。所以说这也是对开发者来说，显然是一个解决了一个很大的一个痛点。对，那另外一个方面我觉得提升的话就是长上下纹，那这个就不说了。我们刚才说我们的出发点想选 GPT 3. 5 16 k 就是因为当时 16 k 是 openai 最长的了，那今天的话 16 k 可能就很短很短了。对，今天的长度 GPT4 mini 的已经是 10 万加，哎，这个就很棒了， 用起来就很顺手。对，像我们去处理波克长纹这件事，它就没有那么棘手了。对，那像 Gemini Flash 一百万家的 token，那这个就很好用了，今天我把绝大多数播客的内容全部塞给 Gemini Flash 都能够支撑得住，对，毕竟有一百万 token，对，长达比如 8 个小时的播客啊这些都能装得下了，已经对，当然 GPT-4 mini 的 10 万家可能还装不下，对，但是 Gemini 这个百万 token 是几乎都能装得下的。所以就很好用。另外一个就是主观感受，来到了这一代模型过后，我觉得相比上一代模型，在这种自然语言啊，文字的那种语言的组织啊，润色呀，或者说风格呀，或者上面，我觉得是要好一些。3.5 啊，Gemini 1.0 那种飞花呀，或者说用的那种词，你会觉得很累赘，或者说很矫情。反正就是不像人能表达的那么自然的那些语言，我觉得要更多一些，对。但这一条我觉得说它是一个比较主观的一个感受，因为每个人感受可能会不太一样，对文字的敏感度可能也不太一样，可能我每天看着很多这种模型生成的结果，这种细微的变化或之类的有时候能感受得到，但是可能对于很多人来说，我相信他可能也感受不到这件事，还有可能还是会觉得说人和模型之间有一个巨大的差距吧，对。这条反正比较主观嘛。好了，最后最后我觉得变化最大的那当然就是成本，这个是所有的人都感受最明显的，当然我觉得这个是对开发者。最友好的一条，那个模型的成本真的现在已经很低很低了，对，我觉得已经是感觉再这样卷下去，我很担心这些厂商哈，模型的提供商最后全部都挂了，那我们也做不下去了，对，感觉他们还是需要赚点钱才行呢，不赚钱感觉对我们来说也很危险。对，当然对开发者来说，这儿我觉得确实可以开始去探索很多比较复杂的流程了，比如说，呃，经常现在有说去构造一些配件头了，或者构造一些那些复杂的 LM 工作流的时候，可以采用一些多轮对话的方式，比如说第一轮我让大模型去生成了一个结果，然后再让另外一个大模型对它进行评价，你生成的这个结果究竟好不好，还有哪是不是有改进的建议，再来一轮根据别人提供的建议意见又去修改，就是这样不断的评估改写，评估优化，评估优化，然后最终达到一个比较好的一个结果，当然这种就是很耗成本嘛，所以说但是现在成本逐渐下来的话，这些处理方式都可以变得更复杂一点，对最后简单的总结一下，就是我前一段时间还发过一条朋友圈，内容是这样的， 我说刚好我们也做了差不多一年了，对，我说在过去一年大模型的进化速度真的之快，那在这中间我自己开发了不少代码，今天都可以删掉了，对，所以说它就是这样的一个感受吧。 Saito: 对，你刚才也提到我们最开始用 GPT-3.5 16K 的 Turbo 的时候，我们已经找了一个最便宜的了，对吧？但是从现在回过头来再看的话，那个时候其实也非常非常的贵， 然后现在你刚才有在讲说成本问题，然后现在大模型成本真的已经很低了，那你能不能给大家介绍一下就是我们对比最早以前用 GPT-3. 5 16K Turbo 的这个模型，我们的成本下降了多少？ 一啸: 嗯，其实关于大模型呢，他们相互卷了，相互去竞争降价这件事，我们之前也录过一期节目，还专门是讨论 deepsec，对吧，引发的一个降价，对，当时当然主要聚焦的是在讨论国内的这个大模型的竞争的问题，然后引来的降价的降价潮啊，或者说这样的一个问题，那其实除了国内在国外也挺卷的，对，当然就像刚才开头你讲的说的是现在主要出现的那种三国鼎立的三家。这种局面吧，对吧？当然我觉得主要可能在卷价格上面，Gemini 和 GPT 两个还是要表现得更突出一些，更凶一些，Cloud 可能还是要赤字一点，对。其实大家都知道 OpenAI 在推出 GPT-4. 0 mini 这个版本的时候是比 GPT-3. 5 的价格还低了几倍的，对，然后并且大家说的效果还好了，成本还低了，对。其实 Google 在最近又将 Gemini 1.5 Flash 的价格又降价了，降到了只有 GPT-Mini 的一半，所以这个就很夸张。当然还是那句话，这个对于开发者来说是一件非常友好的事情。这里因为提到了 Gemini 1.5 Flash 的这个价格的这个问题，其实这里还想再多提一点吧，就之前国内有很多的媒体都在报道，那个 deepsec 利用了一个磁盘缓存技术，将大模型的价格不是达到了百万 token，只需要一毛钱。大概有这样的一则报道，这个报道还挺多的，对，很多人都觉得这一点其实很厉害，这个确实也很厉害，对，我其实想补充一点的就是关于利用缓存 token 这一点的话，其实在 deepsec 之前，Gemini 本身就有这个方案的，对。它今天它的价格在这部分利用缓存技术产生的 token 的价格其实也只有一毛钱多一点，就是换算成人民币的话，大概是一毛三的样子，对。所以说其实也是一毛钱，百万 token 不是一个 token，所以这个就也是很夸张的，对。我觉得更重要的是我们自己一路走来，这个成本至少在大模型这个点上成本的变化我觉得是非常非常的明显的，对。因为最近那个 Gemini 1.5 和 GPT-4.0 两个模型都价格降了很多嘛。刚才也讲到了这两个模型作为这一代模型又有很多的好处，比如说什么巨长的上下纹之类的。所以我就基于这两个模型去重构了我们的工作流的一些部分的关键节点。就把全部的任务都搬到了这两个模型上了，就完全抛弃之前提到的 GPT 的 3. 5 的那个 16K 的模型对， 那成本的话最后我去看了一下我们成本相比之前的话肯定直接就可以下降 20 倍。这个就很夸张，就对，就很舒服的一个事情了，其实我们单纯从模型上的单价上去看 20 倍的话，那肯定是没有的，对，单价哪有 20 倍的差距是没有，所以说它的价格能下降主要是有几个方面，对，没有做这件事情之前，我原本以为说牵到这个新的模型的工作流上面来的时候，我认为价格可能只会下降一点点，甚至成本是持平的。对，当然这里面有很多隐藏的，当时我也没有想得到的。首先第一就是 GPT-4.0 mini 本身就比 3.56k 的那个模型要便宜很多。对。因为 3.5 16K 那个模型，今天应该它都不出现在 OpenAI 的官方的网站上了，它的网站上写的 3.5 的应该是后面那个很便宜的那个模型，就本身就便宜了好几倍，所以换模型肯定是有好处的。而第二个点就是同样的文本，GPT-3.5 的模型的 token 数量要比 GPT-4.0 的 token 要多很多很多，对，一两三倍肯定是有的，对。对，这个是我之前完全就忽略的一个点，都不知道说 token 生成的算法会有这么大的一个差距，对，那 token 少了，成本自然就低了嘛，对，所以这一点也是一个真的很棒的事情，原来模型的优化它不只是说把单价打下来，除了推理的能力上升了，我可能把 token 数量降低，等等也是可以把成本拉低了，对，所以说我们很多时候不是单纯看着那个单价， 甚至他后面我们看不见的地方也会有对你的成本有很好的优化的一些地方，对，另外第三的一个点在我们的场景里面，我觉得还有一个很重要的就是我们将我们那个最大的那个任务，就是我们要能够把整个 transcript 的这个全文能够全部塞给大模型。然后让他去生产我们的整个章节，整个 outline 的这个过程， 对，我们就完全把它直接放到 Gemini Flash 上去跑了。Gemini Flash 一上来就给你提供了一个每分钟有十几次啊免费额度的一个使用，说刚好对我们的这个场景来说就做这件事情，它就非常非常的合适了，就不要钱了，这件事就变得对，所以说整个这三个方面一加起来，你就会发现成本的下降对我们来说就很明显了，对，可以看得到这里面成本下降，第一有顾客的慷慨哈， 当然我相信 Google 的慷慨也在于它背后的技术能力的进步嘛，也才大其粗，所以说可以给大家提供这样的免费的额度。 对，其实除了 Google 以外，我们可以看到像 OpenAI, Cloud，其实都没有免费额度，比如说就是一个有限时间的这些额度，其实都没有，所以说还得有钱，对，Google 可能这点确实还得有钱。所以这一点的话，其实 Google 光是这个点上我觉得还挺有好感的，其他两家在这个点上对开发者是一定要花钱的，对。所以整个流程下来的话，我觉得还是有一点小经验，就是做大模型可能是一定要去实践的一个点，就是一定要充分的去混合使用各家模型，最后找到那个最好的一个性价比吗？因为今天的模型的效果确实大家真的模型的能力是在趋同的。或者说一家模型擅长这个点，另外一家模型擅长另外一个点。你做一个稍微复杂一点的大模型应用的时候，你一定有很多的不同的任务需要处理嘛。那你那些不同的任务可能在每家模型上的表现是不一样的。这个时候我们只要去充分的去测试不同家，找出他们最好的那家，然后去混合的去使用，最后就可能组合出一个最好的一个性价比出来。这件事其实就让我想到还有一个点，就是那个大家都知道像那个 360 前一段时间不是在对外宣传他们在做的那个搜索引擎，AI 搜索采用了一种混合模型的架构，它的名字也叫 MOE, 但是它的 MOE 不是大模型的那个混合专家的那个意思，它的这里把全世界现在市面上能看得见的这些大模型给它全部对接了， 然后再根据那个搜索任务，比如说你今天是要搜索要解答的是一个数学题，还是说你要搜索的是一个编程问题，另外也可能要搜索查询的是一个中国历史或者欧洲历史。他根据你不同的这种。Query 的类型去调用不同的模型，因为他事先已经评估过了所有的模型，他用了好像是用了几千个案例去评估了这些模型，那些模型在哪一方面表现的最好，所以说他就号称他做的这个搜索可能效果就是很多人评测下来觉得说效果确实就很好，这也就是一种混合使用，也是一种很好的技巧吧，我觉得对。 Saito: 对，这个挺有意思的。他可能把所有人都评估了，做数学题，对吧？现在阿里是专门推出一个 Math 的一个大模型，对吧？可能效果会好一点，可能大家都能想到的，但是可能当前没有人做，可能三轮一次就可以做了，对吧？就是我们最早以前的时候，你在用 GPT-3.5，然后 16K，然后当时其实也有 GPT-4，但是大家很难去 cover 住 GPT-4 的那个成本，对吧？那现在当前其实也是一样的，包括你用 Gemini Flash，对吧？那你也会有 Gemini Pro, 对吧，然后你用 GPT-4.0 mini 的话，你也有 GPT-4. 0，那这两种模型当前的价差也是很大的，我之前查了一下，就是 OpenAI 这两个，就 GPT-4.0 mini 跟 GPT-4.0，它们两个价差有 16 倍，那我相信表现肯定没有 16 倍的差异啊，对吧？然后我就想问一下，如果我们去用的话，这个在使用过程里面体验差异有这么大吗？是不是说一定程度上我们可以直接去用 mini 模型，就是不一定说非得去用 GPT-4.0? 一啸: 对，这个问题我觉得不是一个很简单的答案。对，是 1 还是 0 的这样的一个问题，它不是这样的一个简单的答案。我先说一下我的感受的一个体验。首先，GPT-4, GPT-4 mini 这些，就是这个大小的模型。那他们在结果上肯定是有差距。像我们的场景用来处理自然语言的分析和生成的话，其实人还是能感受到差距的，就是有时候。但是你说有没有 16 倍这么大，那肯定没有 16 倍这么大。当然肯定就是这个账它不是这样算的，就你成本比如说降低了，它可能是来自于后台技术的一个突破，或者是做了一件什么事，但是这两件事情成本和那个技术的突破这个路线它肯定不是一个线性的关系，所以说这个地方账肯定不能这样算。但是我还是觉得说像我们这种场景，自然语言或者说叫普通的文本处理，其实你很难去做一个理性的判断，对，就是它究竟是对还是错，它没有对和错这种关系，它更多的是一种主观上的一种感受比较大，它就是它不像做数学题这种有对错之分，对，所以说我们去评估你究竟是用 GPT-4 还是用那你可能在比如一个做数学题这样的场景里面，它就不是这种评价标准了，就可能会说你不上 GPT-4. 0，那个数学题它就解不出来了，它是有对错之分的，哪怕为了省成本，你去上一个 GPT-4.0 的 mini 得出来的答案，它就是不对的，这种有对错之分的，我觉得说它是非常好评估的。对，那你可能成本甚至不太重要，因为你要首先追求的是对和错的问题，在对错之上再去看成本了。对，那回过头来，那像我们这种场景，自然语言的处理或者文本的分析处理这种其实是今天 AI 应用的主要的场景。对，很多生成文本了之类的，这一类里面我还是觉得说这种没有对错之分的那主观感受就比较大了。那这个时候你用 GPT-4 mini 我觉得合适的，对。比如说你用大模型从文章里面去划重点，去划那种 highlight 啊，找那种亮点啊之类的，它不像数学题，你就很难去判断它的结果是不是真的好，是好和坏。比如说在微信的读书里面有一个瞎划线划线笔记的功能，对，我相信所有读书的人应该都会去划线，也能够相互看到别人的划线。那其实我们只要稍微去注意观察，你就会发现你划的线和别人划的线在很多时候其实都是不一样的。对，所以这个东西它就是因为没有对错之分，就是因为每个人的那个认知不一样，关注的那个重点和吸引你的点它是不一样的。因为我经常去微信读书里面，我看到别人的滑线可能很多人都在滑京剧啊， 然而我的滑线经常是去滑一些事件，可能在历史的某年某天某个人他做了一件什么事。对，可能我很关注这种，因为我把它称为这种叫案例啊之类的，所以我很喜欢收藏一些这种案例。我觉得这种案例收藏下来，它可能方便我去做其他的一些输出，比如我录播客的时候，什么时候要讲个段子啊，或者讲个故事啊，我觉得它这种就很好。所以这就是每个人的认知或者说自己的关注点，它不一样。这个我觉得说在模型的表现上就没有那么明显，这个时候直接上来使用 MIDI 啊，这些 Flash 啊，这些更小一些的更便宜的模型。它是非常合适的一个问题，对。那所以在应用开发层面，我的建议那就是你说的那样，一上来就是更多的去使用 Flash，使用 Mili。对，这个我觉得它有两个点哈，第一个点当然就是更容易做成本控制，这个不展开，那第二个的话，我觉得说你去从低配模型开始使用，你其实可以更加深入的去了解自己的业务的场景，在这个 AI 模型上的一个表现的情况是怎么样的，那你未来这里面存在一些优化空间呢或者之类的，你自己也更清楚一些，对。 Saito: 对，我觉得这个挺好的，就我们一开始其实可以用便宜的先开始嘛，然后做，如果你觉得有任何能力上达不到的，你可以再尝试再去用贵的一些模型。对，然后我们其实一直也在讲说。我们自己的这个产品 Podwise，当前来看的话，我们也算是一个总结类的一个 AI 产品，对吧？然后其实最近一年总结类的 AI 产品确实是属于那种爆发式的增长，然后产品之间大家也越来越同质化了，总结本身它是属于内容生成，从内容生成到内容发现的这个路径就顺理成章了，然后这部分其实我们自己也在做实践，刚才我们也在聊说，我们也在做 AI 搜索，对吧？那能不能给大家再介绍一下，就是 Podwise 在总结之后还有什么 AI 相关的创新点吗？ 一啸: 对，我是非常赞同关于总结这件事，今天越来越卷，并且所有的产品和工具真的非常非常的统治化，其实你很难在模型或者纸上去做出很好的差异，比如光是总结这件事，你要做出一些不同的差异，我觉得是很难的。那往后看的话，我觉得总结类的这些工具，拼的肯定不是总结的能力了。当然总结的能力它肯定还会水涨船高，但是还是一句话，所有的人都会水涨船高。所以说大家可能去拼的话，不能单纯去拼这个能力。我觉得更多的可能后面是场景和数据会非常非常的重要。比如说就是你有一个总结工具，能在什么样的场景下进行总结，能够对什么样的数据进行总结。我觉得这件事情是非常重要的。比如举个例子，我们前面不是 Saito 刚访谈过澳洲的那一对夫妻吗，对吧？他的总结工具就是在会议场景，对吧？对。开会能够对会议进行记录，进行分析，进行总结。所以他这个场景其实有绑定的很强，那你说你另外有一个随便你有一个浏览器的插件，有一个什么总结工具，那你不一定能搞得定这样的一个总结的场景，对。这就是我想表达的那个场景的那个那个意思。那回到 Podwise 上的话，它其实真的越来越让我感受到就是做 AI 的应用产品，数据比模型是要更加重要的。因为我的观点是模型它一定会越来越强，价格越来越便宜。我们今天其实真的不需要花时间再去关注模型这件事情，这里只需要和时间做朋友就可以了。当然，只要他们这些模型厂商不要因为亏损严重都挂了就好了。最近不是有个小道消息说国内的一家六大大模型厂商之一，但具体是谁没有说，所以我们这里也就不在节目里面去发布这种我们也没经过证实的名字了，但是反正听说已经团队走了差不多了，好像快挂了，所以说这个可能未来确实有一些大模型厂商真的可能会挂掉的。所以说我们今天的担忧也不是没有道理的。那回到 Podwise 的话，那后面可能我们确实还会去上线一些 AI 功能哈。比如说我们今天有了总结数据，那我们确实就可以很好的去更容易的去做智能推荐去做发现。那我们又有了文本数据过后，那它就可以依这些文本数据去做 AI 的搜索或者说叫 RAG 相关的，利用这些东西去做相关的一些知识或者信息在里面的发现，探索这样的一些功能。就像现在 Proplexity 已经不把自己叫搜索引擎，对吧？大概叫知识引擎，知识问答引擎或者探索引擎，我们可能也会基于 Procast 的数据去做这样的一件事。这已经是我们实现的能力了，很快可能就会把它产品化掉。 另外一个方面，是我想过的，但是我们今天还没有去开发，还没有去实践的。今天其实大模型已经都是多模态了，各家大模型其实都已经在支持多模态，只是说在图片，视频，音频上面的能力没有文本这么强。但是从产品的角度其实我们也是可以去考虑如何在未来利用上大模型的多模态的能力，把你的产品做出另外一个角度，另外一个维度的创新。对，毕竟图片和视频是看得见的地方，对人的那种观感其实也挺棒的。 Saito: 对，你刚才也提到 RAG 嘛，相信大家可能对 RAG 这部分会比较感兴趣。我们能不能给大家分享一下，我们自己在用 Whisper 处理完所有的逐字稿之后，这个播客的逐字稿是经过什么流程，然后最终会被 AI 搜索到的。就这个过程的给大家分享一下，就是它的整个的工作流，大概这样。 一啸: 对，这个问题简单的分享一下，对，因为播客里面也不是很方便的去阐述很多的技术的特别细节的一些东西，对，反正这个步骤大概就是第一步，我们肯定就是需要对文字稿去做一个 chunking, 就是做一个分片，因为我们的文字稿都特别特别的大，对，那为什么要做分片？其实它不仅仅是太大这件事，分片的目的其实是为了让你内容更聚焦，一定要理解这件事，对，因为你整个内容的话，它其实是不聚焦的，是很分散的，然后你全部传给大模型的时候，针对回答一个问题的时候，它一定会产生大量的幻觉，会回答更多乱七八糟的一些内容出来，对，就其实说白了就是输入给大模型的数据越精准，大模型的回答就是越好的。所以说一定要去做 chunking 这件事。把分片做完了过后，第二步就是用找一些 Embedding 的模型，然后对这个文字稿的分片，就是我们上一步的分片去生成一些项量，那你把项量做完了，然后第三步了当然就是找一个项量存储啊，或者项量数据库把它存储起来就可以了。当然，如果你要处理的场景还项量不多，可能说你就一个文档啊或者之类的，那你不存这个项量也行了，你就放到内存里面，然后最后怎么做一下计算比较也行。但是我们的场景显然是有大量的海量的项量，我们现在几乎有几百万的项量需要存储，那你肯定是需要有一个项量数据库的，那我们的项量已经被存好了，保存好了，那第四步肯定就是进行搜索呢？这个时候要完成搜索就是提供一个 API 的流程就可以了。这个 API 的流程里面要做的第一步就是用户这个时候可能发送一个查询请求，一个 query 过来了，你可能就要用相同的 Embedding 的模型去生成一个项量，这个就是 API 的第一步。第二步， 我们可能就拿着这个 query 到项量数据库里面去查询一下和它距离或者最相似的那个分片的文杠了，对，啊，这个时候可能查出来就是一个 top，可能 top100 或者 top50, 那第三步我们可能就将这些文杠和那个 query，那个查询的问题，又一起去交给一个要做 re-rank 的模型，让他去做一个重排序，把它排得更好一点，对，把那些不相关的给我放到后面去，对，最相关的挪到前面来，对，好了，第四步，从 re-rank 的结果里面，我们只需要去选取，比如 top10,top20，作为最终的检索的结果，反正这个就根据自己的需求去调就可以了。所以最终的检索结果就完事。 好了，第五步，最后我们就用你要去做问答，做 answer 的那个 prompt, 然后加上我们的检索结果作为上下文，一起给它发送给大模型，然后大模型就会基于你事先写好的 prompt 就去回答这个问题了，对，所以你会发现整个流程跑下来它其实很简单，但是这个流程里面它本身其实是有两个部分的，那我们可以把它称为前后台两个部分，那后台部分其实说白了就是在实时的处理你的后台的数据，就是把这些数据给它做分片，做相量，然后存到相量存储，对，这是一个后台部分， 前台部分其实就是要提供一个 API 去做问答做搜索。它其实就完事了。 Saito: 对，我觉得刚才你讲的这个过程还是挺清晰的。然后现在很多人做 AI 搜索，他都是透过 Google API 来做嘛，对吧？然后我们场景跟别人还有点不太一样，因为 Podwise 的内容是自己转入产出的。所以说我们在去做播客的一个 RAG 的时候，我们首先就得有一个自己内部的 Google，对吧？内部的搜索引擎来解锁数据。然后这部分我们当前有没有什么最佳实践可以大家分享一下？ 一啸: 对，我们其实在之前有一期专门讲 AI 搜索的节目里面其实也提到，其实做我们这种类似于做垂直场景的私有数据的检索，那其实基本上都要跑这样的一个流程，对，那当然这种流程今天已经也有很多的框架帮你实现了这个流程，你可以直接使用，比如说现在很著名的 Langchain，还有 Llamaindex, RAGflow，其实这些框架， 都能做这个流程，当然 RAG 的框架其实非常非常的卷今天，除了我刚才说的这些还有很多很多。我觉得对于做那些想做 AI Infra 创业的人来说，其实我是不太建议去做 RAG 框架的，因为我觉得这个东西没有什么核心竞争力，对，替代性非常非常的强，对，要回到整个 RAG 的流程，那我们自己其实是没有采用任何框架，对，因为我们本身有自己的工作流，然后自己的数据流，然后去在数据流上去加一些关键的步骤节点，去生成相量啊，传输相量数据库就完事了。就是它本身其实很自然，这个框架不是我们需要重点关注的东西，而我们重点的关注点就是在 RAG 流程当中的每个步骤的一些具体的实现，我觉得这个是非常重要的，这是 RAG 框架，它们是一个很范的支持的情况，比如说你选 langchain 也好，lamaindex，最后你还是要回到去选哪个硬搬定的模型，它会告诉你我支持了现在主流的所有硬搬定的模型， 当然最终选哪一个来使用，其实这个是重点工作，并不是说你支持了 20 个我也用不了 20 个，你支持 20 个我也只会用其中的一个，关键是用哪一个，这个是真正真正的关键之处，并不是在于你支持很丰富的框架。那再回到 RAG 流程当中的一些具体的实现吧，比如我们今天去关注的一些点，那比如香梁数据库选谁，那我们选的是 qdrant, 因为这个数据库真的很轻量，然后部署也方便，然后运维起来也很方便，对，它拥有对应的 cloud 服务，对，所以在未来要迁移上云也是一个很简单的事情，对，其次就是要选一般的模型，我刚才说的，然后再选每个 qdrant 的模型， 好，然后我们其实还支持了全文搜索嘛，对，全文搜索其实也挺重要，对，我们在全文搜索的选的是一个法国的一家公司做的叫 meilisearch, 这个也很出名了，今天，对，大家都可以去看一下，最后在针对这个话题分享一点感受，就是做 RAG 自己内部做搜索这件事的话，对于大文本做 chunking 这件事情非常非常的重要， 至关重要，对，但是这个东西是没有标准答案的。你如果用那些框架的话，它会给你的答案都是按比如按 size 按大小去分多少个字节去做一次 chunking, 但实际上这些可能在你的场景里面，如果你自己去写 chunking 的策略，你可能会做得更好，所以这里没有标准答案，但是非常非常的重要。第二个就是我觉得检索方式和检索的数据源， 如果能做到多种多样的话，那肯定是好的。比如说你可以支持用密集向量来检索， 还有西数向量检索，甚至现在做关键词来检索，就像我刚才为什么提到了全文搜索。还有很多很多，这里面有非常非常多的检索的方式。当然今天主流的第一个最重要的都是密集相连的检索。这个是我们第一步要做的事儿。对，我觉得我们所有的把第一步做完了，再去考虑其他的去优化你的效果都是比较好的一种方式。对，反正就是检索方式多，你的数据源比较丰富，那你最终检索出来的内容可能精度就要高很多了。对。好，那这里刚好我看到 qdrant 在他的 blog 中写的一句话，我觉得挺好的，他说构建一个好的搜索体验的话是一个比较复杂的任务，那你最好可能要保持数据启动，要结合你自己的数据的方式去找到那个最好的搜索体验，而不仅仅是靠直觉，对。 Saito: 对，我们刚才有提到说这个整个 RAG 的这个步骤啊，就第一步要找一个项量数据库，然后我们刚才有介绍相对应的产品，然后第二步是 embedding，第三步是 re-rank，然后第四步是全部搜索，然后我们现在当前用的是 meilisearch，对吧？那我们能不能就一个一个来，因为我们项量数据库其实已经用了 qdrant 了，对吧？那 text embedding 这块的话哪家效果比较好？然后我们当前在用的过程里面我们有没有一些评价体系？ 一啸: 对。对，我觉得这个比较重要哈，它是一般念其实对我们中国团队来说的话，我觉得欧洲团队其实很多时候他们没有这种顾虑，他们一般好像很多时候就只做个英文就可以了，但是对我们中国团队来说，很多时候你做的产品是多语言的，对，其实我觉得加上多语言这件事情，你可选的范围其实就不大了，特别是再加上中文啊，这种日韩啊，这种可选的范围就小了很多很多了，对，所以说 Embedding 的话，我们一般来说，如果大家去做的话，可能就分成两种 Embedding，一种是 Dense Embedding，就是做密集向量的，这个是主流，这个是最核心最关键的，对，这个是第一个我们所有人做检索方式的时候应该做的一件事儿，对，优先做这件事情，那这个其实本身密集向量的 Embedding 这件事儿模型是很多的， 但是如果加上多语言的话，可选范围也不大的，那我们今天直接选 OpenAI 的 Embedding 模型就很好了，那个模型也很便宜，然后又有 API，又不需要自己部署，对，然后其实还有一些替代，如果你愿意自己部署的话，其实有很多的替代型的，比如 BGE M3，这个很著名，很著名了，这个也是中国团队开发的，智源开发的。网易的 bce，网易这个做的也很好，这个嵌入模型，然后还有一家公司 gila 呀这些。对，你会发现我写的三个替代的其实都是中国团队，那个 gila 我原本以为是国外团队，其实我最近才发现他也是中国团队的。为什么我写的替代的他也是中国团队，其实就回到了多语言这个话题上。你会发现真正给你训练了支持中文啊日韩啊这些多语言的模型，你会发现可能大概率是来自于中国团队。那当然除了像 OpenAI 这种厂商以外，Google 这些厂商以外，其他的很少会给你提供多语言，特别是中文是很对，就是这种。再来到 Sparse Embedding，对，Embedding 其实还有个西数项量嘛，那西数项量其实今天可选范围就更少更少了，对，西数项量模型当然大家主要就是用来做类似于关键词的延缩啊这些东西，当然它比全文搜索可能要更好一点，对。这一块的话，它可能今天主要的就是 bge-m3 和 splade，对，这两个，splade 是一个海外的模型，它不支持多语言，所以说你会发现 bge-m3 成为了你可能唯一的选择，对，大概率是唯一的选择。 但是呢，Sparse Embedding 模型主要就是我觉得今天是没有很好的 API 的服务了，所以说你只能自己去部署这一套模型，所以相对来说对你的成本是有挑战的。所以综合来看，在 Taxi Embedding 上，BGE M3 真的是一个功能很强大的模型，它的功能非常非常的多，除了 Dense Embedding, Sparse Embedding，它也支持绿乱客呀，等等等等各种功能，所以这个模型很综合。 Saito: 对，你刚才也提到了，你看 text embedding, 我们现在比如说我们用了 bge-m3 对吧，然后后续的话其实拿到搜索结构之后还需要做一次 re-rank 嘛，然后你刚才也讲说 re-rank 的这个效果对于你的整个结果 RAG search 的结果其实也至关重要，这个当前我们在 re-rank 过程里面有没有什么最佳事件？ 一啸: 对，我们现在的是在 Text Embedding，我们现在跟轻项鱼直接选 OpenAI 的 API, 对，做 Text Embedding，然后第二步 Lelunc 的话，我们选的就是 bge-m3 的 Lelunc 模型，对，它支持多语言的 Lelunc，然后又是长文本，8K 长文本，所以就很好用，那网易的 bce-lelunc 其实也很不错，但是它的语言太少了，它只支持中英日韩，其他的语言就没有了，不像 bge-m3 的语言可能几十种， 就很足够使用，对，其实我还测试过 Gilad Rank, 但是它的中文效果就比 BGE 和 BCE 差了一些，其实这点真的很可惜，因为如果 Gilad 的效果好的话，其实我是就打算直接用他们家的 API 服务了，这样你就不用自己去铺存模型了，但很可惜，他们的模型效果有点差，对。总的来说我觉得绿乱客在选择上刚开始不用太纠结关系不是很大，因为后期其实是可以随便换绿乱客模型的，它不会影响你的数据。它不像 Embedding 模型，可能你后面要换模型的话，你的所有的数据就要重新跑一遍嘛，要重新做一次 Embedding，对。那 LLM 可能没有这个问题，对，可以随便换，所以就比较好选。 Saito: 对，然后我们刚才最后也提到了搜索嘛，对吧，我们用 meilisearch, 对，然后刚才我们也有提到说 RAG 的 search 的这个效果，除了我们刚才讲的这些之外，肯定 Prompt 也是至关重要的，对吧。Prompt 其实不光是在 AI 搜索有用了，对吧，我们自己在以前的那个总结上面其实也蛮有用的。对，然后这块 Prompt 相关的这家事件能给我们分享一下吗？尤其是我们自己在处理一些多语言的东西吗？ 一啸: 对，我觉得多语言这件事是在我们上一次分享 LLM 相关的节目的时候，其实重点讲了很多。但是我今天想说的是随着这些模型的进步，就像刚才我已经说了，我发过一个朋友圈说在过去一年里面开发的很多的代码其实都可以删了。所以说我过去做的很多多语言相关的早都已经被我删掉了。对，那些工作已经不需要了。对，今天的 Prompt 在处理多语言上这个痛点我觉得在 GPT-4 的 media, GPT-1.5 的 flash，当然包括他们的 pro 的版本，这个问题似乎都已经不太存在了，现在你只需要告诉他输出中文，输出英文，输出任何语言，他都给你的答案一定是就非常非常的精准，我几乎没有碰到不会去跟随语言指令的这种情况了，对，所以说已经这一代模型真的比上一代模型强了很多很多，所以我们可能在 Prompt 也简单了很多很多。所以说 Prompt 的经验，我觉得今天只给大家去更新分享一个新的实践经验吧。而不是 Prompt 怎么写本身了。那今天我自己写 Prompt 的流程。已经变了。大概是这样的一种流程。这也是产品的工具这个领域的发展给你带来了很多的一些红利相关的一些工具。我现在首先都是用接纳他们家的那个叫 prompt perfect 的工具。我会首先让他帮我写一个 prompt，对，就是你要干一件什么事，你告诉他，他会帮你写一个 prompt，对，你不需要去把这个事情描述的很清楚，很简洁的告诉他就可以了。第二步，我再对这个 prompt 进行一些调整修改，或者说还在里面再加一些步骤之类的。做完那个后，我最后再把这个 prompt 交给 GitHub 这个产品，让他再帮我把我写完了这个 prompt 做一次优化。对，然后就得到了最终的这个 prompt 了。所以 GitHub 的这个 prompt perfect 的这个产品，它其实本身就支持两个很大的功能，一个就是创建一个 prompt，另外就是优化一个 prompt，对，然后每天你有 10 次的使用机会，所以说你每天做一个 prompt 问题不是很大的，已经足够了，很多啥的，虽然说还是少了一点，但是也差不多够用，对。反正这样基于这种工具去写 prompt 的效率其实就高了很多很多。但是更重要的是我发现他的用词可能比我要好很多。对，有很多词语其实我发现，哎，他写出来，原来可以用这个词语。然后我发现我这个单词听都没听说过，对。 所以说我就发现，对，这个也是人的嘛，可能在英语这方面就没有他擅长，毕竟他学习的更多嘛，对。 Saito: 是的是的，其实我们刚才也有提到像 Gemini 1.5 Flash，它现在有免费的 API 嘛，然后一分钟可以用 100 万个 token，然后一天可以请求 1500 次。我感觉还挺适合用来做点个人小项目的，因为我们独立开发者嘛，对吧？就是你不用去本地去跑以前的什么 7B,13B 这些模型了，其实占的内存还挺大的，对吧？没有点好的 GPU 还不好推理。对，在有这个东西之后，不是之前有一些人就在提说什么批量修改文件名之类的嘛，对吧？我感觉这个东西就可以去用 Flash 了。对，然后还有没有一些别的可以让大家把本地工作留，然后把它 AI 化的一些小玩意儿，我觉得可以给大家推荐一下。 一啸: 对，我觉得你说到这个 Gemini 1.5 Flash 的免费额度的话，我觉得确实是不错的，我们自己因为也在单这个便宜嘛，也在白嫖这个免费额度，对，但是这里其实还是需要有关注的先知点的，对，就是它每分钟只有 15 次的调用额度，就是除了那些什么一天可以调用 1500 次啊，或者说它的 token 一天可以使用 100 万 token 之类的， 但是他每分钟 15 次这个调用额度可能对大多数做应用做产品的人来说，这个是第一个瓶颈，对其他的我觉得可能确实都不是瓶颈，对，然后他这个额度的限制可能还不是很准，因为我发现他有时候可能不到 15 次，对，但是呢，我觉得如果你的频率是每分钟两三次，那这个额度肯定是很安全的，很够用的，对，像我们的场景，每分钟可能最多就一次，对，在那件事上。对，它就很安全的。为什么我就提这个闲置？就是我发现可能大多数的在线产品的话就用不了这个，比如说你做搜索，那你可能每分钟你只要用户量稍微有那么多用户量的话，你可能每分钟就搞不定这件事，对，包括对话类的啊，还有很多复杂的工作流，你可能一分钟就要运行好多次大模型的调用，对，这种可能都做不了了，对，那就像你说的，如果用来做个人本地的工作流，我觉得大多数任务可能真的就是挺够用的，对，直接用来，比如本地做一个翻译啊或者之类的，对，但是也不一定，如果那个翻译的文档特别长，你可能有时候不像一次性翻译，还要采用那种就是之前那个不是那个吴安达写的那个翻译的工具吗？那个翻译工具其实就挺复杂的，要进行好多轮的搞来搞去搞来搞去，那这种可能他又用不了，对，所以说他也不一定那么好使的。当然我自己好像就像你说的自己本地好像没有什么特别的 AI 的流程，因为本地我自己常用的其实就两件事嘛，翻译和写代码，其他的事情好像很少没有别的了，对对，AI 的主要使用今天都是在线服务了，可能我自己的电脑其实确实也很难跑，就像你说的本地的什么 7B, 13B 这些模型很难，对。 Saito: 对，没关系啊，我们的听众如果有什么自己大家在本地在跑的这些 AI 的这些工作流，然后也可以给大家推荐一下，就你自己在用的，然后你觉得用免费额度就足够的，可以在下方评论区然后给我们做一些评论，对。我们今天聊了很多啊，那最后再给大家推荐一下吧。如果现在大家开始做独立开发，用什么模型不折腾？ 一啸: 对，我觉得这个很好啊。如果我们的定位是做独立开发者的同学的话，就先不管折不折腾这件事，首先肯定是要选便宜的，免费的是最好。对对对。我们曾经出发的时候其实也是围绕这个点在出发的，对，所以说我觉得这个很重要，所以最近不是刚好那个字谱也发布了一个完全免费的模型吗？对，当然有一定的使用的一些限制的额度啊之类的，对对对，但是反正挺免费的，对。那我觉得我自己也还没有真正去使用过国内的这种大模型，但是我觉得一个免费的模型并且还是大模型能力好像还挺强的，那我觉得这就是一个很好的机会哈，特别是对于独立开发者来说，嗯，可以去试一下，我也决定要去试一下这个模型，这个免费的，对，我觉得免费的就是好啊，哈哈哈。对，但是回过来说，回来做产品的话，那我觉得今天的 Gemini 还是那句话，Gemini 1.5, Flash, GPT-4 mini，以及他们以上的这些版本几乎都不用太折腾了，稳定性比之前上一代真的好了很多很多，对，并且刚才我也提到了还支持稳定的节省输出了，对，所以说对我们开发者来说，那已经非常非常的友好了，省了很多的事了，对，都可以去搞，但我还是觉得成本优先，对，你刚才提到这个质朴的免费模型啊。 Saito: 然后他们免费模型叫 GLM4 Flash，就是把 GPT-4 然后跟 Gemini Flash 整合了一下，名字起的也很艺术啊。好的，好的，那反正我今天一口气问了这么多问题，然后我收获也很多。如果大家对 Podwise 使用 LLM，然后开发的一手经验也感兴趣的话，然后也欢迎大家加入我们知识星球，然后跟我们一起讨论学习。当然后续更多的最佳实践内容我们也会在星球持续分享。好的，那我们本期节目就先到这里吧，我们下期再见，拜拜。 一啸: 好，拜拜。 Saito: 以上就是我们本期播客的全部内容，感谢大家收听，也欢迎大家踊跃留言。如果你喜欢，我们，欢迎点赞并分享给感兴趣的朋友。如果你在用苹果播客收听，也希望你花几秒钟给我们一个好评。这会让更多的人了解到，我们要是能再点击一下订阅，那就再好不过了。我们下周见。