暖哇科技 大模型开发 二面

1、先做一下自我介绍

2、介绍一个你最熟悉的大模型项目

3、你在项目里具体做了哪些优化

4、如果让你做一个保险知识问答系统，你会怎么设计

如果是保险场景，我会把重点放在“依据”和“边界”上。因为用户问的很多问题，比如能不能赔、赔多少、什么情况下免责、等待期怎么算，这些都不是开放式闲聊，不能让模型自由发挥。

整体上我会先把知识源整理出来，常见的包括：

• 保单条款
• FAQ
• 理赔规则
• 产品说明
• 客服知识库
• 内部业务手册

然后对这些文档做清洗、切分、去重、打标签和建索引。检索层我会优先考虑混合检索，因为保险场景里很多词比较硬，比如免责、既往症、等待期、受益人、赔付比例这类，单靠语义检索不一定够稳。

生成层会尽量限制模型，只让它基于证据回答，而且最好能引用条款或者来源。如果资料不足，就直接拒答或者提示人工确认，不要硬编。

5、保险条款问答和普通问答有什么区别

普通问答更关注自然度和覆盖度，但保险条款问答更关注规则、条件和证据。很多用户问题表面上是一个自然语言问题，背后其实对应的是明确的条款判断。

比如用户问“我这个情况能赔吗”，系统不能像聊天一样只给个大概说法，而应该尽量拆清楚：

• 对应哪个险种
• 涉及哪条责任范围
• 有没有免责条款
• 是否受等待期影响
• 是否和医院范围、材料完整性有关

6、RAG 和微调你怎么理解，边界怎么分

我的理解是，RAG 和微调解决的问题不一样，很多时候不是二选一，而是配合使用。

RAG 更适合解决的是知识更新和私域知识接入的问题。尤其保险这种场景，条款、规则、FAQ 都可能更新，如果完全靠模型参数记忆，不现实，也不利于追溯。

微调更适合解决的是输出习惯和任务模式。比如你希望模型更稳定地按某种格式回答，或者更懂某类任务表达，那微调会更有用。

• RAG 解决“知识从哪里来”
• 微调解决“模型怎么更好地按要求回答”

7、线上效果不好的时候你怎么排查

一般我不会一上来就怀疑模型，而是按链路排。先看知识库有没有更新、切分策略有没有变、embedding 模型有没有切换、rerank 参数有没有改、Prompt 有没有动、上下文是不是变长了。把这些基础信息先过一遍之后，再去抽 badcase 看问题集中在哪一段。

通常会重点看这几个问题：

• 正确资料有没有被召回
• 召回到了以后有没有被 rerank 排到前面
• 上下文有没有把关键证据完整喂进去
• 模型有没有按照证据回答
• 输出后处理有没有误伤

8、你怎么看大模型在保险场景里的价值

我觉得大模型在保险场景里比较有价值的方向，其实不是那种特别炫的 Agent，而是先把几个刚需场景做扎实，比如：

• 保险知识问答
• 智能客服辅助
• 保单条款解析
• 理赔材料摘要
• 文档信息抽取
• 审核辅助

尤其像条款解释、客服辅助、材料整理这类场景，本身就有大量文本和规则，大模型很容易切进去。

但这类场景也有边界，像最终理赔结论、强风控判断这种高风险动作，不太适合完全交给模型直接拍板，更适合做人机协同，或者模型+规则的组合。

9、为什么想来我们公司

10、你觉得自己的优势和短板是