小厂后端的AI自救之路：从面试题到真实项目落地

上周五晚上十一点，我还在公司改一个线上紧急Bug，突然收到猎头消息：“最近在看机会吗？我们这边有个大模型平台的后端岗，薪资开得不错。”
我苦笑了一下，心想：要不是最近被AI面试题虐得怀疑人生，谁愿意大半夜还在这儿调接口限流策略？

我是深圳一家百人规模小厂的后端开发，独立负责一条电商促销业务线。说“独立负责”，其实也就意味着——从前端联调到数据库慢查询，从K8s部署到凌晨三点的报警电话，基本都得我顶上。团队里没有专职架构师，没有算法组，连运维都只有一位兼职的兄弟。但好处是，技术栈自由度高，老板虽然抠门，但对新技术还算开明，只要能带来业务价值，他一般不会拦。

去年开始，我发现面试市场变了味。以前问你“Redis缓存穿透怎么解决”，现在直接甩一句：“用LangChain搭个RAG系统，支持多轮对话和知识库检索，你怎么设计？”
我？？？
我连LangChain是啥都没听过！更别提什么向量数据库、Embedding模型、语义相似度了。

为了不被时代淘汰，也为了下一次跳槽时不至于在面试官面前像个石器时代的程序员，我决定——把AI技术真正用到自己的项目里，哪怕只是个小功能。纸上谈兵不如动手干，这是我一贯的信条。

---

项目背景：促销活动配置太复杂，运营天天找我

我们的业务线主打限时秒杀、满减、阶梯优惠等组合促销。每次大促前，运营小姐姐都要在后台配置几十种规则，而这些规则本质上是一堆if-else逻辑。比如：

“用户A在广东，注册超过30天，购物车有商品B且价格>100，同时没领过券，就发一张5元无门槛券。”

这种规则写死在代码里，每次改都要我手动改Java逻辑，重新打包上线。运营急得直跺脚，测试测到崩溃，产品经理甚至画了个“规则引擎”原型图，美其名曰“低代码化”，结果一看，根本就是个Excel表格转JSON的玩具。

我一度想引入Drools，但评估下来发现学习成本高、调试困难，而且小厂没人维护，万一出问题半夜还得我背锅。于是，我萌生了一个大胆的想法：能不能用自然语言让运营直接描述需求，系统自动解析成可执行的规则？

这不就是LLM（大语言模型）的典型应用场景吗？

---

技术选型：资源有限，必须精打细算

作为一个小厂开发者，我深知“资源”二字有多重。我们没有GPU服务器，没有专属的AI团队，连云服务预算都是按月抠着花的。所以，方案必须满足几个硬性条件：

1. 成本可控：不能动不动就调用GPT-4，每千次请求几十块，老板会把我当韭菜割。
2. 部署简单：最好能跑在现有K8s集群上，别整那些复杂的MLOps流水线。
3. 响应快：促销配置是实时操作，不能等十几秒才返回结果。
4. 可解释性强：运营输错一句话，系统得告诉我哪里理解错了，而不是默默返回一个错误的JSON。

经过一番调研（其实就是周末刷了三天GitHub和Hugging Face），我最终选择了以下组合：

• 本地嵌入模型：text2vec-base-chinese（开源，中文效果不错，768维向量，CPU推理够用）
• 向量数据库：ChromaDB（轻量，纯Python，单文件存储，适合小数据量）
• LLM推理：Qwen-1.8B-Chat 的GGUF量化版本（4-bit，可在消费级CPU上运行，响应速度约2-3秒）
• 框架：LangChain（虽然有点重，但生态成熟，文档全）

为什么不用OpenAI？因为贵，而且网络不稳定。为什么不用Llama.cpp？试了，中文支持不如通义千问。为什么不用Milvus？太重了，ChromaDB一个pip install搞定，对我这种一人团队太友好了。

---

实战过程：从“Hello World”到线上跑通

第一步：构建规则模板库

我把历史上所有促销规则拆解成结构化模板，比如：

{
  "template_id": "coupon_for_new_user",
  "description": "给新用户发无门槛券",
  "condition": {
    "user_region": "any",
    "user_register_days": "<=7",
    "has_coupon": false
  },
  "action": {
    "issue_coupon": "5_yuan_no_threshold"
  }
}

总共整理了23个高频模板，存入ChromaDB。每个模板的description字段会被text2vec编码成向量，用于后续语义匹配。

第二步：搭建RAG流程

用户输入自然语言，比如：“给深圳的新用户发一张5元券”。

LangChain的流程如下：

1. 用text2vec将用户输入转为向量
2. 在ChromaDB中检索最相似的3个模板
3. 将用户输入 + 模板上下文拼成Prompt，喂给Qwen模型
4. Qwen输出结构化JSON（要求严格遵循Schema）
5. 后端校验JSON合法性，持久化到数据库

关键Prompt设计如下：

你是一个促销规则解析器。请根据以下模板，将用户的自然语言描述转换为JSON格式的规则。

可用模板：
- 模板1: 给新用户发无门槛券（注册<=7天）
- 模板2: 给老用户发满减券（注册>30天且消费>1000）
...

用户输入："给深圳的新用户发一张5元券"

请输出严格符合以下JSON Schema的规则：
{
  "type": "object",
  "properties": {
    "user_region": {"type": "string", "enum": ["shenzhen", "guangzhou", "any"]},
    "user_register_days": {"type": "string"},
    "issue_coupon": {"type": "string"}
  }
}

第三步：处理“幻觉”与校验

LLM最大的问题是“一本正经地胡说八道”。有一次，我输入“给北京用户发券”，Qwen居然输出了"user_region": "beijing"，但我们的系统根本不支持北京！这要是上线，运营配置完发现无效，肯定又要找我吵架。

解决方案很简单：在输出后加一层Schema校验 + 白名单过滤。

from jsonschema import validate, ValidationError

def parse_rule(user_input: str) -> dict:
    # ... RAG流程 ...
    raw_output = llm.invoke(prompt)
    
    try:
        rule = json.loads(raw_output)
        validate(instance=rule, schema=RULE_SCHEMA)
        
        # 白名单校验
        if rule.get("user_region") not in ["shenzhen", "guangzhou", "any"]:
            raise ValueError("不支持的地区")
            
        return rule
    except (ValidationError, ValueError, json.JSONDecodeError) as e:
        # 记录日志，返回友好错误
        logger.error(f"规则解析失败: {e}, input: {user_input}")
        raise RuleParseException("无法理解您的描述，请参考示例")

第四步：性能优化

最初版本在本地跑，Qwen-1.8B响应要5秒，运营肯定等不及。于是做了几项优化：

1. 模型量化：从FP16转为4-bit GGUF，内存占用从3.6GB降到1.2GB
2. 缓存机制：对相同或相似的输入做LRU缓存（用Redis）
3. 异步预加载：服务启动时提前加载模型到内存
4. 降级策略：如果LLM超时，返回“建议使用标准模板”并引导到表单页面

优化后，P95响应时间压到1.8秒，勉强可接受。

---

效果对比：投入 vs 回报

指标	旧方案（手动改代码）	新方案（AI辅助）
规则配置耗时	2-3天（含测试上线）	<5分钟
需求变更频率	运营不敢频繁改	每天可迭代多次
我的加班次数	大促前每周3次	几乎为0
系统错误率	低（逻辑固定）	初期15%，现<3%

最让我惊喜的是，运营小姐姐居然主动学起了“如何写清晰的提示词”——她发现说“给新用户发5元券”比“弄个券给刚来的人”成功率高得多。这不就是AI普及的第一步吗？

---

踩过的坑与血泪教训

1. 别迷信“开箱即用”
   LangChain文档写得天花乱坠，但实际集成时，各种版本冲突、依赖地狱。我花了整整两天才让ChromaDB和Qwen在同一个Docker镜像里跑起来。

2. 中文分词是个坑
   text2vec对“新用户”和“新 用户”敏感，中间多了空格向量就差很远。后来我在前端加了自动清洗，把多余空格和标点去掉。

3. 不要裸奔上线
   第一次灰度发布时，有个运营输入“给所有用户发100万券”，Qwen居然真解析成了"coupon_amount": 1000000。幸好我在后端加了金额上限校验，不然公司可能第二天就倒闭了。

4. 资源监控必须跟上
   CPU推理虽然便宜，但并发一高，服务器负载直接拉满。现在我们用Prometheus监控llm_inference_time和cpu_usage，超过阈值就自动降级。

---

面试题挑战？现在我是出题人

上个月，我又去面了一家腾讯系公司。面试官问：“如果让你设计一个自然语言转业务规则的系统，你会怎么做？”

我笑了笑，打开笔记本，给他看了我们项目的架构图和线上数据。他眼睛一亮：“你们真的跑起来了？”

那一刻，我终于明白：技术的价值，不在于你背了多少面试题，而在于你解决了多少真实问题。

小厂资源有限，但正因为如此，每一次技术探索都必须紧扣业务，每一分投入都要看到回报。AI不是魔法，它只是工具。而我们后端工程师，就是那个把工具磨锋利、装上手柄、递给业务的人。

---

写在最后

如果你也在小厂，被各种“高大上”的技术趋势压得喘不过气，我想说：别慌。
从一个具体的痛点出发，用最小可行方案去验证，哪怕只是自动化了一个Excel导入，那也是进步。

我现在每天下班前，都会花半小时看一篇AI论文或跑一个Hugging Face Demo。不是为了装逼，而是为了下次产品经理说“我们要做个智能客服”时，我能淡定地回一句：“行，给我三天，我先做个PoC看看效果。”

技术探索的路上，资源永远不够，但热情和行动力，是我们最宝贵的资产。

对了，下周深圳有个小型后端技术沙龙，我准备分享这个项目。欢迎来聊，咖啡我请——前提是，别再问我“Transformer原理是什么”了，我真的会哭。