顺丰大模型开发二面

1、自我介绍

2、项目拷打

3、RAG 的完整链路是什么，哪些地方最容易出问题

RAG 的完整链路一般是文档接入、清洗去噪、切 chunk、向量化、建索引、在线检索、重排、上下文构造、Prompt 拼接、模型生成和结果后处理。线上请求过来以后，先对用户 query 做归一化处理，再进行向量召回或者混合召回，把候选文档取回来，然后用 rerank 模型重新排序，选出最相关的内容拼到 prompt 里，再交给大模型回答。

最容易出问题的地方通常有几个。第一是 chunk 切得不合理，太短会丢语义，太长会导致噪声太多。第二是召回率不够，模型根本没拿到正确证据。第三是重排不准，正确文档被排到后面。第四是上下文拼接太乱，模型虽然拿到了证据，但没有用好。第五是 prompt 约束不够，导致模型出现幻觉或者答非所问。很多时候最后看起来像模型问题，其实本质是检索链路问题。

4、RAG 优化一般怎么做

RAG 优化一般分数据侧、召回侧、排序侧和生成侧。数据侧重点是清洗、去重、标准化和合理切分。很多业务文档里会有格式噪声、冗余页眉页脚、乱码、错别字，这些都要提前处理，不然后面索引质量会很差。chunk 切分时要控制长度和 overlap，有时还会补标题、目录、标签这些元信息，让召回更稳定。

召回侧常见做法是混合检索，把向量召回和 BM25 结合起来，兼顾语义和关键词匹配。排序侧一般会用 cross-encoder 或 rerank 模型重新排序，提高前几条结果的准确性。生成侧主要是控制 prompt，比如要求模型必须基于资料回答、资料不足时明确说不知道、输出时附带引用依据。再往后会做离线评测和线上日志分析，拆开看是召回问题还是生成问题。

5、Embedding 模型怎么选，评测指标看什么

Embedding 模型选择要看业务场景。如果是通用中文问答场景，会优先选中文语义检索表现比较稳定的模型；如果是垂直领域，比如物流、客服、医疗、金融，就要看领域迁移能力，很多时候还要做领域微调。除了效果，还要看向量维度、编码速度、吞吐和部署成本，因为检索系统通常是高频服务，不能只看离线指标。

评测时主要会看 Recall@K、HitRate@K、MRR、NDCG 这些指标。Recall@K 看的是正确文档有没有出现在前 K 个结果里，MRR 更关注正确结果排得靠不靠前。如果是整条问答链路评测，还会看最终答案正确率、忠实性、相关性和拒答准确率。很多时候 embedding 模型离线语义相似度分数不错，但在线业务效果不一定最好，所以还是要结合真实 query 做评测。

6、重排模型的作用是什么，和召回有什么区别

召回的目标是尽可能把相关文档找全，重点是覆盖率，所以一般会先取一个相对大的候选集。重排的目标是在这些候选里把最相关的排到前面，重点是排序精度。两者解决的问题不一样，召回更看 recall，重排更看前几名的质量。

向量检索或者 BM25 检索通常速度快，适合做第一阶段粗召回；rerank 模型一般更重，因为它会把 query 和候选文档做更细粒度的交互建模，所以更适合做第二阶段精排。没有重排时，经常会出现“召回来了一堆看起来都相关的内容，但最合适的没排第一”的问题，最终就会影响大模型生成答案的质量。

7、你怎么理解大模型幻觉，常见解决方式有哪些

大模型幻觉本质上是模型生成了看起来合理但实际上不真实、不符合事实或者没有依据的内容。原因通常有几类，一类是模型预训练阶段知识本身就不完整或者已经过时，一类是当前输入上下文不够，模型只能凭统计规律往下编，一类是 prompt 约束不清，或者生成温度太高导致发散。

常见解决方式一是接入 RAG，让模型基于外部知识回答；二是加强 prompt 约束，比如明确要求没有依据就说不知道；三是降低生成温度，提高输出稳定性；四是做结果校验，比如结构化字段校验、规则过滤、事实核查；五是在特定场景里通过 SFT 或偏好对齐减少不可靠回答。对于业务系统来说，最重要的不是让模型永远全答出来，而是该答的时候答准，不该答的时候敢拒答。