这是一个创建于 400 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景：交易数据分析，一份交易单等价为一个文件 目前在做 rag 落地相关的探索，尝试了 Dify ，FastGPT ，最后选择了 AnythingLLM ，单文件场景下效果很好。但是多文件场景下立马就不行了，比如我问它编号为 A 单的总金额，由于我上传了大约几百份文件，而每单的编号都在正文开头，总金额都在文末，怀疑是这个原因导致没法很好的进行上下文关联。 一份文件的字数毕竟多，chunk 没法开到太大，因此想问问有没有大佬知道这种情况怎么处理毕竟好
 | 1 mumu9 2024-09-21 16:39:50 +08:00 不太清楚你的“交易单”具体包含哪些信息。从你的描述看，更需要的是知识图谱。交易编号作为一个实体，金额和其他文件内容属于实体信息。对 Query 部分进行 NER 后，根据实体进行检索。 如果非用 RAG 不可，对文件内容进行内容压缩后作为 chunk 可能是更有效的方法。 |
 | 2 Suinn OP @mumu9 其实就是一大堆 word 文档，文档都是业务人员编写的，想看看能不能用 rag 节约点工作时间，不然每个文档一个一个找数据太麻烦了；大佬你说的内容压缩有什么关键词吗，搜了一圈没找到 |
 | 3 akira 2024-09-21 18:40:28 +08:00 可能要先进行结构化处理后， 再进 知识库会好一点。 |
| 4 mumu9 2024-09-22 13:28:06 +08:00 @Suinn 内容压缩简单点就是提取文件中的摘要，将这些摘要作为新的 chunk ，这样就不会出现超过 chunk 长度限制，也能最大限度保留上下文。我们之前的做法是让有需求的同事明确指出需要关注的主题和内容，然后根据他们的反馈，依赖 LLM 去确定文档中的关键信息，但可能不太适合你说描述的场景，因为交易单中的信息可能比较密集。 楼下 v 友的意思应该是让你们先把交易单中的信息比如提取出交易编号、金额、日期等关键信息，存储后进行检索。这个思路我们之前也做过，不过是依赖数据库，利用 function call 去处理查询的参数，然后在存储结构化内容的数据库中执行 SQL 生成响应。 另外的一个做法是你可以尝试使用比如 neo4j 这类的图数据库，将基于交易编号、金额、客户信息等实体进行关联和存储。这方面你可以参考 graphRAG ，不过不算太推荐就是了。 |
| 6 mumu9 2024-09-23 13:46:04 +08:00 @cheava 尝试下来的效果就是成本和收益不成比例吧。我个人的建议是不要在 RAG 上花费太多时间去尝试，收益很。目前看到的各种框架都属于指标战神，没有真正意义上能用于落地的。 |
Select Language