在今年以OpenAI为代表的LLM席卷全球前，笔者尝试了很多开源技术来进行实体关系的识别，发现中文环境下，百度的Paddle所展示出的效果最好的。一种更好的办法是，在提示中给出Json格式的输出样例，以确保LLM按照指定的格式输出结果，方便后续的程序统一处理，更加简单、方便。从目前的实验结果看，使用LLM进行实体关系的识别，较之前的技术，有了很大程度的提升。但在使用LLM的这种技术时，需要注意，不

从我们实验的效果看，除混元、Llama2外，其它四个大语言模型基本都能够识别出我们所要求的信息。输出格式的差异可以通过后续的处理程序对齐。信息抽取的有效性让我们充分看到了大语言模型在实体关系抽取这类作业上能力。它将为我们打通一些我们之前无法企及的应用效果的道路。

RAG，检索增强生成，即大模型LLM在回答问题或生成文本时，通过外挂其他数据源的方式来增强 LLM 的能力。使用外挂数据源检索出相关信息，然后基于这些检索出的信息进行回答或生成文本，从而提高回答的质量。外挂数据源可以是向量数据库、文档数据库、搜索引擎或应用系统等。RAG技术使得LLM在垂直领域应用时，不需要重新训练整个大模型，只需要外挂上相关知识库就可提供问答服务。从而节省了大模型的实施成本，同时

在「低代码+AI」的浪潮中，n8n 无疑是很多人心中的自动化神器。但当数据场景变得复杂、对智能化的需求越来越深时，n8n 也逐渐暴露出「不够用」的一面。于是，HuggingFists 这个「更懂数据、更懂智能」的国产新秀登场了。它不仅解决了数据难搞、模型难训、流程难调的老大难问题，还把这一切做得更优雅、更可视化。今天就带大家一起，重新审视「低代码 AI 平台」的新可能。最近，开源自动化流程工具n8

使用腾讯云技术栈搭建RAG(检索增强生成)的实验完成了。在这个实验中，我们主要利用了腾讯云的相关技术栈。但这种搭建方式可以扩展到其它的云端服务，可以最大限度的使用各类云端服务搭建起面向个人的RAG应用。实验中，我们引入了Cohere的文本重排算法，用于优化文本的相关度排序，减小提交到大语言模型的提示上下文的长度。这里有两方面内容需要权衡，一是成本问题，即Cohere的文本重排算法本质上也是收费的，

之前写了几篇关于如何使用HuggingFists系统搭建LLM RAG应用的文章。对于使用者来说，HuggingFists现在能带来两大点帮助。一是能够以低代码的方式快速处理客户的各类存量文档，如Word、Visio、PDF等。这些文档内容多样，其中不乏需要用到OCR等相关技术才能识别和抽取的内容；二是可以帮助使用者快速搭建出LLM RAG的研究环境，可以对比研究各LLM的差异，RAG的应答效果评

从搜索结果看，搜索出的内容都是与OpenAI相关的内容，错误描述非常相似。没办法，硬着头皮按OpenAI相关错误去解决问题吧，确实解决不了。只能尝试调整角色名称，好在后续报出的错误没查到雷同的信息。只能按照错误提示挨个试，从角色"tool"换成"function", 搞定。笔者团队一个月前为能够使系统可以支持AI Agent的应用，集成了通义千问的模型接口，特别是集成了其可以通过推理调用外部工具的

由示例可以看出，大语言模型的泛化能力能够非常精准的抽取文本中的实体、关系等知识信息。其能够大大提升知识提取的效率与准确性。HuggingFists低代码平台的出现进一步促进了知识图谱构建的效率。它大幅降低了知识图谱构建人员的技术要求，使得从事该工作的人员有了更大的选择范围。不断下降的构建成本，意味着可以有更多的客户享受到知识图谱带来的业务价值。

该问题是因为Jar包内的资源文件在被访问后，会被保存在装载插件的类装载器中。那么，一种合适的解决问题的办法就是，我们需要确保两次读取资源文件的类装载器不同就可以。那么当你升级Jar包插件并再次装载插件时，可能会碰到读取jar包内文件的代码处抛出“java.util.zip.ZipException: invalid distance too far back”异常的情况。在插件内部，我们可以在加载

于是，去年下半年，开始陆续出现了一些以LangChain作为基础的低代码类RPA工具，如：Flowise，LangGraph以及国内最近非常火的Dify等工具。这些工具的出现，进一步降低了LLM的应用成本和搭建AI Agent的成本。通过组件拖拽，可视化的构建数据处理流程和AI的应用逻辑，可降低对实施人员的编程能力要求，使得有经验的业务人员有机会参与工程落地；有别于现在流行的RPA类低代码平台，H