从一次真实项目出发，聊聊技术探索与实践的重要性

作为一名AIGC工程师，我在过去的五年里参与了不少AI驱动的业务创新项目。但今天我想分享的，并不是某个高大上的技术模型或者算法论文，而是一次在实际项目中遇到的具体问题和整个过程中的思考。

这个故事发生在我们公司一个面向教育行业的智能问答系统落地时，项目本身目标很明确：通过AI能力提升学生和教师之间的互动效率。但在实施过程中，我们却踩了不少坑，也经历了一些意料之外的挑战。最终，这些问题的解决不仅让我们成功上线了项目，还让我对技术探索与实践有了更深刻的理解。

---

背景介绍：一次典型的多模态AI落地任务

2023年，我们接到一个教育客户的需求：希望构建一个基于AI的智能问答平台，学生可以上传作业题目（包括文本、图片甚至是公式手写识别），系统能自动理解问题并给出解答建议，同时支持教师进行个性化调整和反馈。

这个项目的“理想蓝图”听起来并不复杂：OCR + NLP处理题干内容，结合大模型生成答案，再配合前端展示即可完成闭环。然而，当我们真正开始开发后才发现，理想和现实之间隔着一座“技术鸿沟”。

---

遇到的问题：技术选型、数据质量、性能瓶颈接踵而来

1. 技术选型的纠结

在项目初期，我们的技术方案是这样的：

• 图像识别使用 Google Vision API
• 文本理解和生成采用 ChatGPT 接口
• 后端服务框架是 Python Flask

听起来挺合理吧？但我们忽略了两个关键问题：

1. Google Vision API 在中文数学公式的识别上误差率非常高；
2. ChatGPT 的调用成本太高，且不支持中文定制化训练；
3. 整个链路响应时间超过 5s，远高于客户预期的 1.5s 响应要求。

更严重的是，由于涉及图像 + 文本的混合输入，传统的 RAG 检索增强方案也无法直接套用。我们需要重新设计推理流程。

2. 数据质量问题暴露

在开发初期，我们依赖的是公开的教育类数据集，比如 OpenBookQA 和 Math23k，但这些数据跟用户真实场景差距很大：

• 公式表达方式不统一；
• 学生上传的手写作业模糊不清；
• 题目中经常夹杂非标准格式（如表格、草稿等）；

这导致 OCR 出来的结果准确率不到60%，根本达不到可用级别。

3. 性能和并发瓶颈

随着功能开发进入中后期，我们在内部测试中发现，单台服务器在并发请求达到 20qps 以上就会出现卡顿，严重影响用户体验。尤其是在图像处理环节，GPU 利用率一度飙升至98%以上。

---

解决思路：边跑边修，在实践中不断迭代优化

面对这些挑战，我们决定不急于盲目重构架构，而是采取一种“最小验证单元”的开发策略——每次只改一个模块，评估影响，再继续前进。

第一步：更换核心 OCR 工具

我们将 OCR 引擎从 Google Vision 切换到了 PaddleOCR，这是百度开源的一套 OCR 系统，尤其擅长中英文混排文档识别。虽然部署需要自己搭建服务，但它支持微调训练，这对于后续优化手写题目的识别非常有帮助。

我们针对一批学生手写体的数据进行了 fine-tune 训练，识别准确率从原先的 57% 提升到了 86%。

代码片段如下：

from ppocr.utils.logging import get_logger
from ppocr.utils.utility import check_and_read, get_image_file_list
from ppocr.predict_system import TextSystem

logger = get_logger()
text_sys = TextSystem(det_model_dir='det_model/',
                      rec_model_dir='rec_model/',
                      use_angle_cls=False)

img_path = 'test_images/handwritten_math_1.jpg'
im = cv2.imread(img_path)
dt_boxes, rec_res = text_sys(im)

for idx, (text, score) in enumerate(rec_res):
    print(f"{idx} | {text} | {score}")

通过这种方式，我们逐步提升了 OCR 模块的质量。

第二步：引入本地大模型，降低调用延迟

为了减少对 ChatGPT 的依赖，我们评估了几种本地化的大语言模型：

• ChatGLM（智谱 AI）
• Qwen（阿里通义千问）
• LLaMA + Chinese-LLaMA-Alpaca

最后选择了 Qwen，主要原因是：

• 支持中文训练语料丰富；
• 社区活跃，官方提供了完整的微调和部署工具包；
• 推理速度更快，在本地部署下可做到平均 0.8s 返回结果。

我们在项目中使用了 Qwen 的 Int4 量化版本，部署在 GPU T4 上，推理服务由 FastAPI 封装提供接口：

from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

model_name = "Qwen/Qwen-7B-Int4"
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto", trust_remote_code=True).eval()

def generate_answer(question: str):
    inputs = tokenizer(question, return_tensors="pt").to(model.device)
    with torch.no_grad():
        outputs = model.generate(**inputs, max_new_tokens=200)
    answer = tokenizer.decode(outputs[0][inputs['input_ids'].shape[1]:], skip_special_tokens=True)
    return answer

第三步：异步流式处理优化性能瓶颈

为了解决并发卡顿的问题，我们做了一件比较大胆的事：将原本同步调用的 OCR + NLP + LLM 流程拆成异步管道模式。

具体来说，我们使用 Celery + Redis Broker 将各个阶段解耦：

1. 用户上传图片 → 写入 Redis Queue；
2. OCR worker 处理图像，输出文本 → 发送中间消息；
3. NLP worker 接收文本，做意图识别；
4. LLM worker 生成回答；
5. 最终整合回传给前端。

这样改造之后，服务负载明显下降，同时也能应对短时间流量峰值冲击。

此外，我们还做了资源隔离和优先级队列管理，确保教师用户的查询优先于普通学生。

---

踩过的坑 & 我们的填坑方式

坑1：OCR 模块微调失败多次

一开始我们尝试使用默认参数进行 fine-tune，但效果一直不理想。后来查日志发现是因为训练数据存在偏移，某些字符标注错误较多。

解决方法：

• 引入半监督学习方式，先使用已有模型预测未标注数据；
• 结合人工审核 + 自动生成伪标签；
• 使用 EasyOCR 辅助纠错训练样本；
• 迭代训练多次后终于达到了满意的结果。

坑2：LLM 回答跑题 / 不准

有时候 Qwen 给出的答案逻辑正确，但步骤混乱或格式不规范，尤其在涉及公式推导时容易出错。

解决方法：

• 增加 prompt 工程，引导模型按照“已知、求解、步骤、结论”格式回答；
• 引入外部知识库（比如《中学数学教材》PDF 提取的知识点图谱）作为检索依据；
• 人工设定 fallback 机制：当模型置信度低于阈值时，触发人机协同机制。

坑3：生产环境下的 GPU 显存爆掉

有一次我们在线上突然收到告警：GPU OOM。排查发现是因为并发请求太多，每个请求都加载模型实例，导致内存炸掉。

解决方案：

• 使用 Model Parallelization 把不同模块分开放在不同设备上；
• 对模型进行量化和剪枝；
• 使用 HuggingFace 的 transformers.pipeline 缓存机制，避免重复加载。

---

成果与收益：不只是技术突破，还有团队成长

最终，我们按时交付了系统，并且获得了客户的认可：

• 平均响应时间控制在 1.2s 内；
• 手写题识别准确率提高 20%+；
• 多轮对话体验显著提升，教师反馈良好；
• 系统支持 100qps 的稳定并发访问。

更重要的是，整个团队在这个项目中完成了从“功能实现”到“深度优化”的蜕变。我们开始更加注重系统的可扩展性和稳定性，而不是单纯追求模型效果。

---

经验总结：技术探索要贴近实战，才能走得更远

回顾整个项目，我觉得有几个经验值得分享给正在一线奋斗的开发者们：

✅ 一切以需求为中心，别让“炫技”主导方向

我见过太多项目一开始就堆各种最新模型，结果连基础流程都跑不通。技术选型要基于业务场景，而不是谁火就用谁。

✅ 小步快跑，快速验证才是王道

不要一开始就试图搞出一个“完美系统”。先做出 MVP，然后不断迭代修复。这样才能保证节奏可控，风险可控。

✅ 日志和监控必须尽早接入

这次项目中，我们是在第三次版本才加入 Prometheus + Grafana 监控，早该这么做的。没有可观测性，你永远不知道性能瓶颈在哪里。

✅ 模型只是冰山一角，工程能力才是硬实力

真正的 AI 工程师不仅是懂模型的人，更是能把模型、服务、数据串联起来、稳定运转的人。这背后有大量的工程细节。

---

写在最后：技术探索的本质，是为了更好地落地

这篇文章讲的是我亲身经历过的一个项目案例，没有夸张，也没有包装。我相信很多同行都经历过类似的场景：一边调试模型一边修 bug，甚至还要亲自跑数据打标签。但我们正是在这种不断的试错与优化中，逐渐成长为真正的 AIGC 工程师。

如果你也在经历类似的事情，请相信：每一块绊脚石，都是通往更高台阶的铺垫。

共勉。