AI大模型原理和应用面试题速记通关版 | 面试刷题 mianshiya.com - 编程导航

请解释大模型微调(Fine-tuning)的原理，并说明在什么业务场景下需要微调而不是直接使用基础模型？

微调的本质是参数高效迁移，不是从头训练。大模型已经在海量通用语料上学到了语言规律和世界知识，微调是在这个基础上，用特定领域的数据去调整模型参数，让它适应新任务。

1）你拿到一个预训练好的大模型，比如 LLaMA 或 Qwen，它的“常识”已经很完整。但如果你要做金融研报生成，它可能写得不够专业。这时候直接 prompt 工程搞不定，因为领域术语、行文逻辑差异太大。

2）微调就是拿一批金融报告数据，用有监督的方式继续训练。比如输入“某公司营收增长30%”，让模型输出对应的研报段落。反向传播会更新权重，让模型在该任务上表现更好。

3）关键在于，并不是所有层都要重训。现在很多做法是只微调部分参数，比如 LoRA（Low-Rank Adaptation），冻结原模型权重，只训练低秩矩阵。这样显存占用少，训练快，适合业务迭代。

需要微调的场景通常是：

输出格式/风格强约束，比如法律文书、医疗诊断记录
领域知识密集，基础模型没见过的专业术语体系
企业私有数据不能走 API，必须本地部署并定制

如果只是简单问答、摘要生成，且对表达风格要求不高，那其实用提示词+RAG就够了。微调成本高，周期长，真要上得想清楚是不是非用不可。

RAG 的完整流程是怎么样的？

RAG 的流程其实就三步：准备数据、查资料、生成答案。整个过程让大模型在回答前，先去“翻书”找依据。

1）数据准备阶段，先把外部知识库的文档切片，比如把 PDF 或数据库表结构说明拆成一段段文本块。接着用 embedding 模型给每一块转成向量，存进向量数据库，像 Milvus 或 Pinecone 这类工具干的就是这事。

2）用户提问时，系统不会直接扔给大模型。而是先把问题也转成向量，去向量库里做相似度搜索，找出最相关的几个文本块。这一步很关键，决定了模型能“看到”哪些背景知识。

3）最后，把这些检索到的文本块拼接成提示词，连同原问题一起喂给大模型。模型基于这些上下文生成答案，而不是靠记忆瞎编。这样出来的回答有据可查，幻觉少。

这个流程里，embedding 模型和向量检索的质量直接决定效果。如果检索错了，后面再强的模型也搞不定。常见坑是文本分块不合理，比如按固定字符切，把一个完整概念切碎了，导致查不准。

什么自查询？为什么在 RAG 中需要自查询？

自查询其实是让模型自己生成查询条件，去检索它需要的信息。比如你问“苹果最新财报怎么样”，模型不会直接回答，而是先拆解问题，生成像“苹果 2024 年 Q2 营收、利润、同比增长”这样的检索关键词，再拿这些词去查文档。

这在 RAG 里特别关键，因为原始问题往往太笼统或包含多个维度。直接拿原问题去搜，召回的内容可能不精准。自查询相当于加了一层智能路由，把复杂问题翻译成适合检索的结构化查询语句。

1）能处理时间范围过滤，比如“去年销售额最高的产品”会被转成带时间约束的查询
2）支持属性筛选，“便宜的安卓手机”会拆成“价格低于 2000 元、操作系统为 Android”
3）适配向量库的元数据检索，比如用 Chroma 或 Pinecone 的 where 条件过滤

代码上一般用 LLM 接一个提示模板：

▼
java
复制代码
String prompt = "根据用户问题生成检索查询语句: " + userQuestion;
List<String> queries = llm.generate(prompt);
List<Document> results = vectorStore.search(queries);

整个流程像是给 RAG 装了个“理解大脑”，先把人话转化成机器能高效检索的指令，避免压根不经过语义解析就硬搜。

什么提示压缩？为什么在 RAG 中需要提示压缩？

提示压缩其实就是把 RAG 中过长的上下文输入给“瘦身”。你想想，大模型的上下文长度是有限的，比如 32K 或 128K，但检索回来的文档片段一多，加上原始问题和模板，很容易就超了。

1）最直接的问题就是 token 数爆掉，请求直接被拒，压根不经过模型推理。
2）就算没超，长上下文推理成本高，响应慢，延迟上去用户体验就差了。
3）而且很多检索出的内容其实跟问题关系不大，纯属噪音，反而干扰生成质量。

所以得做提示压缩，把那些冗余信息、重复段落、无关句子给剔除或简化。不是简单删减，而是保留关键事实和语义，让输入更紧凑高效。

常见的做法有几种：

用小模型先做一轮重排序或摘要，比如用 BGE 或 Cohere reranker 挑最相关的 top-k。
在 prompt 组装时加逻辑，只保留高分 chunk，甚至对每个 chunk 做句子级裁剪。
也可以引入类似 HyDE 的思路，先生成假设答案再反向匹配，过滤低相关度内容。

代码上没啥复杂语法，核心是控制组装后的总 token 数：

▼
python
复制代码
# 伪代码示意
context = "\n".join([chunk["text"] for chunk in relevant_chunks[:3]])  # 限制数量
prompt = f"基于以下内容回答：\n{context}\n\n问题：{query}"

要不要压缩，其实看场景。如果检索精度高、返回少，可能不需要。但面对海量文档库，比如用在企业知识库搜寻，就得靠这招扛住长上下文压力。