企业官网建设流程全解析

背景痛点：规则引擎为何“听不懂人话”

过去两年，我维护过一套基于正则+关键词的客服系统。用户问“我昨天买的手机能退吗”，规则要写“退|退货|退款|能不能退”，一旦用户换成“想把手上的新机退了”，规则立刻抓瞎。更糟的是多轮对话：用户先问“运费谁出”，再问“那要是七天外呢”，上下文一丢，答案全靠猜。结果客服同学每天仍要人工兜底 60% 的咨询量。

LLM 的出现把“写规则”变成了“读语义”。它能把“想把手上的新机退了”自动映射到“退货政策”意图，还能记住前面的“运费”话题，给出连贯回答。对开发团队来说，最大收益是把维护上万条正则的成本，变成维护一段自然语言 prompt。

技术选型：OpenAI、Claude 还是本地 LLM？

我花两周跑了三组对比实验，结论直接放表：

选型建议

1. 冷启动、无 GPU：直接 OpenAI，两周就能上线。
2. 对数据出境敏感：用 Claude，再通过 AWS Bedrock 做 VPC Endpoint。
3. 日均百万轮以上：租 A100 本地部署，成本可降到原来的 1/10。

核心实现：Python 搭一套最小可用框架

下面代码全部跑通 Python 3.10，依赖仅openai>=1.0和redis。

1. 会话 ID 生成与上下文缓存

import uuid import redis from typing import Dict, List r = redis.Redis(host="localhost", decode_responses=True) def get_session_id() -> str: return uuid.uuid4().hex def save_turn(sid: str, role: str, content: str, ttl: int = 3600) -> None: key = f"chat:{sid}" r.lpush(key, f"{role}:{content}") r.expire(key, ttl) def load_history(sid: str) -> List[Dict[str, str]]: key = f"chat:{sid}" items = r.lrange(key, 0, -1) history = [] for item in reversed(items): # 按时间正序 role, content = item.split(":", 1) history.append({"role": spinxo role, "content": content}) return history

2. 带退避机制的 API 调用封装

import openai import time from typing import List, Dict client = openai.OpenAI() def chat_with_backoff(messages: List[Dict[str, str]], max_retry: int = 5) -> str: for attempt in range(1, max_retry + 1): try: rsp = client.chat.completions.create( model="gpt-3.5-turbo", messages=messages, temperature=0.3, max_tokens=300 ) return rsp.choices[0].message.content except openai.RateLimitError as e: wait = 2 ** attempt time.sleep(wait) except Exception as e: raise RuntimeError(f"LLM call failed: {e}") from e raise RuntimeError("Exceed max retry")

3. 意图识别 prompt 模板

intent_prompt = """ 你是客服意图识别器，只输出 JSON，不解释。 用户问题：{question} 可选意图：[退货政策, 运费说明, 优惠券, 账号安全, 其他] {"intent": "退货政策"} """

把intent_prompt.format(question=msg)塞进messages里，LLM 会返回干净 JSON，后续用json.loads即可。

生产考量：并发、安全都不能省

1. 性能压测

我用 locust 起 100 并发，脚本里每次随机拿 200 条真实对话。结果：

• 平均延迟 780 ms，P95 1.2 s
• 错误率 0.8%，全部来自限流触发退避

优化手段：

• 把 Redis 换成 6 GB 连接池，rps 从 1200 提到 3200
• 在网关层做 20 次/秒令牌桶，减少打到 LLM 的突发

2. 安全方案

• 敏感词过滤：先过一遍本地 DFA 树，100 μs 内完成
• 日志脱敏：写文件前用正则把手机、邮箱、身份证打码
• 返回侧再扫一次，防止模型幻觉泄露内部知识

避坑指南：血泪经验总结

1. 上下文长度超限

场景：用户聊了 50 轮，token 数飙到 3.8k，GPT-3.5 直接截断。
解决：

• 对历史消息做滑窗，保留最近 6 轮 + 系统摘要
• 摘要由 LLM 自己生成，100 token 概括前面所有关键信息，实测意图准确率不掉

2. 模型幻觉回答

现象：用户问“你们卖苹果吗”，模型答“有的，红富士农场直采”。实际我们只做 3C。
检测：

• 让 LLM 先输出{"confidence": 0.85}，低于 0.7 走兜底话术
• 答案里出现品牌词必须命中后台 SKU 白名单，否则触发“暂未提供，转人工”

纠正：

• 把官方文档切成 512 token 块，做向量索引
• 检索 Top3 相关段落塞进 prompt，实测幻觉率从 12% 降到 2%

代码规范小结

• 全项目强制black + isort，CI 里跑flake8 --max-line-length 88
• 所有函数写类型标注，public 函数加Raises声明
• 网络、磁盘、LLM 三类异常分别捕获，日志用extra={"sid": sid}便于追踪

开放问题：如何平衡大模型成本与响应速度？

我把 Claude 换到 Haiku 后，成本降一半，但平均延迟仍比 GPT-3.5 高 200 ms；本地 7B 模型速度飞起，却需要常备 GPU。你的业务场景会怎么选？是“小而快”的本地量化，还是“贵但稳”的云上 API？欢迎留言聊聊你们的折中方案。