在coze上实现notebookllm

1.首先，LLM的一个很大的缺陷是它无法实时获取最新的信息。它能获取的信息就是预训练时输入的信息，这些信息有一个截断日期，这个日期之后的信息它一概不知（至少无法从模型内部获取到）。而搜索引擎可以获取到更加实时的信息。2.LLM有“幻觉”问题。在缺少相关事实信息的情况下，它就会编造。更严重的是，它很擅长编造，经常编得跟真的一样。而搜索引擎可以检索出相关的信息，这些信息可以作为LLM“推理”的依据。3.LLM无法给出准确的引用来源。LLM吸收了整个互联网的信息，当它回答问题的时候，你会感觉它的回复好像是参考了互联网上的某个地方的内容，但是它无法告诉你它具体引用或者改编的是哪里的内容，因为LLM已经把整个互联网的信息作了词元（token）级别的融合。LLM无法给出引用来源间接带来一个严重问题是，你无法去到信息源，去自己做验证。而搜索引擎可以给予准确的信息源。以上种种问题，决定了LLM本身作为一个知识问答工具是完全不合格的。而搜索引擎的问题则是体验上不够简便、不够直接。搜索引擎返回的信息是一堆链接和文本片段（很多时候还有广告干扰），这种呈现形式是比较原始的，还需要人去做进一步处理。给搜索引擎加上LLM，或许可以带来更优的信息检索体验。Perplexity[4]就是基于这个思路搞出来的产品，目前其估值已经超过5亿美元了，它的目标是要取代Google搜索。这个思路本身没有什么新鲜的，OpenAI早在21年就研究过了[5]，后来也有研究者作了进一步的验证[3]。这个思路的技术实现也不复杂，贾扬清大佬用了不到500行Python代码就实现了一个基础版[6]。

在生成标题、导语、大纲时，因为只涉及文本理解与文本创作，很明显这是LLM节点的工作，所以我们需要对LLM节点进行配置。可能你在1.2分解子任务那个章节就想问：为什么不把“标题、导语、大纲”拆得更细，比如分成生成标题、生成导语和生成大纲3个子任务？——因为LLM是按输入/输出的字符数量来消耗token，在满足预期的情况下，更少的大模型处理环节，能有效减少token消耗，在实际投产时节省模型调度费用。经过实测，豆包·function call 32k模型，已经能在一轮对话中稳定地生成这三项内容了。每个大模型节点的配置项很丰富，对于入门用户来说，主要关注：在“标题、导语、大纲”节点中，我们希望LLM能够从开始节点，接收到原文信息，经过处理后，一次性把我们需要的中文标题、中文导语、英文标题、英文阅读大纲生成输出。所以设置如下：另外，为了保证大模型能够处理足够长的内容，需要视实际情况调大模型的最大回复长度：最后，根据1.3设计每个子任务的执行方法中的内容模块要求，设计并填入以下用户提示词（本文主要讨论工作流的设置，就不论述这个提示词具体是如何设计的了，感兴趣的可以单独和我聊）：

在生成标题、导语、大纲时，因为只涉及文本理解与文本创作，很明显这是LLM节点的工作，所以我们需要对LLM节点进行配置。可能你在1.2分解子任务那个章节就想问：为什么不把“标题、导语、大纲”拆得更细，比如分成生成标题、生成导语和生成大纲3个子任务？——因为LLM是按输入/输出的字符数量来消耗token，在满足预期的情况下，更少的大模型处理环节，能有效减少token消耗，在实际投产时节省模型调度费用。经过实测，豆包·function call 32k模型，已经能在一轮对话中稳定地生成这三项内容了。每个大模型节点的配置项很丰富，对于入门用户来说，主要关注：在“标题、导语、大纲”节点中，我们希望LLM能够从开始节点，接收到原文信息，经过处理后，一次性把我们需要的中文标题、中文导语、英文标题、英文阅读大纲生成输出。所以设置如下：另外，为了保证大模型能够处理足够长的内容，需要视实际情况调大模型的最大回复长度：最后，根据1.3设计每个子任务的执行方法中的内容模块要求，设计并填入以下用户提示词（本文主要讨论工作流的设置，就不论述这个提示词具体是如何设计的了，感兴趣的可以单独和我聊）：