下载llama factory

llama-factory是一个零代码大模型训练平台,可以快速搭建模型训练环境,并提供丰富的模型训练功能。可以选择前往github下载llama-factory项目的压缩包。但我下面是直接命令行下载的,但其实差不多,就是不用git clone https://gitee.com/hiyouga/LLaMA-Factory.git下载,自己手动下载到本地。



用框架自带的requirements.txt去下载安装相关依赖,完全匹配当前分支的依赖版本,避免 “手动指定版本出错”。

安装好后可以执行llamafactory-cli version来快速校验安装是否成功,如下界面就是安装成功了,然后执行运行webui.py的代码就可以得到下图界面





当你选择大模型时可以发现有很多版本,这些模型名称中的后缀(Chat/Math/Base)代表不同的模型定位和用途,针对 “微调大模型” 的需求,选择逻辑如下:





下面时出现的一些下载情况,走了很多弯路,为啥下面我一开始非要单独下载一些依赖,导致很多依赖的版本都互相冲突。所以下面内容可以不看。
在anaconda中创建

出现如下报错



当我下载安装好git就可以了,注意下载时,可以放在自己想放的位置,其实不同在本地cmd中执行也可,在虚拟环境下是一样的。





注意执行 下面的llamafactory核心依赖时,要在llamafactory的根目录下执行,不然会出下面如下报错

问题不是路径本身的问题,也不是 “虚拟环境存储路径” 的问题,而是你执行 pip install -e ".[torch,metrics]" 时,当前目录不是 LlamaFactory 的代码根目录—— 这条命令必须在包含 setup.py/pyproject.toml 的 LlamaFactory 文件夹内执行,否则 pip 找不到安装配置文件,自然会报错。

之前用 git clone 下载的 LlamaFactory 代码,完整路径应该是:D:\software\liulanqi\weitiao\llamafactory\warehouse\LLaMA-Factory(进入这个文件夹,能看到 setup.pywebui.pyrequirements.txt 等文件,就是正确目录。在对应目录下执行下面这条命令就可以

之前在 warehouse 目录执行 pip install torch 能成功,但执行 pip install -e ".[torch,metrics]" 失败,核心是这两条 pip 命令的逻辑完全不同—— 前者是 “安装公共库”,后者是 “安装当前目录下的本地项目”(LlamaFactory 这个开源项目),核心依赖当前目录的配置文件。


如上图所示还是出现了问题,这是安装numpy时触发的编译环境缺失错误,原因是 Windows 系统缺少 C/C++ 编译器(比如 Visual Studio 的编译工具),导致numpy无法从源码编译安装。



这样就可以顺利安装好依赖了。

如下命令安装可选依赖

执行第二条命令时出现如图报错



这个报错是依赖版本冲突:安装bitsandbytes时,pip 自动把你的torch版本升级到了2.9.1,但原来的torchaudiotorchvision是依赖torch==2.1.0+cu121的,新版本torch 2.9.1和它们不兼容。

执行完上面代码觉得可以了后,通过使用 llamafactory-cli version 来快速校验安装是否成功。出现如下图报错,transformers 库版本与 torch 版本不兼容导致的:因为transformers 新版本用到了 torch.utils._pytree.register_pytree_node,但你当前的 torch 2.1.0 中这个接口还没开放(或命名不同)。



但是明明没手动执行pip install transformers,但transformers却出现在环境里,核心原因是执行pip install -e ".[torch,metrics]"时,pip 会自动下载 / 安装 LlamaFactory 声明的依赖,transformers就是其中之一--no-deps如何阻断这个自动下载?不加--no-deps:pip 会 “先装依赖,再关联 LlamaFactory”,且优先装最新版依赖(导致 transformers 升级到 4.36+);加--no-deps:pip 会 “跳过所有依赖的安装 / 升级,只关联 LlamaFactory”,完全不碰 transformers、torch 等库。

先卸载

正确的依赖安装顺序

但安装第一步时发现如下报错,卸载再去安装又和别的依赖冲突了。



报错太多实在时一直出现版本安装问题,直接执行pip check会很清晰。



发现处理pip check,还有如下命令可以很好的查看依赖情况。



因为出现的依赖问题太多,后来我直接删除了虚拟环境,重新下载依赖





这是之前发现的一些问题。

发现下图问题,下载的 LlamaFactory 代码包不完整 / 分支不对,导致缺少 Web UI 核心文件(webui.py),可能用git clone --depth 1只克隆了最新版本,但如果仓库的默认分支没有 Web UI 文件,就会缺失,但其实明明webui.py文件就在src文件下。这个ai骗我。

考虑到上面出现的两个问题,所以下面打算清除之前下载的内容(下载的llamafactory框架,就是删除这个文件夹即可),重新来下载。

如下重新下载,注意可以切换到自己想要的路径下下载,可以在cmd中下载,也可以在虚拟环境中执行。



Read more

智能客服对话机器人设计全流程:从架构设计到生产环境部署

最近在做一个智能客服项目,从零开始搭建一个能实际处理用户问题的对话机器人,踩了不少坑,也积累了一些经验。今天就来聊聊从架构设计到最终部署上线的全流程,希望能给有类似需求的开发者一些参考。 1. 背景与痛点:为什么需要智能客服? 传统的客服系统,无论是电话热线还是在线聊天,主要依赖人工坐席。这种方式有几个明显的痛点: * 人力成本高:7x24小时服务需要三班倒,人力成本巨大。 * 响应速度慢:高峰期排队严重,用户体验差。 * 服务质量不稳定:不同客服的业务熟练度和服务态度参差不齐。 * 知识难以沉淀:优秀的客服经验很难系统化地传承和复用。 而早期的“智能”客服,很多是基于关键词匹配的规则引擎。比如用户说“我要退款”,系统就回复一个预设的退款流程链接。这种方案的局限性非常大: * 理解能力弱:无法处理同义词、口语化表达和上下文关联。用户说“钱怎么退”和“我要退款”,在规则引擎里可能就是两条完全不同的规则。 * 维护成本高:业务规则一变,就需要人工添加大量新规则,容易产生规则冲突。 * 毫无灵活性:对话僵硬,无法进行多轮交互,用户体验像在和“人工智障”聊天。 正是这

无需代码!10分钟玩转RetinaFace+CurricularFace人脸识别

无需代码!10分钟玩转RetinaFace+CurricularFace人脸识别 你是不是一直觉得人脸识别技术很高深,需要懂编程、会配置环境、还要处理复杂的模型部署?现在我要告诉你一个好消息:完全不需要!即使你没有任何技术背景,也能在10分钟内搭建一个专业级的人脸识别系统。 本文专为产品经理、业务人员和对AI感兴趣的非技术人员设计。我们将使用ZEEKLOG星图平台提供的预置镜像,全程无需编写任何代码,就像使用普通手机应用一样简单。你只需要点击几下鼠标,就能体验RetinaFace+CurricularFace这个强大的人脸识别组合。 RetinaFace负责精准定位人脸位置,就像一双敏锐的眼睛;CurricularFace则负责识别身份,就像一个聪明的大脑。这两个技术组合在一起,能够实现准确率高达99%的人脸识别效果,广泛应用于安防、金融、社交等领域。 更重要的是,ZEEKLOG星图已经帮我们把所有复杂的技术细节都打包好了。你不需要安装Python、配置CUDA、下载模型权重,所有这些繁琐的工作都已经完成。你只需要关注最核心的问题:这个技术能不能满足我的业务需求? 读完本文后

Fanuc机器人与PLC的Ethernet/IP通信

Fanuc机器人与PLC通过Ethernet/IP实现高速通信的技术实践 在现代智能制造产线中,机器人与上位控制系统之间的实时、稳定通信是保障生产节拍和设备协同的关键。Fanuc作为工业机器人领域的主流厂商,其控制系统虽然封闭性强,但通过标准工业以太网协议如Ethernet/IP,依然能够实现与第三方PLC(如罗克韦尔ControlLogix、西门子S7等)的高效数据交互。 尤其是在汽车焊装线、装配工站或物料搬运系统中,我们经常遇到这样的需求:用Allen-Bradley PLC统一调度多台Fanuc机器人执行不同动作序列,并实时监控其运行状态、报警信息及I/O反馈。这种场景下,传统的硬接线DI/DO方式已难以满足复杂逻辑与高响应要求,而基于Ethernet/IP的通信方案则展现出显著优势——不仅布线简化,更支持结构化数据传输和远程控制。 那么,如何让一台Fanuc LR Mate 200iD或M-20iA真正“听懂”ControlLogix控制器发出的指令?这背后涉及硬件配置、网络参数设置、标签映射以及KAREL程序的协同配合。本文将结合实际工程案例,深入剖析这一集成过程中的关

低代码AI化爆发:OpenClaw成企业数字化破局关键

低代码AI化爆发:OpenClaw成企业数字化破局关键

企业数字化转型喊了多年,却始终卡在两难境地:纯代码开发周期长、成本高、迭代慢,中小团队耗不起;传统低代码看似快捷,却只能做简单表单和固化流程,适配不了复杂业务,智能化更是形同虚设。        如今低代码AI化迎来全面爆发,行业彻底告别“拖拽凑数”的浅层次应用,可多数平台依旧停留在AI插件拼接的伪智能阶段。直到OpenClaw的落地,才真正打通了低代码、AI与企业业务的壁垒,凭借原生智能体能力,补齐企业数字化的最后一块短板,成为转型落地的核心抓手。 一、行业痛点:企业数字化的三座拦路大山        抛开浮华的概念,企业做数字化转型,最怕的不是没工具,而是工具不实用、不落地,当前市面上的方案普遍存在三大硬伤,卡死转型进度: * AI与业务割裂:低代码搭载的AI仅能做表层代码生成、问答交互,无法深度理解业务逻辑、对接企业现有系统,智能能力用不上、落地难; * 开发门槛仍偏高:即便用低代码,仍需专人配置流程、对接数据、调试权限,业务人员无法自主操作,技术团队负担依旧繁重; * 数据安全存隐患:多数AI能力依赖云端接口,企业核心业务数据、经营数据需要外发,隐