AI项目落地的困难点在哪？

一、问题的表象：一个”智能问答”引发的六个月返工

我们做电力行业的AI落地项目。第一个项目，甲方的需求描述只有四个字：”智能问答系统”。

听起来很明确。实际上，”智能问答”这四个字可以指代十种以上完全不同的系统形态：

• FAQ匹配机器人：问一句答一句，从预设问答对中检索。半天可上线。
• 知识库检索问答：将文档灌入检索系统，用户提问后从文档中定位答案。
• 多轮对话系统：支持上下文理解、意图澄清、槽位填充的对话引擎。
• 结构化数据查询：对接业务数据库，将自然语言转为查询语句。
• 语音交互系统：语音输入、语音输出的完整交互链路。

甲方说不是第一种，要”能理解我们业务的”。最终确定走知识库检索方向。从需求确认到上线，中间隔了六个月。不是技术难，是需求改了三次。

二、第一道坎：非结构化数据的”脏活”

2.1 文档解析的真实复杂度

甲方最初说”所有文档都放进去”。我们收集后发现文档类型包括：

文档类型	格式	可解析性
调度规程	PDF（文字层）	可直接提取
继电保护手册	Word	可直接提取
配网运维规范	扫描件PDF	需OCR，无文字层
设备说明书	混合格式	部分需OCR
检修报告	Excel	需结构化解析

光是把这些文档解析成可用文本，花了三周。甲方不理解：”不就是上传文件吗？”

2.2 工程启示

这里涉及的是典型的非结构化数据治理问题。业界常见的技术方案包括：

# 文档解析的典型处理链路（示意）
def parse_document(file_path):
    # 1. 格式识别
    fmt = detect_format(file_path)
    # 2. 分流处理
    if fmt == "pdf_with_text":
        text = extract_pdf_text(file_path)
    elif fmt == "scanned_pdf":
        text = ocr_pdf(file_path)  # 需要OCR引擎
    elif fmt == "docx":
        text = extract_docx(file_path)
    elif fmt == "xlsx":
        text = extract_excel_structured(file_path)
    # 3. 后处理：分句、去噪、元数据标注
    chunks = chunk_and_annotate(text)
    return chunks

关键教训：需求确认的第一件事不是讨论功能，而是让甲方把所有文档发过来看一遍。看完再说能做什么、不能做什么、需要多长时间。

三、第二道坎：使用场景的隐性约束

3.1 语音需求的突然出现

知识库搭好进入测试阶段，甲方突然提出：”我们还要语音问答。要在值班室装设备，值班员用语音提问，系统语音回答。”

需求本身不难——加语音识别加语音合成即可。但问题在于使用环境：

• 变电站值班室
• 设备运行噪声持续存在
• 空调噪声
• 偶发报警声

语音识别在这种环境下的准确率惨不忍睹。试了三个月，甲方说算了，先用文字。

3.2 场景确认的框架

这个教训指向一个核心问题：需求确认时要问清楚使用场景，而不是”你要什么功能”。

正确的问法应该是：

谁（角色）在什么环境下（噪声/光照/网络条件）用什么设备（PC/移动端/专用终端）怎么用（单手/语音/键盘）达到什么目的（查询/记录/审批）？

差一个环节，整个技术方案都可能推翻。

四、第三道坎：验收标准的模糊性

4.1 “能用”和”好用”之间的距离

知识库检索系统上线后，甲方试用反馈：”搜出来的东西不对。”

追问具体哪里不对：

• 是检索不到相关文档？→ 召回率问题
• 是检索到了但排序靠后？→ 排序算法问题
• 是答案片段不完整？→ 切分粒度问题
• 是答案正确但表述不清晰？→ 生成或摘要问题

甲方说不清楚。因为在甲方眼里，”搜不到”和”搜出来不对”是同一件事。但对应到技术侧，是完全不同的优化方向。

4.2 建立可量化的验收指标

在项目初期就应该和甲方共同定义：

指标类别	具体指标	目标值（示例）
检索召回	Top-5召回率	≥85%
检索精度	Top-1准确率	≥70%
响应时间	端到端延迟	≤3秒
覆盖范围	可检索文档占比	≥90%
用户满意度	抽样评分	≥4/5

没有量化标准，”优化”就是无底洞。

五、第四道坎：为什么企业AI项目容易做成聊天机器人

5.1 路径依赖

聊天机器人是AI能力最直观的展示形态。大语言模型出来后，对话交互成了默认范式。但企业场景中，很多需求本质上不是”对话”能解决的：

• 报表生成 → 需要结构化数据查询和模板渲染
• 工单分类 → 需要文本分类模型
• 设备缺陷识别 → 需要图像识别
• 检修计划排程 → 需要优化算法

把这些问题都包装成”聊天”，反而增加了不必要的复杂度。

5.2 技术选型的惰性

聊天机器人技术栈成熟、开源方案多、演示效果好。团队容易倾向选择熟悉的技术路径，而非最适配业务的技术路径。

正确的做法：从业务问题出发，选择最简技术方案。能用规则引擎解决的不上模型，能用传统机器学习解决的不上大语言模型。

六、第五道坎：组织内部的共识缺失

6.1 甲方内部意见不统一

项目推进中经常出现：业务部门说要A，IT部门说要B，领导说要C。技术团队夹在中间，按谁说的做都可能被推翻。

6.2 应对策略

• 找到真正的决策人：不是对接人，是能拍板的人
• 需求确认会要有纪要：口头确认不算，邮件或文档确认才算
• 变更要走流程：需求变更可以，但要有记录、有评估、有确认
• 分阶段交付：每个阶段有明确的交付物和验收标准，避免到最后一起算总账

七、总结：AI项目落地的检查清单

阶段	关键动作	常见陷阱
需求确认	收集全部原始文档；确认使用场景；定义量化验收指标	只听功能描述，不看数据，不问环境
方案设计	选择最简技术路径；预留数据治理时间	过度设计；低估数据清洗成本
开发实施	分阶段交付；每阶段确认	一次性交付，最后被全盘否定
测试验收	按量化指标验收；记录变更	主观评价”好用/不好用”
上线运维	持续监控；建立反馈闭环	上线即结束，无迭代机制

AI项目落地的困难，技术只占一部分。更多时候，困难在于：需求的不确定性、数据的不规范性、场景的复杂性、以及组织内部的共识缺失。

技术团队能做的是：把不确定性变成确定性——用文档确认需求，用数据评估可行性，用场景约束方案，用指标衡量效果。

这不是技术问题，是工程管理问题。但恰恰是这些”非技术”因素，决定了AI项目能不能真正落地。