Why Your Rag Assistant Is Giving an Incorrect Answer Even Though It Found the Correct Document
A developer queries an internal AI assistant. The assistant looks up the documentation, finds a relevant troubleshooting document, and provides an answer.
You get an incorrect answer.
This can seem like a problem with retrieval. Maybe the embedding model didn't find the correct document, or the index needs rebuilding.
But when you look at the retrieved documents, the correct document is already there.
This means you're potentially dealing with a reliability issue. The RAG system has found the relevant information, but it isn't giving you a reliable answer. Improving the search alone won't necessarily fix it.
The issue can occur after retrieval, when the application decides which information to trust, what it means, and whether there's enough evidence to answer the question.
You have multiple stages in a RAG system.
A RAG system has several stages.
The application takes in a question, finds relevant information from documents, and passes it to a language model to generate an answer based on the context provided.
Every part of this process can affect the outcome.
Say you have an internal troubleshooting assistant with documentation for three environments: Development, Staging, and Production.
A user asks what to do when their tests fail in Staging.
The search returns a troubleshooting document with the correct information for fixing issues in Staging. It also returns a runbook with similar instructions for Production.
Both documents are relevant to the general topic, but only one applies to the user's situation.
If the assistant combines them, the answer may contain technically correct information but give the wrong advice.
The issue here isn't necessarily with the search engine. It's with the application not maintaining enough context to know which information to use.
Irrelevant documents can be returned.
Vector searches are designed to return semantically relevant information.
However, they won't necessarily return the most up-to-date, authoritative, or environment-specific information.
Say you have three documents in your knowledge base. All describe how to restart a service.
One is an up-to-date runbook. Another is an old troubleshooting note, and the third is an incident report.
A similarity search may return all three because they discuss the same service and symptoms.
The assistant then needs to decide which document should be treated as the source of truth.
For a well-designed RAG system, you'll need metadata such as environment, system, version, publication date, and document type.
This metadata should be used during retrieval wherever possible to narrow the results to information that applies to the user's request.
If someone asks about Staging, we wouldn't want to recommend Production instructions just because the error messages are similar.
This can't always be solved by writing a more persuasive prompt. Some restrictions need to be enforced in the retrieval and application layers.
Chunking can cause information loss.
Chunking is another common reason for misleading answers.
Long documents are often broken into smaller chunks. This makes them easier to embed and search, but important conditions can become separated from the instructions they apply to.
Say you have a runbook containing this instruction:
Restart the worker if the queue is stuck for more than 10 minutes.
Later in the document, it says this should only be done in a non-production environment and only after confirming that no jobs are running.
If the retrieved chunk doesn't include those conditions, the model may recommend an action that isn't appropriate.
The wording in the chunk may be correct, but the information is incomplete.
Teams should test whether important conditions are preserved throughout document processing and retrieval.
For procedural documents, keeping headings, warnings, prerequisites and related steps together may be more useful than creating equal-sized chunks.
Where possible, chunk boundaries should follow the structure of the original document.
Overconfident Answers
Say someone asks whether their integration tests are failing because of a recent deployment.
The assistant finds a deployment note and a few troubleshooting documents. None of them include the actual test execution logs.
The model may produce a plausible explanation based on similar issues, but there isn't enough evidence to confirm the cause.
A reliable assistant should distinguish between what is known and what remains uncertain.
It could respond with:
The deployment documentation describes a failure pattern similar to the issue you're facing. However, without the execution logs, I couldn't confirm the cause.
This answer is less certain, but it's more useful.
It tells the user what information is missing and what to investigate next.
RAG systems should be tested on whether they recognise when there isn't enough evidence to provide a reliable answer.
Check the citations.
Adding citations can make generated answers more transparent.
However, citations aren't useful if the referenced passages don't support the claims.
The assistant may cite a document discussing the correct service even though that document doesn't support its conclusion.
For example, a troubleshooting document may mention a timeout as one possible symptom.
The assistant might cite that document and confidently state that the timeout was caused by a recent deployment.
The citation looks legitimate, but it doesn't establish the cause.
Your evaluation should check the relationship between each claim and its cited passage.
In practice, you'll want to know whether the source supports the claim, whether it applies to the requested environment, and whether the assistant ignored contradictory evidence.
The presence of citations and the correctness of those citations should be measured separately.
Know where your issue is.
If your RAG assistant provides incorrect answers, you'll want to identify where the problem occurs.
This can be difficult if you're only testing the final response.
A useful approach is to break the evaluation into three areas:
- Retrieval quality: Did the search return the correct documents needed to answer the question?
- Context suitability: Were the documents current, applicable, and appropriate for the user's request?
- Answer grounding: Was the final answer supported by the retrieved evidence?
Say you have a test question with a known answer and a verified supporting source.
If the source never appears in the search results, retrieval needs investigation.
If the source appears but gets ignored during context selection, the issue is in the intermediate processing.
If the source reaches the model but the answer contradicts it, the problem is with answer generation or how the model uses the evidence.
Each of these issues requires
[程序员] 我在 2 核 2G 云主机上跑 OpenViking:一次关于云主机、模型选型与长期成本的真实复盘
最近把自己的 AI Coding Agent 记忆底座迁移到了自建的 OpenViking 上( OpenViking 真的满足我所有的要求:即是各种 Agent 的统一大脑自进化、又是知识库,检索的时候是两方面综合起来的)。RAG 相关的东西看着挺吓人,动辄推荐高配服务器和本地显存,实际上用下来,只要选型想清楚,一台几十块钱的入门级云服务器完全能跑得飞起。
这篇不是教你怎么敲命令的安装教程,只是聊聊折腾这一圈下来,在云主机、模型组合、算力开销上的一些真实心得和踩坑取舍。
1. 云主机:为什么我选 99 元的 2G ,不选友商更便宜的 4G ?
买云服务器时,第一眼很容易被一些友商“几十块钱买 4G 甚至 8G”的新客促销吸引。但我最终还是选了阿里云 99 元/年的 2 核 2G ( ecs.e-c1m1.large )。
核心原因就一个:算长期的续费账,避开“首年低价、次年暴涨”的套路。
如果只是搭个无状态的个人博客,一年一换、到处搬家无所谓。但 OpenViking 是你的记忆数据库,里面存的是日常所有的会话轨迹、沉淀的项目架构、实体图谱和向量索引,是强状态资产。很多友商首年 60 块,第二年续费直接跳到 600 、800 甚至上千,一年后为了省钱被迫停机、跨云拷贝几千兆数据、重新配安全组和域名解析,折腾成本远超那点差价。
阿里云这款活动最大的诚意,是保证来年依然可以 99 元无套路同价续费。
2G 内存虽然紧凑,但只要做好 Swap 兜底,限制好容器内存,并把计算全都甩给外部 API ,机器本地只做存储检索,日常内存占用常态也就几百兆。拿稍微调优一下系统为代价,换一个每年只要 99 块、不用频繁搬家的稳定记忆底盘,这笔账怎么算都更划算。
2. 向量模型( Embedding ):花钱的大头,必须一步到位
整套系统跑起来,持续花钱的大头其实就是向量模型。但我从一开始就放弃了“白嫖免费模型”的想法,坚定选择花钱买商业服务,并且要“一步到位”。
为什么必须一步到位?
VLM 、意图分析、重排模型这些都是即时推理,今天觉得不好用,改一行配置重启一下直接就换了。但向量模型决定了数据库底层的空间几何特征。一旦以后你想换向量模型,哪怕输出维度一模一样,之前的向量也全都废了,必须全库全量重建索引( Re-index )。随着记忆越积越多,二次重构的代价和停机风险极高,所以向量模型选型必须一开始就选最好的。
为什么放弃 SiliconFlow 免费的 BGE-M3 ?
很多教程推荐用硅基流动上免费的 BGE-M3 。我们在实际做向量召回测试时发现,它的召回质量被新一代模型拉开了非常明显的代际差距。BGE-M3 是 2024 年 1 月的模型,底子太老,而且是个纯文本模型,图片只能当附件存,根本建不了索引,做不到“以文搜图”。
更关键的是,公用免费池已经被羊毛党挤烂了。我们在测试免费模型做路由时频繁遇到丢包、高延迟、无响应。作为核心基础设施的底座,把身家性命系在免费公共池上,纯属给自己找麻烦。
为什么选火山方舟的豆包 Vision ( 0.7 元),没选阿里千问?
最终我用的是火山方舟的 doubao-embedding-vision-251215,官方定价是推理输入 0.7 元 / 百万 tokens。
其实阿里百炼也有一款多模态向量模型(qwen3-vl-embedding),价格一模一样也是 0.7 元,但两者有个致命差距:
- 阿里千问的上下文窗口只有 32K;
- 火山豆包的上下文窗口高达 128K。
对于 Agent 场景,经常要塞入长篇开发规范、长上下文代码切片或者多张高清截图,128K 带来了整整 4 倍的安全容限,彻底不用担心超长切片溢出。加上 OpenViking 本身就是字节火山引擎开源的,原生 Provider 兼容最稳,同价位下显然选 128K 的豆包。
注:如果你完全没有图片、截图的检索需求,只做纯文本或代码笔记,阿里百炼的纯文本向量 qwen3.7-text-embedding 是个很好的省钱备选,价格只要 0.5 元/百万 tokens 。
3. 意图分析( Query Planner ):90% 的人都漏看的“隐藏开关”
很多人刚用 OpenViking 时都有个共同的困惑:“为什么这玩意儿响应这么迟钝?每次在 IDE 或终端里刚敲完一句话,光标都要卡顿个五六秒才开始有反应?”不少人甚至因此觉得是机器配置不够,或者系统本身设计笨重。
其实根本不是性能问题,而是绝大多数人压根没仔细看配置文档,不知道还能单独配一个意图分析模型。
官方默认示例里大家一般只填 vlm 和 embedding。但只要没在配置里显式声明 query_planner,OpenViking 在处理每一轮对话时,就会默认回退去调用主模型 VLM 来分析这轮对话是不是闲聊、要不要搜记忆、怎么提取关键词。如果你的 VLM 选了个大模型或者带思考链的模型(比如智谱 glm-5.3-flash),单次前置分析直接就能吃掉 6~7 秒,前端交互自然卡成 PPT 。
为了解决这个前置卡顿,起初我试图在主流的通用大模型里寻找替代方案。但跑了一圈下来非常沮丧:
- 阿里百炼官方的 Qwen3.7-Flash 默认带深度思考,跑一次要想 10 秒;
- 硅基流动上的 Qwen/Qwen3.5-9B 吞吐偏慢(常态 30 tok/s ),每次提问依然要停顿 4 秒;
- 硅基流动上的 Qwen/Qwen2.5-7B 格式飘忽,爱吐裸数组;
- 硅基流动公用免费池的模型(如 Qwen3.5-4B)更是被羊毛脚本挤爆,频繁丢包超时。
正当我们卡在通用大模型的选型瓶颈时,**我在阿里百炼模型广场里无意间翻出了一个宝藏模型——tongyi-xiaomi-analysis-flash(伶鹊-对话分析-flash )**。官方介绍写得很朴实:专攻对话信息抽取、场景分类与低时延分析的领域模型。
我立刻把它拉进测试矩阵,和前面的候选模型来了一场同台竞技。需要特别说明的是,为了公平对比,我们在压测所有候选模型时,全都显式关闭了思考模式(开启非思维链模式,纯直接输出)。
在实际评估中,我们重点死磕了三个核心维度:响应耗时、生成结构、规划表现。在三项严苛检验下,这个意外淘到的宝藏模型给出了教科书级的表现:
维度一:响应耗时(时间预算必须死守在 1 秒内)
query_planner 处于用户敲下回车、模型真正回答前的关键阻塞路径( Critical Path )上,耗时哪怕多 1 秒,体感都是极其明显的卡顿。
- 阿里百炼 Qwen3.7-Flash:即使关掉思考模式(
enable_thinking: false),单次分析依然要 1.1~1.4 秒( 70~90 tok/s ),作为高频前置拦截还是略重; - 硅基流动 Qwen/Qwen3.5-9B:关掉思考后,受限于供应商 30 tok/s 的生成吞吐瓶颈,跑完一段多轮分析依然需要 3.8 ~ 4.2 秒;
- 硅基流动免费池(如 Qwen3.5-4B ):公用免费池常年被羊毛脚本挤占,延迟严重抖动甚至直接超时;
- 通义伶鹊( Flash ):首字延迟( TTFT )仅 0.31 秒,生成吞吐高达 200+ tok/s,整轮规划耗时直接干到了 0.8 秒左右,完美落在亚秒级预算内。
维度二:生成结构(严苛遵循 OpenViking 要求的 JSON 协议)
OpenViking 底层的意图解析器对输出格式有明确的契约要求:模型必须返回形如 {"queries": [...]} 的标准 JSON 对象结构(由内部代码直接反序列化提取检索意图),容不得半点格式偏差:
- 通用大模型的通病:喜欢画蛇添足加礼貌用语(“好的,为您规划如下”),或者在外面套一层
json ...围栏,把本该干净的输出搞得拖泥带水,全靠系统写正则兜底去清洗; - 硅基流动 Qwen/Qwen2.5-7B 的硬伤:虽然速度压缩到了 1.8 秒,但格式极其不服从规范,经常丢掉 OpenViking 要求的顶层 Key ,直接吐出一个裸数组
[...]。一旦丢了对象结构,极易触发解析异常导致检索失败; - 通义伶鹊( Flash ):官方特性主打“自定义分析标准遵循”,实测下来对 OpenViking 要求的 JSON 协议做到了 100% 严格执行——输出纯净裸 JSON ,没有 markdown 围栏,没有前后废话,与 OpenViking 的反序列化契约严丝合缝。
维度三:规划表现评估(业务意图的决断质量)
意图分析模型绝不是盲目生成检索词,它必须具备清晰的业务场景决断力:
- 闲聊拒搜率:面对“你好”、“谢谢”、“帮我写个冒泡排序”这种无需长程记忆介入的输入,通义伶鹊能像防火墙一样在 0.4 秒 内果断断定无需检索,并输出空数组
{"queries": []},避免了无意义的向量库查询与上下文污染; - 多轮指代消解与实体抽取:在多轮对话中(比如用户追问“把刚才说的那个服务端口发我”),它能从历史上下文里把代词精准还原成具体的实体词(展开为“OpenViking 1933 端口配置”),提取出来的 Query 极其精准紧凑,绝不发散脑补。
事实证明,这个无意间淘到的宝藏模型绝非侥幸胜出,而是其专攻“对话抽取、场景分类、格式遵循”的垂直微调定位,正好与 OpenViking 前置路由的工程诉求完成了教科书般的精准对齐。
4. 重排序( Rerank )与 VLM:务实的经济账与容灾
最后说说剩下的两个组件:
- 重排序( Rerank ):我依然放在了硅基流动上,用的是
Qwen/Qwen3-Reranker-4B。 之所以用它,是因为它走的是轻量商业计费通道(避开了免费池的排队),调用一次只要几厘钱。关键是我账号里还有送的 16 块钱代金券,不用白不用。实测 4 条文档打分 0.26 秒,30 条文档打分 0.57 秒,速度快而且打分很准,性价比拉满。 - VLM (多模态语义抽取):用的是智谱 Coding 套餐里的
glm-5.3-flash,顺便配了双 Key 主备容灾。 这里有个极其关键的实战经验:配置里一定要把思考模式显式改为reasoning_effort: "low"。 我们专门做过多组 A/B 实测,默认不传参或者设为high时,模型会先深度思考大几十秒(耗时 20~48 秒,生成上千个无意义的思维链 Token ),而最终提取出来的实体和概览内容与low几乎毫无区别。记忆提取本质上是信息抽取和结构化归档,根本用不着复杂的数学逻辑推演,开high纯属白白浪费时间和算力。 即使设为low,单次抽取依然需要 4~6 秒(有底层基础思考和 20~30 tok/s 的吞吐上限),它也是目前系统唯一的耗时点。但因为 VLM 只在后台异步做会话归档和概览生成,完全不阻塞前端的提问交互;加上 Coding 套餐按年付费极度便宜,配合双 Key 容灾非常稳定,现阶段完全不需要花钱折腾换它。
5. 写在最后的一些大白话心得
折腾完这套配置,最大的几点感悟:
- 状态型服务,买服务器先看续费:做长期记忆库,宁可前期在 2G 上花点时间调优,也别为了贪图首年几块钱的便宜去买续费暴涨的机器,搬家真的很累。
- 核心资产一步到位,无状态节点随时优化:向量模型决定了你的底层空间,别贪免费,多模态 + 大上下文( 128K )直接锁死,避免以后二次重建;而 VLM 和 Rerank 这种纯推理节点,谁快谁便宜就换谁。
- 专用小模型在垂直场景吊打通用大模型:意图分析这种讲究“分类、提取、严格 JSON 格式、极速”的任务,微调过的对话分析小模型比动不动就写小作文、开思考链的通用大模型好用太多倍。
易鸿智能冲刺港股IPO:宁德时代撑起七成收入,存货却超全年营收
(本文作者为 创业最前线,钛媒体经授权发布)
文 | 创业最前线,作者 | 希波,编辑 | 冯羽
在锂电池生产线上,有一类设备并不直接制造电池,却决定着电池生产过程中的“良品率”。
比如,一卷锂电池极片生产出来后,设备需要判断它的厚度是否达标、表面有没有缺陷;电芯装配过程中,也需要持续检查尺寸、位置以及其他关键指标。一旦发现异常,系统需要及时识别,并进一步控制生产设备进行调整。
广州市易鸿智能装备股份有限公司(以下简称“易鸿智能”)做的,正是这类业务。
近期,易鸿智能在港交所递交了招股说明书,申报在港交所上市。值得注意的是,宁德时代贡献了公司超七成收入,且公司机器视觉业务毛利率大幅下滑,存货规模也持续攀升。此外,公司在IPO前夕因未能按约定期限提交合资格上市申请,向多名投资者转让股份作为补偿。
从机器视觉到智能装备,易鸿智能能否摆脱对头部客户的高度依赖,将营收增长转化为更稳定的盈利与现金回流,仍有待检验。
1、押注智能装备,IPO前夕股权补偿协议触发
易鸿智能的起点,可以追溯到2014年。
2014年4月11日,公司前身广州市易鸿机械制造有限公司成立,初始注册资本为200万元。其中,王刚出资80万元,张权和许卓夫分别出资60万元。
创业早期,易鸿智能主要围绕机器视觉检测能力展开布局。
对于锂电池生产而言,极片、焊接部位、电芯等环节都涉及大量高速、精密的检测需求,而机器视觉就是给工业生产线装上一双“眼睛”,通过摄像机、光学系统、传感器以及算法,对生产过程中的材料和产品进行拍摄、识别和判断,从而发现缺陷、测量尺寸或判断位置是否准确。
因此,机器视觉能够进入锂电池生产流程,帮助电池企业减少人工检测,提高生产效率和良率。
随着新能源汽车和动力电池产业快速发展,易鸿智能逐渐把机器视觉能力集中到锂电池生产场景,并持续向更复杂的检测设备和智能制造解决方案延伸。
2015年至2018年,易鸿智能进入宁德时代供应链,且完成数千万元A轮融资,由源渡创投领投,融资资金主要用于核心技术研发和业务拓展。
近年来,公司开始把视觉检测能力进一步嵌入生产设备中,从发现问题的“眼睛”转向发现问题后直接控制生产设备的方向进行延伸。
目前,易鸿智能的智能装备主要包括辊压分切一体机、激光模切卷绕一体机等。
其中,辊压分切一体机可以理解为先把电池电极材料压实、压薄,再将宽幅材料切成符合生产要求的窄条;激光模切卷绕一体机则负责把电极材料精准切割成特定形状和尺寸,并进一步将正极、负极及隔膜等材料卷绕成电芯。
此外,易鸿智能在2025年还完成了第一条全极耳圆柱电芯高速自动装配线的销售和交付,进一步从单一检测设备向更复杂的电池制造装备延伸。
按2025年收入计,易鸿智能在国内锂电池机器视觉检测解决方案中排名第二、在全球大宽幅辊压分切一体机市场中排名第一。
易鸿智能成立后,曾经历多轮融资和股权转让。2026年2月股权转让完成后,公司的投后估值达到13.43亿元。

值得一提的是,公司部分历史投资协议中存在与投资人权益保护及退出安排相关的特殊机制。不过,易鸿智能在本次港股IPO递表前,已经进行了一轮较为集中的股份补偿。
2026年5月10日,包括百咖地坤、北京新动力、源慧睿泽创业投资、福州晨粒、南京经纬壹号、三亚榕泉、海南源渡三期、天津源渡、温州捷琰、无锡砺行、珠海隐山等在内的多家投资者,以零代价获得了来自王刚、张权以及其他相关股东的共计121.78万股补偿股份。
这意味着,对于易鸿智能而言,过去融资过程中与投资人之间的特殊权益安排,并不是简单停留在“纸面上”,而是切实补偿了股份。
2、宁德时代贡献超七成收入,客户集中风险突出
中国是全球最大的锂电池智能装备市场,市场规模预计由2025年的340亿元增长至2030年的800亿元。此外,2025年我国按出货量计算的前三大锂电池厂商产能利用率近90%,其中最大的锂电池厂商呈现产能供不应求的态势。
依托锂电池产业链发展机遇,锂电池配套厂商易鸿智能近年业绩逐年增长。
招股书显示,2023年至2025年(以下简称“报告期”),易鸿智能的收入分别为2.94亿元、3.94亿元和5.52亿元;年内利润分别为70.9万元、5127.5万元和6966.6万元。
2025年,全球锂电池辊压分切一体机市场规模总计13.2亿元。据招股书披露,易鸿智能在全球前五大锂电池辊压分切一体机制造商中位列第三,市占率为21.1%。
在锂电大宽幅辊压分切一体机市场中,全球前三厂商合计占据95.1%份额。2025年,易鸿智能在该项业务中按收入计位居全球第一,市占率为42.1%。
易鸿智能能够快速推动智能装备收入增长的重要原因之一,就是绑定了宁德时代等大客户。
招股书显示,报告期内,公司来自前五大客户的收入占公司总收入的比例分别为98.7%、97.2%和94.4%。其中,来自最大客户也就是宁德时代的收入分别为2.53亿元、2.64亿元和4.19亿元,占各期总收入的比例约为86.0%、67.1%和75.8%。
可见,易鸿智能的客户结构相当集中。
依赖单一大客户有其优势。一般来说,像宁德时代这样的大客户订单规模大、项目周期长,一旦设备进入其供应链体系,易鸿智能有机会伴随客户扩产持续获得订单。
然而,在大型电池厂面前,设备供应商往往拥有相对有限的议价能力。
招股书显示,报告期内,易鸿智能的毛利率分别为19.6%、30.9%和26.2%。2024年公司的毛利率大幅增长,但是2025年却再度下滑4.7个百分点。值得一提的是,易鸿智能机器视觉业务毛利率从2024年的40.8%跌至2025年的14.4%。
毛利率起伏背后,易鸿智能的盈利稳定性仍经受考验。易鸿智能也在招股书中坦言,公司核心客户多为头部电池与新能源企业,这类客户在合作中具备较强的议价权。
因此,如果想扩大头部客户订单,就可能需要接受大客户较强的议价权;如果想维持较高毛利,则需要不断推出具有技术差异化的设备,这也对易鸿智能的研发能力提出了更高要求。
截至2025年末,易鸿智能研发团队有191人,占员工总人数的25.9%,涵盖机器视觉、人工智能、精密机械、自动控制和工艺工程等专业方向。
报告期内,易鸿智能的研发开支分别为3760万元、4150万元和4940万元,占当年收入的比例分别为12.8%、10.5%和8.9%。
这意味着,随着公司收入规模扩大,研发投入并没有保持同样的增长速度。对于一家强调AI算法、机器视觉和智能装备的企业而言,研发费用率的下滑尤其值得关注。
一旦产品进入成熟期,设备之间的差异化下降,价格之间的“内卷”式竞争就有可能重新出现。
3、应收账款、存货“双高”,资金回收压力加剧
对智能装备企业而言,拿到订单只是生意的开始。从采购原材料、组织生产,到设备交付、客户验收,再到货款回收,每个环节都需要资金支撑。
近年来,易鸿智能收入规模持续扩大,但存货与应收款项同步增长,也让这家企业的资金周转效率备受关注。
招股书显示,报告期各期末,公司的存货金额分别为5.16亿元、5.13亿元和6.78亿元,2025年末,公司存货规模较上年末增长约32.3%,相当于当年5.52亿元营业收入的约1.23倍。
也就是说,公司账面存货已经超过全年收入,资金占用规模不小。此外,2026年一季度末,存货金额更是增长至8.82亿元。
存货周转效率同样值得关注。报告期内,易鸿智能的存货周转天数分别为788天、690天和534天。报告期内存货周转天数逐年下降,说明公司存货周转有所改善,但截至2025年,周转天数仍超过500天。
对此,易鸿智能在招股书中解释道,公司销售锂电池智能装备及机器视觉系统,通常需要在取得客户出具的验收证明后确认收入,因此导致公司存货金额的水平较高。
这意味着,设备完成生产甚至已经交付,并不代表易鸿智能可以立即确认收入。这与易鸿智能近年来的业务结构变化有关。
2023年,公司智能装备业务收入占比为32.7%;到2025年,这一比例已升至83.6%,成为公司最主要的收入来源。随着业务重心从机器视觉检测解决方案转向辊压分切一体机、激光模切卷绕一体机等智能装备,项目生产、交付和验收环节对资金周转的影响也更加突出。
不仅如此,易鸿智能的应收款项进一步体现了公司的回款压力。
报告期各期末,易鸿智能的贸易应收款项及应收票据分别约为6923.7万元、9025.8万元和1.94亿元。截至2025年末,公司应收账款规模较上年末增长超过一倍,应收款项的增长速度明显快于收入增长速度。
不仅如此,报告期内,公司贸易应收款项及应收票据的周转天数分别为126天、78天和97天。易鸿智能在招股书中表示,公司来自行业顶尖电池客户的订单占比提高,该客户通常依赖银行承兑票据或商业承兑票据,导致收款周期延长。
截至2026年3月31日,公司2025年12月31日的未偿清贸易应收款项中,仅有32.6%已被结清。
当存货规模扩大、应收款项增长,而部分应收款项又暂时无法收回时,易鸿智能就需要持续投入营运资金来支撑业务运转。
不过,易鸿智能的经营现金流并非持续恶化。招股书显示,报告期各期,公司的经营活动所得现金流量净额分别为-1.37亿元、5895.3万元和2.01亿元。可见易鸿智能近两年的经营现金流已经有所改善。
截至2025年末,易鸿智能拥有现金及现金等价物2.62亿元,计息银行及其他借款则为1.21亿元,公司现有资金储备足以覆盖全部计息债务。
不过,随着机器视觉业务毛利率下滑、智能装备成为新的增长支柱,易鸿智能还需要证明,新增订单能够在合理周期内完成交付与验收,并最终转化为现金回流。
招股书显示,随着锂电池制造从规模扩张向精益化升级转变,易鸿智能计划继续围绕核心工艺控制能力进行布局,研发重点包括固态电池设备及干法电池相关技术。
此前,公司已交付首条纯锂新能源聚合物固态电池中试生产线全工序整包工程,并开始将客户范围拓展至欧洲、北美电动汽车整车厂以及韩国锂电池制造商。
然而,新产品研发、产能扩张和市场拓展都需要资金与时间投入,而易鸿智能现有业务仍面临机器视觉业务盈利能力下滑、存货规模较大以及回款周期拉长等现实考验。其港交所IPO能否顺利落地,「创业最前线」也将持续关注。
更多精彩内容,关注钛媒体微信号(ID:taimeiti),或者下载钛媒体App
Mapping the Emerging Social Science of Large Language Models
The Direction of Ignorance: LLMs Encode and Temper a Unigram Prior
KumbhDoot: A Scale-Ready, LLM-Bounded Architecture for Mass-Gathering Public-Service Assistants
Conditional Memory Enhanced Item Representation for Generative Recommendation
SemantiScene-Edit: Expert-Synthesized Supervision and Dual-Path Source Conditioning for Instruction-Based Video Editing
How to Loop Your Transformer: Loop Scaling, Specialization, and Parallel Inference
Latent Prediction Yields Cross-Subject Alignable Representations in Sensory-Evoked fMRI
TaskFrame: Connecting Task-Level Planning with Frame-Level Control for Game Agents
EventSeeColor: Learning to Reconstruct Color from Monochrome Events
Event-SAMA: Language-Grounded Video Object Segmentation on Neuromorphic Event Streams
FDSML: Formula-Driven Supervised Metric Learning with Parameter-Aware Triplet Loss
Where Position Matters: Profiling-Guided Layer-Wise RoPE Allocation in Transformers
PRISM: Personalized Item Representations in User History
From Local Recovery to Unified Generation: Discovering Triple Set in Knowledge Graphs via Observation-Anchored Latent Diffusion
Learning Scientific Trajectories to Predict Future Biomedical Discoveries
Geometry Matters in Packed 3D Attention