想做一个agent定期触发开拓供应商资源。 除了抄模板感觉啥也不会 。完全没有头绪。。。 5 个帖子 - 5 位参与者 阅读完整话题
身在某金融外包信息科技中心，领导定了以dify为主要平台进行开发。但是这玩意它真的不好用啊！踩了很多坑，劳心费力的，劝了还不听。目前已经准备跑路了。 10 个帖子 - 6 位参与者 阅读完整话题
我的华为云的Flexus L 实例IP被 墙了, 上面部署了一个hiddify, 现在没办法使用了. 谁能救救我. 2 个帖子 - 2 位参与者 阅读完整话题
太久没上论坛，感觉发生了翻天覆地的变化。最近在给公司做Dify企业应用开发，学到了很多新东西，给佬们开开眼界。 起因是要设计图文混排的工作流（workflow），因为是后端异步调用dify，所以不用担心耗时的问题。因此最初我的设计是先让LLM输出完整的内容，然后再让另一个LLM理解这些内容，输出一个对象数组，每个对象包含文生图提示词以及图片在内容中的位置（这里采用的方案是按\n\n分割内容，然后计算图片在分割数组中的索引），循环调用文生图工具，将图片上传oss后将oss地址插入到内容中，最后返回。 最近提了个新需求，要求给dify的对话流（chatflow）开发图文混答，由于这次是文本图片采用流式输出，就必须考虑耗时的问题了。然而市面上的教程清一色的都是构建知识库，然后在知识库文档中引入图片地址，这样AI检索到图片地址就能完整的输出。但是这种方式非常依赖知识库，而我们的场景主要是医疗领域（产品很多地方借鉴了阿福，只不过我们是针对私域的，而非公众通用），知识库数量庞大，并且维护困难。 就在我一筹莫展之际，我找到了这篇文章： baijiahao.baidu.com 苹果研究团队：AI实现图文理解与生成统一框架能力提升突破 通过AI解读和理解之后，给出方案为先规划后生成，并且用两个迭代节点并行生成文字和图片，通过代码调度控制输出的节奏。比如：规划LLM给出一个对象数组，大致如下 [ { "id": "text_1", "content": "第一板块的概括内容", "depends": [], "index": 0 }, { "id": "image_1", "content": "基于[text_1]的内容，生成图片：高科技宣传图，蓝色主色，未来风", "depends": ["text_1"], "index": 1 }, { "id": "text_2", "content": "第二板块的概括内容", "depends": ["image_2"], "index": 2 } ] 完成生成的内容会写入队列（Redis），每次输出前都会从完成队列中读取所有未消费的项，判断当前项是否有依赖，依赖项是否完成，是否消费，同时依赖项的依赖项是否完成以及是否消费（递归），满足条件的按照index排序，确保输出顺序正确，最后拼接和输出。当然，这里我只是简单概括，实际逻辑要更复杂，大概是这么个意思。 测试流程效果: 现阶段的问题还是出现在循环里的文字生成LLM的提示词不够完善，由于架构的弊端，AI每次循环生成的段落可能重复，加上有一些特殊的业务需求，模型不给力就靠蒙，只能用qwen3.5plus才能勉强满足要求。 不过工程问题都好解决，优化一下速度还是能够落地的。 1 个帖子 - 1 位参与者 阅读完整话题
（话题已被作者删除） 1 个帖子 - 1 位参与者 阅读完整话题
工具用的是 Coze + Dify + n8n+Ollama ，搭了三个 demo： 自动抓网页 + AI 总结 + 发邮件 FAQ 知识库 + 客服 Chatbot 定时生成推文 说几个踩坑： n8n 连 Ollama 不能用 localhost ，得写 127.0.0.1 ，卡了一个小时 QQ 邮箱 SMTP 在 n8n 里完全不通，换了几个姿势都不行 Coze 免费点数用得太快，只够跑两个 demo 感受：AI Agent 开发门槛比想象的低，但工具链对国内用户不太友好。Dify 体验最好，Coze 其次，n8n 本地跑坑最多。 有也在搞 AI Agent 的兄弟吗？交流一下。
工具用的是 Coze + Dify + n8n+Ollama ，搭了三个 demo： 自动抓网页 + AI 总结 + 发邮件 FAQ 知识库 + 客服 Chatbot 定时生成推文 说几个踩坑： n8n 连 Ollama 不能用 localhost ，得写 127.0.0.1 ，卡了一个小时 QQ 邮箱 SMTP 在 n8n 里完全不通，换了几个姿势都不行 Coze 免费点数用得太快，只够跑两个 demo 感受：AI Agent 开发门槛比想象的低，但工具链对国内用户不太友好。Dify 体验最好，Coze 其次，n8n 本地跑坑最多。 有也在搞 AI Agent 的兄弟吗？交流一下。
这种多模态的Embedding模型有没有现成能直接调用的工具 1 个帖子 - 1 位参与者 阅读完整话题
问题是这样的： 我们最近在测试时候发现一个问题，在Dify中通过Prompt构建一个了一个agent，Prompt做了角色定义，行为，工作流程，输出的相关约束，但是又一次偶然的机会对接错了API，发现不加这些prompt，模型也可以很好的按预期进行输出。这样就带来了一个问题，我们以为可以有效约束模型输出的各类手段，怎么能确定其哪些部分是真的有用，哪些是过度工程化或主观的感觉。有没有一个这样的可以对包括Prompt和Skill这些手段有效性进行benchmark和测试评估的手段。 3 个帖子 - 3 位参与者 阅读完整话题
【实践分享】如何手搓一个RAG 前言 1.之前有看到佬友分享使用dify的悲伤经历，还有搭建知识库踩过的坑，在下面我也评论了一下，佬友希望我开贴细说一下，今天写在这里。 2.项目是24年的，但是我也没什么很深厚的理论基础，毕竟23年GPT才开启第一波开源；然后我真正手搓项目是在24年，所以这个分享可能有点简陋；并不是我不愿意分享自己的知识，只是我的理论其实也很薄弱，拿的出手的只有一点实践。 关于RAG的回忆 23年，我们对大模型的应用还很薄弱，当时业界有两个分支： 1.用原生大模型，用不同的问法。（这个就是后来提示词工程和rag的原型） 2.微调大模型。（当时的主流方法我已经不记得了，我只记得我试过了没有） 因为严格意义上来说，我并不是一个底层的AI开发，我是属于AI应用开发。微调我实在是整不明白，其次，微调需要很多语料，当时的知识库并没有被很多公司接纳，我得到的语料其实就那么几十个文档。 衡量利弊之下，我选用了方案一。那么接下来有两个东西就很重要了：提示词、知识库。 上面说的这些其实都算免责申明了，很菜，别骂。 回忆结束，进入正题。 RAG流程 检索增强生成 有一套比较简单的流程： 用户提问->文档检索->提示词拼接文档，发给大模型->大模型返回结果 但是我要讲的是一套稍微复杂一点的流程： 用户提问->问题重写->意图识别（可以不要）->文档检索->提示词拼接文档，发给大模型->大模型返回结果 这个我会在下面展开讲。 用户提问与提示词 后端接收到前端传来的用户提问。 我们当然不可能直接把用户的提问传给大模型，就说最简单的，我们在 messages=[ {"role": "system", "content": "You are a helpful assistant. Help me with my math homework!"} ] 这个json里面写的东西，其实就是我们的提示词。他是我们使用大模型的开始，也是大模型能够更精确回答用户问题的开始。 问题重写（连续对话的根本） 问题重写，顾名思义就是把用户的问题，进行重构。当时的大模型并没有那么长的上下文，不能像现在一样，把用户和大模型的对话全部发给大模型。而且，过长的报文带来的是过长的等待时间和非常差的用户反馈。 因此，问题重写就出现了。这样说可能不够明确，我给大家举个例子吧。 以下这个是很简单的对话： messages=[ {"role": "system", "content": "You are a helpful assistant. Help me with my math homework!"}, {"role": "user", "content": "Hello!"} ] 但如果用户进行了十几轮的对话呢，就会变成下面这样。 messages=[ {"role": "system", "content": "You are a helpful assistant. Help me with my math homework!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hello!"}, ] 我们不可能把这种message全部传给大模型的，当然，实际生产的情况更复杂，但无论如何，我们不可能把所有的上下文全部传给大模型。 那有人会问了，那我只传最新一次的不就好了？ 是的，效率提升了，但是大模型连续对话的能力没有了。 所以我们要压缩上下文，在压缩上下文的同时，还需要最大程度地保证上下文是有意义的、能够讲明白用户问题的。 最简单的方式，就是把用户当前最新一句话，以及前几轮对话+我们预先写好的提示词，传给大模型，让他进行问题重写。然后用这个问题重写的结果，作为 真正的用户提问 。 这里举一个真实的例子： user：Ame是谁？ assistant：Ame 是Dota2职业选手王淳煜的ID。 user：他在哪个队打过？ 重写后： user：Ame（王淳煜）在哪些Dota2战队效力过？ 意图识别 应用场景： 如果知识库过多，或者你的机器人（现在叫智能体）功能比较多，你要识别用户是不是想进行知识问答。 实现方式： 这里的实现方式有很多种，最简单的是直接让大模型对用户的提问进行意图识别；难一点的就是让大模型进行意图识别并在代码中进行处理。 好处和坏处： 好处是我们这样之后，文本检索可能会更准，比如我们有30个知识库，先通过意图识别进行一次初筛，然后对对应的知识库进行检索。 坏处就是链路变长了，速度变慢了。 但是，经过我的实践发现，在多知识库、多工具、多业务入口时，这是不可缺少的一环，而且这一环最好和用户进行交互后完成。不然用户不仅会骂机器人笨，还会说机器人胡言乱语。 文档检索（重点） 接下来是文档检索，我们需要准备一个向量化模型、一个向量库。 知识库构建 知识库 有人总是把知识库的构建说的很高大上啊，其实很简单，就是把文档向量化，然后存在向量库里面。 这就是知识库。知识库的质量就是文档的质量，知识库的效率就是向量库的查询效率。 文档分块 为什么我的知识库是依托答辩？ 为什么我的问答机器人总是胡言乱语？ 明明我把文档给他了，原文我都看得明明白白在这一页了，为什么他就是答不上来？ 就是因为你分档分块有问题。 我一开始手搓的时候，用的是FAISS向量库，当时是500个字一个块。这就有很大的问题了，段落会被截断啊，明明是同一个章节的内容，他就是识别不来。 那么有人会说了，那我们把章节也加上去。那你加到几级标题呢，文档名称要不要加呢？ 你先别急着回答，我也不会回答，因为这个要具体问题具体分析，需要结合实际情况调测。但我很明确告诉你，无脑加是不行的。 那么那些很吊的RAG，他们是怎么分块的呢？ 我这里慢慢介绍大家优化分块的方式，首先第一个是 分块重叠 。 分块重叠（chunk overlap） 分块重叠是系统切分时让相邻 chunk 共享一部分内容 。比如： 分块500字，重叠100字。 那么实际上我们得到的分块结果是： 第一块：0-500字。第二块：400-900字。第三块：800-1300字。 这样做的目的不是让每个分块变大，而是避免文本语义被切断。举个最简单的例子。 原文： 在日语里，ame通常写作「雨」，意思是“雨”。所以看到ame ga furu， 一般可以理解为“下雨”。但在下面这段电竞报道里，Ame不是日语单词， 而是Dota2职业选手王淳煜的ID。 他在这场比赛中使用幻想系一哥们完成收割，帮助队伍赢下团战。 如果没有分块重叠，那么切块的结果是 分块1: 在日语里，ame通常写作「雨」，意思是“雨”。所以看到ame ga furu， 一般可以理解为“下雨”。但在下面这段电竞报道里，Ame不是日语单词， 分块2: 而是Dota2职业选手王淳煜的ID。 他在这场比赛中使用幻想系一哥们完成收割，帮助队伍赢下团战。 你提问：ame是谁的ID？ 大模型回答：ame是雨的ID，因为你命中分块1的概率更高。 加上分块重叠后，切块的结果是 分块1: 在日语里，ame通常写作「雨」，意思是“雨”。所以看到ame ga furu， 一般可以理解为“下雨”。但在下面这段电竞报道里，Ame不是日语单词， 分块2: 但在下面这段电竞报道里，Ame不是日语单词， 而是Dota2职业选手王淳煜的ID。 他在这场比赛中使用幻想系一哥们完成收割，帮助队伍赢下团战。 这时候的答案就完全不一样了。 那有人会说了，两段一起传不就好了？直接两个分块怼过去： 分块1: 在日语里，ame通常写作「雨」，意思是“雨”。所以看到ame ga furu， 一般可以理解为“下雨”。但在下面这段电竞报道里，Ame不是日语单词， 分块2: 而是Dota2职业选手王淳煜的ID。 他在这场比赛中使用幻想系一哥们完成收割，帮助队伍赢下团战。 是可以的，但是两段一起传属于另一个优化方向： 知识库的检索之Top-K 。我还没说到检索方面的优化，我现在在讲的是知识库构建方面的优化。 那么我们还有什么其他的优化方式呢？ 语义分块 方法一： 这个比较无脑很好用，既然分块那么麻烦，我直接用大模型分块不就是了？ 我的超级智慧告诉我，用大模型就完事了。 既然写代码那么麻烦，我交给codex不就是了。 放弃所有思考，agent代替大脑。 方法二： 老老实实搞点语义识别的边界，例如：标题、小节、段落等。 给分块补内容 这是前面说的给分块补内容，就是在分块里面加标题和信息来源。也是用刚刚的例子： 标题：Ame的不同含义 来源：电竞术语说明 正文：在Dota2语境中，Ame通常指职业选手王淳煜。 父子分块（超级常用） 你叫父子分块也好，你叫小块检索+大块返回也罢。反正就是这么个玩意，稍微说一下区别吧。 小块检索+大块返回： 向量化的时候，我只向量化其中100个字，但是我存在向量库里的结构，包括了前面的50个字，和后面的50个字。这样我实际检索出来的内容其实是200个字。这里我要换个例子，不能用之前那段话了： 标题：Ame的不同含义 Ame在日语中可以表示“雨”，写作「雨」，读作「あめ」。 例如ame ga furu，意思是“下雨”。 但在Dota2语境中，Ame通常指中国职业选手王淳煜的比赛ID。 他长期担任核心位选手，因稳定的后期能力被很多玩家熟知。 接下里小块切分： 分块1： Ame在日语中可以表示“雨”，写作「雨」，读作「あめ」。 分块2： ame ga furu 的意思是“下雨”。 分块3： 但在Dota2语境中，Ame通常指中国职业选手王淳煜的比赛ID。 分块4： 他长期担任核心位选手，因稳定的后期能力被很多玩家熟知。 检索时，用小块去匹配问题。 用户问：dota2里的ame是谁？命中分块3，但是实际上我们会传给大模型一整段。 大模型回答：dota2中ame是王淳煜的ID，他是核心位选手。同时，ame还在日语中表达“雨”。ame取这个名字为id可能表示了他对雨的喜爱。 这时候用户就会想了，我靠，这个大模型这么聪明啊，居然还有引申！ 其实是我们传的。 父子分块： 对大章节进行语义汇总，作为父块，每一个不同部分作为子块，检索时用子块，更精确，回答时带上父块，上下文更完整。依旧举例： 父块：一整节，讲Ame的不同含义 子块1：Ame在日语中的含义 子块2：Ame在 Dota2中的含义 子块3：如何根据上下文区分Ame 一样的情况，这里我就不举例了。 知识库检索 知识库的检索，简而言之就是把用户的问题向量化，然后去向量库里比对向量相似性，然后把相似性最高的拿出来，这段文本里的内容，就是用户问题的答案。 但是你懂的，生活总是艰难的，一如检索到正确的文本。 最最简单方法之向量相似度。 向量相似度 不管有的没的了，我直接： select * from table where col like '%我的问题%' 当然，这个是写给懂sql但是不懂向量库的同学看的，原理不是这样，但实际情况差不多。 实际上向量相似度是一个数学概念，知识库会把每个分快转化为embedding向量（我很不喜欢说英文概念，但是embedding的中文我是真不常说）。然后把你的输入条件也转化为向量，最后通过余弦相似度、点积或者欧式举例，返回他们之间的距离或者相似度。 注意，向量相似度本身只是数学距离，它不等于真正理解语义；只是因为embedding 模型会尽量把语义接近的文本映射到相近位置。所以向量检索能做语义近似，但效果高度依赖embedding模型质量。 比如Dota2这个游戏，聪明的embedding会把这一整个当成一个名词，笨一点的分词结果为:D,o,t,a,2。结果显而易见，一个词被分成了5个字母，语义直接被切碎了。 语义相似度 两段话字面上不一定一样，但表达的意思很接近。 这个也是靠embedding模型实现的，同样的例子我甚至可以再说一遍，比如Dota2这个游戏，聪明的embedding会把这一整个当成一个名词，笨一点的分词结果为:D,o,t,a,2。结果显而易见，一个词被分成了5个字母，语义直接被切碎了。 那么有人会问了，那和上面的也没有区别啊。 是的，严格来说，向量相似度和语义相似度不是两个独立的检索方式。 在RAG里，我们通常是先用embedding模型把文本转成向量，再计算向量之间的距离。这个距离就是向量相似度。 而我们真正关心的是：两段文本的意思是不是有关来拿。这个叫语义相似度。 所以可以这么理解： 向量相似度是系统实际算出来的分数；语义相似度是我们希望这个分数能够代表的含义。 embedding模型越好，向量相似度就越接近真实的语义相似度。 Top-K 中文翻译：“取前 K 个结果”。依然举例： Top1：Ame是Dota2职业选手王淳煜 Top2：Ame在日语中表示雨 Top3：PSG.LGD战队介绍 Top4：Dota2职业选手列表 如果 K=3，就取前三个。 因为Top-K不是一种复杂算法，它更像一个参数： 召回多少条候选内容 。 K 太小，可能漏掉正确答案；K 太大，噪声会变多。 关键词检索（BM25） 顾名思义就是用专有名词、编号、术语、代码、产品名之类的东西，直接进行关键词匹配。 多路召回 其实就是在检索的时候，用很多种方式进行检索，得到不同的答案，然后合并、去重、重排，得到一个或几个最终的结果（这里也是可以给定参数的）。有点类似于 异质集成学习 。 直接上用法： 1.向量召回：找语义相近的内容 1.关键词召回：找包含Ame、Dota2、王淳煜的内容 1.元数据召回：限定domain=电竞、game=Dota2 1.标题召回：优先匹配文档标题、章节标题 1.问题改写召回：把问题改写成多个版本分别检索 2.用某种方法集成、返回给大模型 加个序号，代表前面4个是并行的。 rerank重排序 王中王，文档检索真正的王。但是非常非常非常吃性能。 你不用这个，5s回答完毕，你用这个，30s回答完毕。 比如你得到了20条文档检索结果，重排序模型会把最适合回答问题的分块，放到最前面。 混合检索（常用） 我们要知道的是，数据库的检索方式并不是多选一的，而是可以一起使用的， 例如：向量负责语义、关键词负责精确匹配、rerank负责最终排序 这样我们得到的结果会更加精准。 图谱检索（基于知识图谱的检索） 适合实体关系很强的知识库。 比如一个东西有别名，或者说映射关系很明显的时候，会用到这个。 它在组织关系、产品依赖、法规条款、故障链路、人物关系里其实挺有用。 但是这个搭建成本太高，不是所有知识库都值得做。 提示词拼接模板，发给大模型 这里就结合业务、检索结果、写一段提示词，发给大模型。 大模型返回结果 有人会说了，大模型返回结果不是很简单的么，这个也算流程之一？ 算了。实际运用的时候，你不仅希望大模型告诉你答案，你还希望他告诉你答案是哪里来的，所以返回的结果我们是要加工的，比如来自哪个段落、来自哪个文件。这些东西大模型是不知道的，需要你在手搓的时候，留个字段来存。 总结 纯手搓，里面可能有很多错别字，主要是答应了佬友要写，赶工出来的。先发后改。尽量做到不误人子弟吧。 3 个帖子 - 3 位参与者 阅读完整话题
如题突然想起来现在用dify、n8n、coze这些多吗？ 1 个帖子 - 1 位参与者 阅读完整话题
现在比较火的那种使用整个文档为知识库那种叫什么开源项目来着？ 好像是前阵子提出的，不是dify这种rag这种。我忘了叫什么来着 7 个帖子 - 4 位参与者 阅读完整话题
<1> 背景 自动化测试代码维护这行干了挺久，以往基本是在和内部框架打交道，以往工作实属不难，只能说测试以及Debug比较耗时间精力 后来上面也想与时俱进一下，就想着结合AI搞点辅助我们工作的东西，想法是美好的 团队里有一套长期演进的内部工程体系，配置、脚本、规则和经验散在不同地方不同人。 新人要改一个东西，有时要问老同事；老同事也不一定每次都记得准，只能继续翻文件、搜历史、看代码。 于是很自然地想到：那就做一个 AI 知识库吧。 最初的预期很朴素： 把文档、规范、经验整理进去 用户用自然语言提问 系统检索相关知识 大模型组织答案 听起来没毛病，甚至很符合最初大家对 RAG 的想象。 但真正落地后才发现，内部业务知识和互联网公开文档完全不是一回事。 公开文档通常是"解释型"的：这个 API 怎么用、这个参数是什么意思、底层模块解释等。 我们的内部问题更多是"操作型"的：我要改一个现有流程、调整一个规则、关闭一个子项、增加一个步骤、定位一个历史遗留逻辑。 这两类问题看起来都叫问答，但需要的系统能力完全不同。 所以问题不是"能不能用 AI"，而是"怎么让 AI按既定思路来理解"。 本地部署ai以及在vscode基础上做一个自己的业务汇总软件再基于cline改个有基础agent功能的插件，细节不赘述。 <2> 第一阶段：上了 Dify 当时的想法 Dify 嘛： 文档丢进去 切 chunk 做向量 用户问问题，相似度召回 AI 回答 实际效果 各类实际术语听不懂 AI拿到项目不知道从何开始，直接一顿召回一顿搜本地项目文件，实际各种答非所问完全靠大模型自己发挥 Dify 这套方案适合：文档类问答，知识相对固定，用户问法相对规范，需要一直自我调整 我们的问题是：业务实操类，问法千奇百怪，业务理解需要特定思路。 其实换个说法就是：把人对这项目各方面的理解思路等等抽成skills哈哈 但是细调用Dify软件就很不方便了，索性放弃Dify <3> 第二阶段：自建路由 核心思路 先听懂意图，再谈检索 。 这一步其实不是先研究模型，而是先把自己平时遇到的需求拆开。 先把这些常见业务动作分出来，再针对每一类动作设计不同的处理路线。 然后再兼容用户真实问法。中文、英文、缩写、符号、口语表达都要算进去。如果不先统一到同一个意图，后面检索再准也没用。 最开始当然也有关键词规则，后来逐步加上 embedding 和语义分类。简单说，就是不只看用户用了哪个词，还要看这句话整体更像哪类需求。 为了提高稳定性，又加了一层小模型兜底。当前面的规则和语义分类都不够确定时，再让小模型辅助判断一次。它不是负责最终回答，而是负责把问题分到更合理的路线里。 再往后，就是把我们对项目的理解、业务维护经验、常见判断逻辑整理进 RAG。这个过程有点像把人的经验拆成一组组 skills：每类问题都有自己的判断方式、需要看的材料、不能踩的坑。 但它又不完全等同于传统 skills。传统 skills 分散在各处，后面维护起来容易散；RAG 这边有一个相对集中的知识入口，可以单独调路由，也可以单独调知识内容。对这种业务落地场景来说，反而更好维护。 <4> AI不走原定路线 路由做完后，又遇到一个很典型的问题：AI 有时不按你设计好的路线走。 很多需求其实只要进入对应路由，把输入拆好，再查对应知识，就能稳定完成。但模型有时会"觉得自己能行"，上来就直接开始自己读文件、猜结构、自己组织答案。 还有一种情况是多轮对话。用户第二句明明是在补充上一句，打个比方比如"那把它改小一点"，模型却把它当成一个全新的问题处理，完全不管历史上下文里的"它"是谁。 这类问题光靠提示词里说"请优先走 RAG"是不够的。因为模型一旦进入自由发挥状态，就很难保证每次都守规矩。 后来做法变成：先检测当前项目是否属于我们已知的业务项目。如果是，就在底层强制加规则，让它优先走固定 RAG 路线，而不是随便读文件和自由发挥。 这样做以后，系统不一定一下子变得非常聪明，但至少变得可诊断了。答错的时候可以看出来：是项目识别错了，是路由错了，是知识没召回，还是模型最后总结跑偏了。 <5> 人工汇总知识不够用易过期 走到这一步后，AI 已经能处理一些简单、固定流程的业务需求了。但新的问题也很明显：知识库不能只靠人工写。 人工总结的知识短期有用，但长期会遇到三个问题。 第一，维护成本越来越高。后续可能项目在变，文档也要跟着变，靠人手动同步迟早会漏，其实推广到别的项目也容易变。 第二，答案会逐渐不可信。知识写进去的时候是对的，不代表几个月后还对。内部项目最怕的不是"不知道"，而是系统拿着过期知识自信地指导用户。 第三，模型有时会为了补上下文读太多内容。看似更努力，实际会增加 token 消耗和服务压力，而且读得越多，越容易把不相关内容混进来。 所以后面思路又变了：不能只把项目当成一堆文档，而要把它看成一张结构网。 一个业务对象可能关联配置、规则、动作入口、脚本、命令、上下游顺序。靠纯文本相似度去猜这些关系，不稳定，也浪费。 于是开始尝试走LangChain + neo4j路线把项目内条目切离结构抽取，再把这些关系放进图谱。 图谱不是为了替代 RAG，而是给路由结果提供更精准的背景补充：这个对象在哪里、它关联哪些东西、下一步该查哪类材料。 这样原本"靠模型自己理解项目"的问题，就变成了"先由系统把结构上下文准备好，再让模型基于这些上下文回答"。 (小小的吐槽一下：其实到图谱前这个就已经基本实现功能了，最核心最主要是上面觉得要图谱才放心,因为别人好像什么王道路线就是那么走的，没办法胳膊肘拧不过大腿不是吗 手动滑稽 ） <6> 展示层也要自己做 结构抽取图谱建出来以后，本以为可以直接用数据库工具展示。实际又踩了一个坑。 neo4j数据库浏览器适合工程调试，不适合业务展示。比较好的图谱浏览能力都在企业版里， 普通版本虽然能证明"数据确实在里面"，但对普通用户来说，看到的常常只是一堆点和线。 我最开始就只是部署到容器里测试，怎么看怎么别扭以为得下个软件，结果实际还是得付费了属于是 用户不关心数据库里有多少节点，他关心的是：这个对象为什么会关联到这些东西，我要改它应该看哪里。 所以展示层也得自己做。 这个浏览器不追求通用图数据库能力，只服务当前业务： 打开后默认展示一个对象的局部关系 节点按业务类型着色 边显示关系含义 支持搜索、点击查看详情、逐步展开 隐藏原始大段内容，只展示对维护有用的信息 它的目标不是替代数据库，而是把图谱翻译成业务人员能看懂的界面。 后续如果用户能自己搜索对象、展开关系、点节点看详情，再结合 RAG 给出的解释和修改建议，就比较不戳了"。 <7> 过程中最大的几个教训 1. 不要把 RAG 理解成"文档问答" 文档问答只是 RAG 的一种最简单形态。 内部业务场景里，用户往往不是来问"这段文档什么意思"，而是要完成一个动作。动作需要结构、规则、上下文和边界。 如果只做文档问答，很容易一开始看起来能用，深入使用就暴露问题。 2. 意图识别比召回更早出问题 很多人调 RAG 时第一反应是调 chunk、调 embedding、调相似度阈值。 这些当然重要，但在操作型场景里，更早的问题是：系统有没有判断对用户要做什么。 意图错了，召回越准越危险，因为它会在错误方向上给出很完整的答案。 3. 结构化知识比堆文档更重要 文档越堆越多，不等于系统越懂业务。 有些知识应该写成说明，有些知识应该从项目里自动抽取，有些知识应该建成关系，有的知识需要把人的理解抽出来 把所有东西都塞进向量库，只会让问题变得更难诊断。 4. 展示工具会影响认可度 这是后来才意识到的。 同样一套图谱数据，如果只在数据库浏览器里展示，普通用户会觉得乱不知道干啥的；如果用业务视角重新组织，用户才会觉得"这个东西能用"。 所以展示层不是锦上添花，它会影响别人对系统成熟度的判断，也方便用户检查 9 个帖子 - 6 位参与者 阅读完整话题
有没有类似当初的 MJ 的 iOS 课程开发一样的 coze 或者其他工作流视频啊？愿意付费
有没有类似当初的 MJ 的 iOS 课程开发一样的 coze 或者其他工作流视频啊？愿意付费
有没有类似当初的 MJ 的 iOS 课程开发一样的 coze 或者其他工作流视频啊？愿意付费
提示词如下 # Coding - You must apply approve before modifying the code, but you don't need to apply for consulting. - Coding must AI-AGENT SUSTAINABLE AND HUMAN READABLE - Actively use subagents and suitable skills to solve the problem. # Communication Rules - Always answer in Chinese - Use markdown headings - Use tables when comparing - Use ascii graphics for architecture - Be concise but readable - Avoid raw file dumps 不加提示词的回复太干巴了 2 个帖子 - 2 位参与者 阅读完整话题
1 个帖子 - 1 位参与者 阅读完整话题
想招几位靠谱的兼职专家一起合作， 目前主要方向是： Coze / Dify 工作流 AI 智能体搭建 内容自动化 / 公众号协作 更看重： 真实项目经验 理解需求的能力 配合度和交付稳定性 不是临时接私活模式， 而是想找能长期协作的人。 有兴趣的可以来聊。 +v:13371782660
因为移动开发的工作日常检查扣分太多，被转岗为公司搭建 DIFY ，当时说的岗位职责是给运营提供 DIFY 的技术帮助，结果人家运营的 DIFY 玩的比我 6 多了。偶尔有几个同事提问，我用 Claude 根本解决不了。现在的工作还涉及制表，汇报，快把我逼疯了。Claude 并不能帮我制作在线共享表格，请问大家有什么建议吗？