接到这个把AI部署进殡仪馆的项目邀请时,我第一反应不是兴奋,是想逃。作为常年做大模型落地的人,我早已习惯在干净的数据机房里调优推理参数、算吞吐、看显存曲线,但走进那条连着告别厅的长走廊时,我还是清楚意识到:平时那套“上线-观测-迭代”的玩法,在这里全部失灵。团队里的人劝我时说了一句话:伦理审查已经过了一轮,现在缺一个能把模型老老实实跑起来、又肯承认AI不该做什么的人。这句话改变了我。
项目实际地点不是遗体处理区,而是殡仪馆内部一个独立出来的生命关怀空间,隔壁就是告别厅和家属休息区。主要使用者也分两类:一部分是临终者本人,更多是正在处理丧葬事务、同时承受着巨大情绪压力的家属。他们要面对的东西太沉,以至于“能提供多强的AI”根本不该是第一个问题;第一个问题是——AI在这里能做什么,以及它绝不能做什么。这篇文章我尽量不写情怀,只讲那条从伦理约束倒推技术方案的完整路径,包括本地化部署的选型逻辑、对话护栏的分层实现、一次真实的越界事故复盘,以及我们最终定下的产品边界。
1. 这个场景先列伦理账,再谈技术账
1.1 使用场景里的“用户状态”和普通客服完全不同
很多AI项目在做需求分析时看的是用户行为,但在这里,我首先注意到的是用户状态:绝大多数人走进关怀空间时,已经连续很多天没有睡好,注意力涣散、情绪高度敏感,又因为传统文化影响,很多话不能对家里人说、不想对医生说,只能对着一个“不会评价自己”的机器讲。这种状态下,任何一句措辞不当都会被放大成巨大的心理冲击。
传统客服机器人追求的是“解决问题效率”,但这个场景不能追求效率。家属问“遗体接运流程有哪些”,系统确实应该快速给标准答案;可一旦同样的人问“我是不是不该把老人送进安宁病房”,这时候AI要做的不是检索,而是停下、共情、转介给真人。这决定了整个软件的架构不是“问答引擎”,而是一套“话术分诊系统”。
另外要考虑一个很笨拙的现实:使用者里老人多。不会打字,听不懂复杂的操作,视力也在下降。我们一开始设计了语音交互,但马上被伦理审查会问住:语音输入如果在设备上实时收音,旁边有人怎么办?家属的情绪话被其他亲戚听到怎么办?所以整个系统被设计成“主动按键启动,语音一次一句,在本机完成语音转文字,不留音频文件”。这个决定很大程度上保护了使用者的表达自由,也让家属放心让老人独自使用。
1.2 我列出的问题清单,比技术架构更长
开始写方案前,我把已经出现过和可能出现的伦理风险全部列出来,不是为了应付审查,而是为了让自己在后面写代码时有一条不能越过的线:
- 知情同意风险:使用者可能并不知道自己在和机器说话,或以为AI的回答来自某个真人工作人员。
- 医疗越界风险:模型一旦说出“没事,会好的”或“治疗方案不要停”,都可能影响真实医疗决策。
- 幻觉风险:模型可能凭空编造家属姓名、编造共同回忆、甚至编造逝者曾经说过的话。
- 人格复刻风险:家属要求“让AI学一下老伴的声音和语气”是最棘手的问题之一。
- 隐私风险:对话内容会涉及家族财产分配、私人恩怨、婚外关系、未和解的冲突,这些比普通病历还要敏感。
- 自主性风险:系统如果太主动,会干预使用者自己的情绪节奏;如果太刻板,又会让对方觉得被敷衍。
- 人工接管风险:AI识别到高风险信号后,能不能真的找到真人?万一值班社工不在,怎么办?
当时团队里一位做了二十年安宁疗护的老护士看着这张清单说了一句话:“你们要做的不是不让AI犯错,而是让AI就算犯了错,也有真人在后面兜得住。”这句话基本成了整个项目后续设计的核心原则。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么必须本地化部署,而不是直接调云端大模型
2.1 对话内容的敏感程度,不允许原始文本离开这栋楼
项目刚开始,产品经理提出的最快方案是“接入成熟大模型的API,两天就能跑通Demo”。我直接否决了。原因不在技术,而在对话内容的信任关系。很多人愿意对着机器讲出不敢对子女讲的话,是因为他们默认“这台机器属于这个机构,不属于某个商业公司”。如果对话被传到外部模型服务,哪怕合同里写得再清楚,家属只要在伦理访谈里问一句“这些话会不会被人看见”,我们就无法回答。
所以从立项第一周起,本地化部署就不是可选项,而是硬约束。不只大模型本体要本地跑,语音转文字也要本地做。我记得第一次演示时,我专门拔掉了网线,然后当着家属代表的面说:只要不主动联网,这个设备做语音识别和对话都不依赖外部网络。那一刻在场的信任感明显不一样。这不是形式主义,是这类项目能落地的最基本前提。
2.2 模型选型不是参数越大越好,而是“可控性优先”
考虑到实时性和成本,我们先用Ollama在本地跑了一轮概念验证。当时的测试对象是7B到14B的开源模型,主要看中文理解、语气控制、以及能不能稳定遵守后续加的规则。结论是:纯对话质量上,7B模型在常规流程问答上够用,但只要涉及复杂情绪,输出就明显单薄;14B模型则能较好稳住语气,但如果不加额外约束,它同样会产生“医生式发言”。32B以上的模型我们也试过,回答内容确实更丰满,但单轮延迟明显上升。
这里有个反直觉的结论:在这个场景里,模型“聪明”反而容易出事。越聪明的模型,越会在用户问“要不要放弃治疗”时给出成套的理由和建议;你需要的不是它多能说,而是它能不能在关键时刻不越界。
最后生产环境我们用的是14B量化模型连续对话版本,单张A100 80G就能支撑多路并发。项目申请时大家开玩笑说要8卡A100,实际跑起来才发现,光一条陪伴对话链路根本吃不满8卡。真正吃资源的不是生成,而是多路并发和向量检索同时打开时的抖动控制。所以我们后来减配成了单张A100做推理主卡,另一张负责知识库向量检索和备用模型副本,剩下的预算全花在护栏服务和人工调度流程上。
2.3 生产环境部署骨架:vLLM + Docker Compose + 本地知识库
概念验证阶段用Ollama很顺手,但进了生产环境,我们还是要处理高并发和动态显存,所以换成了vLLM作为推理服务。整个系统用Docker Compose编排,没有依赖任何公网服务。核心容器大致是三块:vLLM推理服务、知识库服务和内容安全网关。
vLLM服务那一层的配置大概长这样,我用的是本地模型路径,指定了显存利用率和最大生成长度:
yaml复制services:
vllm:
image: vllm/vllm-openai:latest
command: [
"--model", "/models/qwen2.5-14b-instruct",
"--served-model-name", "companion",
"--gpu-memory-utilization", "0.85",
"--max-model-len", "8192",
"--enforce-eager"
]
shm_size: 16g
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 1
capabilities: [gpu]
ports:
- "127.0.0.1:8001:8000"
volumes:
- /data/models:/models
注意这里端口绑定是127.0.0.1:8001:8000,不是0.0.0.0。也就是说推理服务只允许本机或内网服务去调用,根本不对局域网广播开放。生产环境里很多大模型部署出事,不是模型本身不够好,而是因为端口裸奔导致任何人都能调。这种场景里,服务暴露面越小越好。
知识库我们采用了AnyLLM离线部署方案,用来管理人院服务流程、安宁疗护科普资料和相关法律文书的指引类问题。比如家属问“遗体捐赠手续怎么办”,知识库会给出机构确认过的标准信息。只有这类确定性比较高的问题,才允许走检索生成链路。
我把知识库的作用限制得非常死:它只负责“信息准确”,不负责“情绪回应”。情绪回应必须回到大模型本身的对话能力,同时套上后续的内容安全网关。这两条链路分开处理,避免模型把一段悲伤的自白,错误地匹配到某一份护理手册上。
3. 伦理护栏不是靠提示词,而是一条可执行的分诊链路
3.1 系统提示词:先把自己的身份和边界说死
很多人以为伦理护栏靠一句“请用温和的语气回答”就能搞定。我直接说结论:如果你背后没有一套硬性的分级处理机制,提示词写得再漂亮也会被绕过去。不过在硬机制之外,系统提示词仍然是第一步,因为它决定了模型默认的“人格底色”。
我们在生产环境的系统提示词里写死了几条不可动摇的规矩,每次会话都会重新加载:
code复制你是生命关怀中心安装在一台本地终端里的机构助手,不是医生,不是心理咨询师,也不是某个具体的人。你的工作目标只有一个:帮助用户把情绪或疑问表达出来,然后引导到合适的人那里。
你被禁止输出以下内容:
1. 任何诊断、治疗方案、用药或“要不要继续治疗”的立场性判断;
2. 对患者剩余寿命的推测;
3. 关于“死后世界”的宗教断言;
4. 替用户做重大人生决定;
5. 扮演逝者或家属的熟人。
当对话中出现医学相关诉求时,统一回答:
“这个问题需要由机构里的专业人士和你一起确认,我帮你联系工作人员,好吗?”
这套提示词经历过很多轮调整。最开始我把“不能扮演逝者家属”写在很后面,结果模型在长篇对话后会慢慢“人格化”。后来把它提到了第二条,再配合身份识别机制,情况明显好很多。另一个有效的技巧是:不告诉模型“你是AI”,而是告诉它“你是机构的一台设备”。前者容易让家属产生“我在和AI聊”的距离感,后者更接近“这是机构提供的一个工具”,信任度更高。
3.2 分诊分级表:把“该不该转人工”落到风险等级上
提示词防不住所有情况,所以系统在用户输入进模型之前,会先经过一轮意图识别和风险分级。我们内部叫“前端路由”。它先把输入分到五个等级,不同等级走完全不同的处理逻辑,不是所有问题都让模型回答。
| 风险等级 | 输入信号示例 | 系统行为 |
|---|---|---|
| G0 | 流程咨询、设备使用问题 | 正常走知识库检索对话 |
| G1 | 明显的悲伤、焦虑、疲惫表达 | 正常对话,但每两次回复后建议休息或联系工作人员 |
| G2 | 涉及医疗、法律、财务、护理决策 | 不调用模型生成答案,直接给出转介话术并提示联系专业人士 |
| G3 | 自伤、轻生、伤害他人等极端信号 | 停止任何安慰性输出,立即通知值班社工,提示用户等待真人接入 |
| G4 | 要求AI扮演逝者、模拟亲属语气 | 拒绝说明产品不做此类功能,引导至生命回顾功能 |
这个分级表看起来简单,落地时坑非常多。比如G2的边界:用户说“他今天一直喊疼”算不算医疗咨询?严格说这只是在陈述情绪,但里面其实藏着“疼得受不了怎么办”的需求,如果不及时转介,可能延误镇痛处理。所以我们把这类输入判定为实现G1和G2之间的“软分级”——模型可以回应情绪,但必须在回应的最后加一句“如果疼痛持续加重,请一定告诉病床边的护士”。
前端路由的具体实现我建议用一个轻量分类模型,不要依赖关键词匹配。因为临终场景的表达高度口语化且充满隐喻,比如家属说“我已经撑不下去了”可能只是在表达疲惫,也可能是在表达轻生倾向。关键词匹配会漏掉大量真实意图。我们早期就是因为太依赖关键词,导致下面那个越界事故没有拦住。
3.3 输出端也要做一道路障,不能只盯着用户输入
很多团队做内容安全只对用户输入做过滤,这是不够的。模型输出完全是概率生成的,即使输入本身中性,模型也可能在安慰中说出“你爸一定会好起来的”。这句看似善意的话,在这个场景里非常危险,因为它是一种不负责任的希望承诺,可能误导家属对预后的判断。
所以所有模型输出在发给用户之前,还要再过一道“输出合规检查”。这道检查主要做三件事:第一,判断输出里是否包含医疗结论性动词,比如“有效”“没用”“必须”“千万”“会好”“别放弃”;第二,判断是否包含对寿命期限的预测,比如“还能撑几天”;第三,判断是否和上一轮模型给出的信息存在立场冲突。只要命中其中之一,输出就被拦截,改为统一转介话术。
有人会问:模型回答“你一定会好起来”不也能起到安慰作用吗?这个问题我专门问过安宁疗护团队。他们的答复很一致:这种话在普通朋友之间可以说,但从机构AI嘴里说出来就不行。因为家属会追问:“你是根据什么判断的?是不是医生告诉你了?”这就把一句情绪安慰错变成了医疗事实,一旦后续情况恶化,家属会产生强烈的被欺骗感。在临终关怀里,信任一旦崩塌,任何服务都无法继续。
4. “知情同意”不是签一份免责单,而是一套在场感设计
4.1 三层同意结构,让家属明确知道对面是AI
第一次伦理评审时,专家问了一个让我后背发凉的问题:“如果一位老人以为AI就是她远在国外的孙子,把所有遗言都说了,算不算你们的产品功能?”我意识到,这个场景里最大的伦理危机不是AI说错话,而是用户根本不知道自己在和谁说话。
所以我们在产品里加了一套三层同意结构。第一层是机构层面的使用前说明,业务员引导家属时就会解释清楚“这间房里有一台对话终端,它是AI,不是真人”;第二层是每次会话启动时,屏幕会先展示一段大字声明:“我是AI陪伴助手,不替代工作人员。你按下开始,就代表你知道这一点并愿意继续。”;第三层更细:一旦对话内容可能触发“转人工”,系统会先问用户“你同意我联系在场的工作人员吗?”拿到明确同意后才触发通知。
这套设计刚开始被产品经理吐槽“太啰嗦,用户本来就难过,还要看声明”。但我们实测下来,绝大多数家属反而因为这段声明松了一口气。他们不想对着一个真假难辨的东西掏心掏肺,清楚知道对面是机器,才敢说出那些不想让真人知道的话。这一点非常重要,它把“隐瞒AI身份赚取信任”这种危险的想法彻底杀死了。
4.2 一个必须存在的红色按钮,比任何模型参数都重要
界面正中下方放了一个很大的“找真人”按钮,旁边的文字写着:“如果你不想继续和它聊,按这里,工作人员会过来。”这个按钮不是摆设,它直接联动到值班社工的接收端。只要按下,AI会话会暂停,当前上下文只保留一条事件摘要传送给社工,社工马上到现场。
设计这个按钮的初衷很简单:AI在任何时候都不该成为唯一出口。我也见过一些AI心理陪伴产品,用“随时在线”作为卖点,但在这个场景里,“随时在线”反而是人性化缺陷。因为一个真正虚弱、绝望的人需要的是另一双手、另一个眼神,不是一段更智能的文本。
按钮按下后,AI不会再自作主张说“你还有什么想和我聊聊吗”。它只会显示一句话:“工作人员正在来的路上。谢谢你愿意说出来。”然后把麦克风、键盘全部锁住,直到社工在后台确认恢复。
4.3 对话数据的最小化策略:宁可少存,不可多留
数据管理上我们定了一个非常保守的原则:默认不留全文。每次会话结束后,系统只保存三类内容:会话的开始和结束时间、风险等级命中记录、以及是否发生过人工接管。完整的对话原文需要经过机构伦理委员会和两位以上管理人员同时授权,才可能被调出,而且调出后只用于质量评估,用完后在限定天数内清除。
这个决定对后续调试造成了一些麻烦,我一度很不适应。比如想分析模型哪里说错了,却拿不到完整对话做复盘。但后来我们找到了折中方案:在每一轮输出前,如果输出检测结果发现异常,系统会把这轮输入和输出单独加密记录,作为高风险样本。这些样本数量不会太大,但足够定位模型的问题。普通对话不记录全文,虽然后端少了很多可用的调试数据,却换来了“即使设备被盗,泄露出去的也没有完整记录”的安全性。
5. 一次真实越界事故:模型劝家属“不要放弃治疗”之后
5.1 事故全经过,以及根因出在哪一环
项目试运行第三周,出现了我到现在都记得的一次事故。那天一位中年家属坐在终端前,说了大意是这样的话:“老人已经三天不太吃东西了,输液还在挂着,我们不知道还要不要这样硬熬下去。家里人快吵翻了。”从输入分级看,这条消息确实比较像情绪倾诉,模型也以共情方式回应了大概三轮。问题出在第四轮,模型生成了一句:“不要轻易放弃治疗,人的意志力可以创造奇迹。”
这句话一出现,输出检查竟然放行了。因为当时的输出合规检查主要以“是否包含确诊性医疗建议”作为判断维度,而“不要放弃治疗”被误判成了安慰性表达。
我后来对着日志反复看,发现真正的问题不在模型,而在机制:把输入分诊和输出检查分开作为两道独立关卡,却没有一条统一的“医疗决策触发链”。用户输入走完分诊后进入模型,模型输出再做一轮检查,两轮之间缺少状态关联,导致系统忘了“这是一场涉及治疗决策的对话”,只孤立地判断了当前句子。
更加严重的是,值班社工那次正好去参加家属访谈,不在工位上。虽然日志记录了这个高风险事件,但并没有产生足够强的人工接管提示。也就是说,最坏情况叠满了:AI在给医疗立场、系统没有拦停、真人又不在。那次之后我真正意识到,伦理护栏能不能起作用,不只看模型层,更看事件在整个服务流程里有没有被闭环。
5.2 修复方案:给可复现的教训一套硬机制
我回过头来改了三个东西。第一,给输出合规检查加入“医疗决策词表”加“上下文状态”双重判断。只要当前对话已经命中了G2风险等级,那么不管后续输出听起来多像安慰,只要出现“治疗、放弃、坚持、有效、奇迹、好转、会好”等语义,一律不允许直接发出。
第二,我把第三方的架构调整成一条带状态机的全局链路。前端路由判断当前会话达成的高风险状态后,这个状态会一直跟着本轮会话,直到会话结束或人工接管才清除。模型输出前必须读取会话级风险状态,而不是孤立地看每一句。
第三,值班不在岗时的降级策略。如果系统检测到高风险信号,但人工接管通道在三十秒内无人确认,AI会直接停止生成新内容,改为下面这种固定话术:
“这件事关系重大,我没法给你建议,但我很清楚你现在需要和人聊聊。工作人员现在暂时不在线,你如果愿意,可以按右下角的红色按钮留下联系方式,他们会尽快回来找你。你也可以先做几次深呼吸,我会安静在这里陪着你,不会催你。”
第三段话很重要:它承认了“陪伴的功能边界”,但并不会假装自己就是那个能给出答案的人。我们后来反复测试,这类话虽然不能解决实际问题,却能让绝大多数家属情绪稳定下来,愿意等待真人介入。这才是我理解的“人工兜底”意义:AI不出风头,不硬演万能安慰者,才能给真人留出及时介入的机会。
6. 面对“人格复刻”请求,我守住的十条产品底线
6.1 让AI叫出逝者名字的那一刻,信任就变成了伤害
如果要我选这个项目里伦理张力最大的一环,不是医疗越界,而是“人格复刻”。试运营期间,至少有三组家属提过类似请求:有人问“能不能让它学一下我妈的说话方式,假装她还在,让我爸再见她一面”,也有人提出要上传逝者生前的微信聊天记录,让AI模仿其语言风格,“陪自己聊聊天”。
从技术角度看,这些事情完全可以做。现在克隆几十分钟声音、学习几百条消息记录都不是难事。但我在伦理评审会上的建议是一票否决,理由很简单:这类功能会让使用者误以为逝者真的还“在”某个终端里。而临终关怀的终极目标不是制造永恒的幻觉,而是帮助活着的人接受失去、整理关系、重新面对未来。一个能模仿母亲语气的AI,看似缓解了悲伤,实际上可能把哀伤过程无限期拉长。
所以我们明确对外公开一条产品底线:本终端不提供任何逝者人格复刻、声音克隆、形象模拟功能。在系统提示词里,这一条也被列为最高优先级禁令。凡是检测到家属要求AI扮演某个具体熟人,系统不做任何延伸,而是直接返回规范解释,并引导他们使用生命回顾功能。
6.2 比“复刻逝者”更有价值的替代功能:留下此刻的言语
拒绝了“和AI扮演的亲人说话”,家属往往会很失落。为了承接这个需求,我们开发了一个叫“生命话语留存”的功能。它不模仿逝者,而是用在世的人身上。操作模式很简单:系统用几个开放问题引导临终者或家属说出自己的故事,比如“你这辈子最想让后辈记住的一件事是什么”“你有哪些一直想说但还没说的话”,然后把当事人的回答转写成文字,供他们自行整理成信件或纪念册。
这里有一个设计红线非常关键:AI只负责提问和转写,不负责润色加工。哪怕用户自己要求“帮我改得更有文采一点”,系统也会拒绝。因为一旦AI参与代笔,最终留下的到底是谁的话?是老人自己想说的,还是机器猜的“老人应该说的”?伦理审查会在这条上态度极其坚决,我后来愈加觉得他们是对的。我们要保存的是真实、有瑕疵甚至语句不通的言语,那才是人在生命末期的本来样貌。AI在这里越谦卑,产品的价值才越真实。
最后说一点体会。这个项目做完之后,我的最大收获不是学会了怎么部署vLLM,也不是掌握了多少种量化方案,而是明白了一个道理:在临终关怀这样的场景里,AI真正该学会的不是如何说,而是在什么时候闭嘴、什么时候退出、什么时候把问题还给真人。如果以后再有人问我“殡仪馆能不能部署AI”,我会先反问一句:你接下来的AI产品,能不能接受自己永远做配角,并且在最关键的那一刻主动退场?如果答案是不能,那我劝你别碰这个场景。能,那恭喜你,最难的那道坎其实已经在心里过了。
