1）你先简单介绍一下这个项目
考点：你能不能在 1 分钟内讲清楚业务价值和技术主线。
你可以这样答：
这是一个面向食品加工企业内部知识管理场景的智能问答项目。企业内部有大量法规、行业标准、检测规范、操作规程和业务文档，原来主要靠人工翻阅，检索效率比较低。 我做的事情是把这些文档统一解析和入库，基于 RAG 的方式搭建问答系统。用户输入自然语言问题后，系统会先做问题向量化，再去向量库检索相关片段，经过重排序后拼接上下文，最后调用大模型生成答案，并把引用来源返回给前端。项目强调本地化部署和答案可追溯，主要是为了满足企业数据安全和业务可信度要求。
2）这个项目为什么要做？解决了什么问题？
考点：业务理解能力。
答题方向：
-
企业文档分散
-
查询依赖人工翻找
-
知识复用效率低
-
大模型直接裸问不可靠
-
所以需要“检索增强 + 来源追溯 + 本地部署”
你可以说：
核心痛点不是“没有数据”，而是“有很多文档，但不好找、不好用”。这些资料分散在不同文件里，员工遇到问题时需要手动翻阅，效率低，而且容易遗漏。 所以项目目标不是做一个泛聊天机器人，而是做一个围绕企业知识库的问答系统，把文档变成可检索、可追溯、可持续更新的知识服务能力。
3）这个项目的核心技术链路是什么？
考点：你是否真的理解 RAG。
标准回答：
整体链路可以概括成五步： 第一，文档解析，支持 PDF、Excel 等格式； 第二，文本切分，把长文档切成适合检索的 chunk； 第三，向量化，使用 embedding 模型把文本转成向量； 第四，检索与重排序，先做向量召回，再通过 rerank 提高结果相关性； 第五，答案生成，把召回片段作为上下文输入大模型，最后返回答案和引用来源。
4）为什么要用 RAG，而不是直接把问题丢给大模型？
考点：AI 系统设计认知。
可以答：
直接问通用大模型有两个明显问题： 一是企业内部知识它本来不知道； 二是容易出现幻觉，回答看起来像真的，其实没依据。 RAG 的价值在于先从企业知识库里检索到相关片段，再让模型基于证据生成答案。这样一方面能覆盖私有知识，另一方面可以把答案追溯到原始文档，可信度更高。项目里也明确把“避免大模型幻觉”和“答案可追溯”作为核心价值点。
5）Graph-RAG 和普通 RAG 在你这个项目里是什么关系？
考点：你会不会乱吹概念。
稳妥说法：
普通 RAG 的重点是“从文本 chunk 里找相关内容”；Graph-RAG 更强调把实体和关系组织起来，适合做跨文档、多跳关联和全局关系理解。 这个项目材料里提到采用了 Graph-RAG 机制，但从现有展示内容来看，落地链路的主体仍然是“文档解析、向量化、向量检索、重排序、答案生成”这条主链，所以面试里我会把它表述成：以 RAG 为主链，在部分知识组织和关系增强上引入 Graph-RAG 思路 。这样更稳，不会把自己送进图数据库追问区。
这个回答很重要。别上来就说“我们是行业领先 Graph-RAG 架构”，那句 PPT 风味太重，面试官一开心，就会开始追实体抽取、关系建模、图谱更新、一致性维护。然后你就从候选人变成祭品。
6）为什么要做本地化部署？
考点：企业场景意识。
答题方向：
-
文档敏感
-
企业合作
-
减少数据外发
-
合规和安全
因为项目涉及企业内部资料，包括规章、标准、流程、操作性文档，这类内容通常不适合直接走公网推理链路。 本地化部署的价值是把知识库和模型能力尽量放在本地环境中处理，减少敏感数据外流风险，同时也更符合企业合作场景下的数据安全要求。项目材料中也明确把“本地化部署，保障数据安全”列为核心设计点。
7）为什么要加重排序（Rerank）？
考点：你是否知道向量检索的局限。
标准说法：
只靠向量检索，召回结果在语义上可能相关，但不一定最贴近用户真实问题，尤其是在文档内容相似、术语重复较多的场景下，容易把“沾边但不关键”的片段召回来。 所以需要在召回后再做一层重排序，对候选片段重新计算与问题的匹配度，把最相关的内容放前面，再去拼上下文，这样能提升最终答案质量。项目的业务流程里也明确写了“向量检索、重排序筛选相关片段”。
8）这个项目里你主要负责什么？
考点：个人贡献，避免“我们做了”。
你要按你真实参与度选说法。安全模板：
我主要参与的是文档处理和问答链路这一侧的设计理解与方案整理，包括文档解析、文本切分、向量化、检索增强和答案生成这条链路的理解与梳理；同时我也重点关注了为什么要做本地化部署、为什么要做来源追溯，以及 Graph-RAG 和普通 RAG 的差异。 如果面试更偏工程实现，我会把我真正参与的部分讲清楚，不会把整个团队工作都算到自己头上。
这一句没有炫技，但很保命。
9）文档为什么要切分？怎么切分更合理？
答题方向：
-
文档太长，不能整篇喂给向量库
-
太大召回不准，太小上下文断裂
-
一般按语义段落 / 标题层级 / 固定长度 + overlap
文档切分的核心目标是在“检索精度”和“上下文完整性”之间做平衡。 如果 chunk 太大，会导致语义太杂，召回不准；如果太小，上下文容易断掉。 更合理的方式通常是结合文档结构做分段，比如按标题、段落、表格块来切，在此基础上控制长度，并保留一定 overlap，避免跨段信息丢失。项目材料里虽然没有展开具体参数，但明确提到了“文本分块策略”是文档处理环节的重要部分。
10）为什么选 BGE 做 embedding？
答题思路：
-
中文效果较好
-
社区常用
-
部署方便
-
适合语义检索
embedding 模型的选择本质上看几个维度：业务语言、检索效果、部署方式、推理成本和项目集成复杂度。
对这个项目来说，文档以中文知识资料为主，而且企业合作场景更强调本地化部署和数据安全，所以相比纯云端 API embedding，像 BGE 这类开源、中文效果较好、适合 RAG 检索任务的模型会更合适。
同时它的生态也比较成熟，和向量库、rerank 链路的配合比较方便，因此是一个比较稳妥的工程选择。
11）为什么答案要附来源引用？
答题方向：
-
降低幻觉
-
便于验证
-
增强可解释性
-
企业场景很重要
企业场景里“答得像”没有意义，关键是“答得有依据”。 所以引用来源很重要，它一方面能帮助用户快速回看原文，另一方面能提升系统可信度，也方便排查是“模型生成问题”还是“检索证据问题”。项目材料里把“答案可追溯至原文档”和“最终返回前端并附来源引用”都写得比较明确。
12）如果检索结果不准，你会怎么优化？
这是高频必问，建议直接背。
答法：
-
看 chunk 切分是否合理
-
看 embedding 是否适合语料
-
调整召回 topK
-
增加 rerank
-
做 query 改写 / 同义词扩展
-
优化知识库质量
我会从四层排查： 第一层是数据层，看文档解析是否干净、切分是否合理； 第二层是向量层，看 embedding 模型和业务语料是否匹配； 第三层是召回层，看 topK、召回策略和 rerank 是否合适； 第四层是生成层，看拼接上下文是否有噪声、Prompt 是否约束了“只基于检索结果回答”。 因为 RAG 出问题不一定是模型的问题，很多时候是前面的数据和召回链路出了偏差。
13）如果模型出现幻觉，怎么处理？
答题方向：
-
限制只基于上下文回答
-
返回无法确认
-
引用来源
-
提高检索质量
幻觉治理不能只靠大模型“自觉”，要靠系统设计。 常见做法包括： 一，Prompt 里约束模型仅基于召回内容回答； 二，没有足够证据时明确返回“未在知识库中找到依据”； 三，强制附来源引用； 四，从前面的召回和重排序上提高证据质量。 项目里“来源追溯”和“避免幻觉”本身就是设计目标之一。
14）本地大模型和大模型 API 两种方案你怎么选？
项目里确实提到了两种问答模块方案。
面试回答可以这样说：
两种方案本质上是“效果、成本、延迟、安全”的取舍。 本地大模型的优点是数据安全更可控，适合敏感场景；缺点是对算力和部署要求更高。 API 方案的优点是接入快、模型能力通常更强，缺点是数据出域风险和长期调用成本更高。 对这个项目来说，因为企业合作场景对数据安全要求高，所以本地化部署更符合落地方向；但从快速验证角度，API 方案也有原型期价值。
15）你们这个项目的难点是什么？
建议答三个点：
-
企业文档格式不统一，解析难
-
检索结果不稳定，需做切分和 rerank
-
企业场景要可信、可追溯、安全
16）这个项目和普通聊天机器人有什么区别？
普通聊天机器人偏开放式对话，而这个项目本质上是“企业私有知识问答系统”。它不是靠模型自由发挥，而是围绕企业知识库做检索增强和证据约束，重点是准确性、可追溯性和安全性，而不是聊天感。
17）这个项目有没有评估过效果？
PPT 没给明确问答指标，所以这里不能硬编准确率。
你应该这么答：
从现有材料看，项目重点展示的是技术路线、业务流程和系统演示；问答系统本身没有看到明确公开的量化评测指标。 所以我在面试里不会虚构准确率，而会从“检索命中质量、答案可追溯、业务可用性”几个维度讲项目价值。
这个答法很加分。因为你没瞎编。
面试官如果追问 rewrite，你要能答什么
1）为什么要做 rewrite？
答：
用户原始问题不一定适合直接检索，比如表述过短、过口语化，或者缺少业务关键词。 所以在检索前先做一次问题改写，把自然语言问题转成更规范、更完整的检索表达，可以提高召回相关性。
2）rewrite 是怎么做的？
你可以答轻一点，别编太复杂：
可以基于规则和大模型两种方式。 规则层面主要做术语补全、同义表达归一； 大模型层面可以把用户问题改写成更适合知识检索的一句话，再送去向量检索。
如果你没真做实现，就不要讲得太细，比如别扯“多路 rewrite 并行召回融合”，那是给自己挖坑。
3）rewrite 有什么风险？
这个答出来很加分：
rewrite 不是越激进越好，改写过头可能会偏离用户原意，导致召回错误。 所以更稳的做法是只做轻量规范化，而不是重写业务语义。
4）rewrite 一定有用吗？
答：
不一定。 对表达清晰、关键词明确的问题，直接检索可能就够了； rewrite 更适合处理口语化、简称、模糊提问和多轮上下文场景。