加上qwen2token生成速度以及推理的增强 更要吹了 主要是qwen2对齐没有限制，这点挺好的，这样可以让安全也可以自动化。
https://github.com/QwenLM/Qwen-Agent
阿里这个agent就是用 react-cot agent + 相关片段的提取来解决多跳。具体内容看这个github链接，论文看https://qwenlm.github.io/blog/qwen-agent-2405/
但是依然还是有很多问题，比如上下文长度限制了提取很多文章内容的限制，代码上来看就是超过了几百Ktoken就截取前面一部分内容。
但是我觉得和langchain之前的内容一样 部分问题依然受限于长度 导致无法回答的很好，比如“结合相关欧洲和亚洲的近代史，请你告诉我地理因素对这2个板块的文明进程发展有什么影响”，有一些问题本身就是需要基于大篇幅的内容来进行回答，而且点可能很多，像这种问题就很难很好的总结，用阿里这套逻辑可以回答比以前好 但是无法很完美。并且结合了react，所以整个过程会消耗比较多的token，比如10M文档的话会全部input进去，然后做相关问题提取，得到1M回答。
当前的价格是：
10M文档大概是(按照anthropic和openai常见的token分词来算)
假设:
-
输入的10M文档包含4,000,000个token(取中间值)。
-
输出的1M回答包含400,000个token(假设回答的平均长度是输入的十分之一)。
-
在处理过程中,输入的文本token总数是输出的2倍(即模型对每个输入token平均生成0.5个输出token)。
费用计算:
-
模型调用-输入费用: 4,000,000 / 1000 × 0.02元 = 80元
-
模型调用-输出费用: 400,000 / 1000 × 0.02元 = 8元
反正一般上react的应用都很贵的。。尤其这种长文本+react 就是钱buff叠满的那种。。。llm用更便宜的qwenlong之类的来替代还差不多，不过qwenlong之类的llm token生成速度实在太慢了。跑完都一天了。rag应用也不是这么简单的，这个更像是个demo。因为中间从文件loader到封装metadata丢给llm，包括丢在上下文里进行关键内容查询，中间也要符合官方的prompt engineering，做应用还差点
总的来说这个架构其实不是很新鲜，但是贵在国产，中国人要有
自己的langchain ，自己的llm才行啊
原文始发于微信公众号（xsser的博客）：阿里开源的qwen-agent长文本agent RAG
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论