Langchain-Chatchat如何实现问答结果的短信推送?
在企业智能化转型不断深入的今天,越来越多组织开始部署本地大模型系统来处理内部知识服务。一个典型的挑战浮现出来:即便后台已经能精准回答技术文档、运维手册中的复杂问题,用户仍需守在网页前等待响应——尤其当答案涉及紧急操作时,这种被动等待可能带来严重后果。
有没有办法让系统“主动出击”,把关键信息直接送到用户手上?比如,当员工问“数据库主从同步中断怎么办”后,不仅页面显示解决方案,还能立刻收到一条短信提醒?这正是本文要解决的问题。
我们以开源项目Langchain-Chatchat为例,探讨如何在其基础上构建一套稳定可靠的短信推送机制。这个过程不依赖云端知识传输,所有数据始终留在内网,同时又能借助成熟的通信通道实现毫秒级触达。
理解核心组件:Langchain-Chatchat 的能力边界
Langchain-Chatchat 并不是一个简单的聊天界面,而是一套完整的本地化 RAG(检索增强生成)系统。它允许你上传 PDF、Word 或 TXT 文档,自动解析内容并建立语义索引,最终通过大语言模型返回基于这些私有资料的答案。
它的架构清晰且模块化:
- 前端提供交互界面;
- 后端 API 负责文档加载、文本分块、向量化存储和问答生成;
- 支持多种本地模型(如 ChatGLM3、Qwen、Baichuan),可通过 llama.cpp 加载 GGUF 格式运行于普通服务器;
- 所有流程无需联网,原始文件永不外泄。
这套系统本身专注于“理解与生成”,并不关心“如何通知”。也就是说,它会完美地给出一段 200 字的技术指令,但不会告诉你:“这段话很重要,请立即查看。”
而这恰恰是用户体验的断点。
短信为何仍是不可替代的通知方式?
尽管微信、钉钉、邮件等渠道广泛应用,但在某些场景下,短信依然具备独特优势:
- 强制可见性:几乎所有手机都会弹出短信通知,即使应用被关闭或静音;
- 跨平台通用:老人机、备用机、访客设备都能接收;
- 法律效力强:银行交易、医疗预约等领域仍将短信视为正式通信凭证;
- 低延迟高到达率:运营商通道保障了 99% 以上的送达成功率,平均响应时间在 2 秒以内。
更重要的是,短信内容可以结构化控制。例如使用模板变量${answer}动态填充回答摘要,既合规又灵活。只要提前在阿里云、腾讯云等平台完成企业认证、签名备案和模板审核,就能合法调用 HTTPS 接口发送非营销类通知。
这意味着我们可以安全地将 AI 回答封装成一条简洁明了的短信,推送给指定人员。
如何打通“问答 → 短信”的最后一公里?
整个集成的关键在于事件监听 + 异步触发。
Langchain-Chatchat 提供了标准 RESTful 接口,最常用的是/chat接口,用于提交问题并获取回答。我们的目标是在该接口成功返回后,判断是否需要推送,并将结果转发至短信服务。
架构设计思路
用户提问 ↓ Langchain-Chatchat API Server ↓ [新增] 通知中间件(拦截响应) ↓ 条件判断 → 是否需短信推送? ↓ 是 异步任务队列(Celery / APScheduler) ↓ 调用云短信 API(如阿里云 Dysmsapi) ↓ 用户手机收到短信注意几个关键原则:
- 不能阻塞主流程:短信发送失败不应影响问答功能本身;
- 必须异步执行:避免因网络延迟拖慢整体响应;
- 支持规则过滤:不是每个问题都值得发短信,应可配置触发条件。
实现示例:基于阿里云短信的服务封装
以下是一个简化但可用的 Python 函数,模拟调用阿里云短信接口:
import requests import json from datetime import datetime def send_sms(phone_number: str, answer: str): """ 发送问答结果到指定手机号 :param phone_number: 接收方手机号(带国家码,如8613800000000) :param answer: 从 Langchain-Chatchat 获取的回答文本 """ url = "https://dysmsapi.aliyuncs.com/" params = { 'RegionId': 'cn-hangzhou', 'Action': 'SendSms', 'Version': '2017-05-25', 'PhoneNumbers': phone_number, 'SignName': '企业知识助手', # 已备案的签名 'TemplateCode': 'SMS_240000000', # 审核通过的模板ID 'TemplateParam': json.dumps({ 'question_time': datetime.now().strftime("%Y-%m-%d %H:%M"), 'answer': answer[:100] + "..." if len(answer) > 100 else answer }), 'AccessKeyId': 'YOUR_ACCESS_KEY_ID', # 替换为真实AK 'Timestamp': datetime.utcnow().strftime('%Y-%m-%dT%H:%M:%SZ'), 'Format': 'JSON' } try: response = requests.get(url, params=params, timeout=5) result = response.json() if result.get('Code') == 'OK': print(f"[INFO] 短信发送成功 → {phone_number}") return True else: print(f"[ERROR] 短信发送失败 → {result.get('Message')}") return False except Exception as e: print(f"[EXCEPTION] 短信接口异常 → {str(e)}") return False⚠️ 注意事项:
- 生产环境务必使用官方 SDK 进行签名(HMAC-SHA1),防止密钥泄露;
TemplateParam中的字段名必须与审核通过的短信模板完全一致;- 单条短信长度限制为 300 字符以内,长回答需截取或引导跳转。
工程实践建议
1. 使用 Celery 实现异步解耦
为了不影响主服务性能,推荐将短信发送放入后台任务队列:
from celery import Celery app = Celery('tasks', broker='redis://localhost:6379/0') @app.task def async_send_sms(phone, answer): send_sms(phone, answer)然后在/chat接口的响应逻辑中添加触发代码:
# 假设已获得 answer 和 user_phone if should_trigger_sms(question): # 自定义判断逻辑 async_send_sms.delay(user_phone, answer)这样即使短信服务暂时不可用,也不会导致问答超时。
2. 敏感信息脱敏处理
内部文档中常包含 IP 地址、密码、工单编号等敏感字段,在推送前应做掩码处理:
import re def mask_sensitive(text): # 掩盖 IPv4 地址 text = re.sub(r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b', '***.***.***.***', text) # 掩盖密码字段 text = re.sub(r'(?i)password\s*[:=]\s*\S+', 'password = ***', text) # 掩盖手机号(可选) text = re.sub(r'1[3-9]\d{9}', '***********', text) return text3. 智能推送策略
并非所有问题都需要短信通知。可以通过以下方式实现精细化控制:
- 关键词匹配:若回答中出现“立即重启”、“停止服务”、“核心故障”等词,则标记为高优先级;
- 用户标签:仅对运维、值班工程师等角色开启自动推送;
- 频率限制:同一用户每小时最多接收 3 条,防刷防误触;
- 内容长度判断:超过 200 字的回答改为发送短链接,指向 Web 端详情页。
4. 日志与监控
建立独立的日志表记录每次推送状态:
| 字段 | 说明 |
|---|---|
| question_hash | 问题指纹,用于去重 |
| answer_summary | 截取的回答摘要 |
| phone_numbers | 接收号码列表 |
| status | 成功 / 失败 / 重试中 |
| error_code | 错误码(如 InvalidTemplateParameter) |
| retry_count | 重试次数 |
| created_at | 创建时间 |
结合 Prometheus + Grafana 可视化展示每日发送量、失败率趋势,及时发现异常。
5. 权限与成本控制
- 设置 RBAC 权限:只有管理员可启用短信功能;
- 配置白名单号码:防止恶意填写他人手机号;
- 设定日限额:如每天最多发送 100 条,超出则告警;
- 定期审计日志:检查是否有滥用行为。
典型应用场景
这种“智能问答 + 主动通知”的组合已在多个行业中落地:
场景一:IT 运维知识库
一线员工询问“交换机端口异常怎么处理”,系统自动生成排查步骤,并短信发送给值班工程师。即使不在电脑前,也能第一时间响应。
场景二:医疗机构患者咨询
医院部署本地 AI 助手解答常见问题(如“疫苗接种禁忌”)。患者扫码提问后,除页面显示外,还会收到一条确认短信,提升信任感。
场景三:工业现场设备维修
工人通过平板查询某型号 PLC 的复位流程,系统识别为高风险操作,立即群发短信给三位主管备案,确保多人知情。
小结:让静态知识真正“活”起来
Langchain-Chatchat 的价值不只是“能回答问题”,而是“能在正确的时间把答案送到正确的人手中”。通过在其输出层接入短信推送机制,我们实现了从被动查询到主动服务的跃迁。
这一方案的核心优势在于:
- 安全性不受损:知识仍在本地,仅推送脱敏后的摘要;
- 实用性大幅提升:关键信息直达移动端,减少遗漏风险;
- 扩展性强:同一架构可适配企业微信、钉钉、邮件等多种通知方式。
未来还可以进一步探索:
- 结合用户行为分析,预测哪些问题更可能需要后续跟进;
- 利用语音合成技术,将重要通知转为电话播报;
- 建立反馈闭环:用户收到短信后点击“已处理”,反向更新系统状态。
技术的本质是服务于人。当我们不再要求用户“盯着屏幕等结果”,而是让系统主动说“我已经准备好了解决方案”,这才是智能化真正的意义所在。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考