大模型算法实习面试复盘：RAG、LoRA、强化学习与 Agent 架构解析

一、项目与八股文：从 RAG 到 LoRA，层层深入

Q1：你在项目中用到了 RAG，那 RAG 是如何做 rerank（重排序）的？

面试官提问：'你在简历里提到用 RAG 构建了一个金融问答系统。那么，在 retrieve 阶段拿到 top-k 个文档后，你是怎么做 rerank 的？具体用了什么模型或策略？'

我的回答：

我在项目中构建了面向投资者教育的金融知识问答系统，底层基于 Llama-3-8B + FAISS + Reranker 的三段式 RAG 架构。

首先，用户输入问题后，我会用 bge-large-zh-v1.5 对 query 进行编码，然后在 FAISS 中进行近似最近邻搜索（ANN），召回 top-50 的候选文档片段（chunk）。但这 50 个结果只是基于向量相似度（cosine similarity）的粗排，存在两个问题：

语义漂移：比如用户问'科创板上市条件'，可能召回一堆关于'创业板'的文档；
细粒度相关性不足：有些文档虽然整体主题相关，但关键信息缺失。

因此，我们引入了 Cross-Encoder Reranker 做精排。具体来说，使用了 bge-reranker-v2-m3 模型（这是智源开源的中文重排序模型），它会对每个 (query, passage) 对进行联合编码，输出一个相关性分数。

# 伪代码示意
reranker = BGEM3Reranker(model_name="BAAI/bge-reranker-v2-m3")
scores = reranker.compute_score([(query, doc) for doc in retrieved_docs])
reranked_docs = [doc for _, doc in sorted(zip(scores, retrieved_docs), reverse=True)]
final_top_k = reranked_docs[:5]

这个 reranker 虽然计算开销比双塔模型大（因为要对每个 pair 做 full attention），但在金融这种高精度场景下，准确率提升远大于延迟成本。我们在测试集上观察到 MRR@5 提升了约 18%。

此外，我们也尝试过 ColBERTv2 这种 late interaction 架构，它在保持较高精度的同时推理速度更快，但由于部署复杂度较高（需要维护 token-level embeddings），最终选择了更成熟的 cross-encoder 方案。

面试官追问：'如果 reranker 输出的分数都很接近，比如都在 0.85~0.90 之间，你怎么判断哪个更相关？有没有考虑过集成或者不确定性校准？'

这个问题很关键！我们在实际部署时确实遇到过'分数扎堆'现象。我们的应对策略有三点：

引入多样性惩罚：在 rerank 后再加一层 MMR（Maximal Marginal Relevance），避免 top-k 结果内容高度重复；
置信度阈值过滤：如果最高分 < 0.7，直接返回'未找到可靠答案'，避免幻觉；
多模型投票：在离线阶段，我们并行跑 bge-reranker 和 Cohere Rerank API，取交集或加权平均，提升鲁棒性。

未来我们也计划引入 Uncertainty-aware Reranking，比如用 Monte Carlo Dropout 估计 reranker 的预测不确定性，对高不确定样本降权或触发人工审核。

Q2：LoRA 参数计算——给你一个 7B 模型，优化器这块如何分配显存？

面试官提问：'假设你要用 LoRA 微调一个 7B 的 LLM（比如 Llama-3-7B），只微调 attention 的 q_proj 和 v_proj，rank=64。请你估算一下可训练参数量，并说明在 AdamW 优化器下，显存如何分配？'

我的回答：

好的，我们一步步来算。

首先，Llama-3-7B 的结构大致是：

层数（layers）：32
注意力头数（n_heads）：32
hidden_size（d_model）：4096

在标准 LoRA 设置中，我们通常只对 q_proj 和 v_proj 注入低秩矩阵。每个 linear 层原本是 d_model × d_model（因为 q 和 v 的输出维度也是 d_model）。

对于一个 linear 层，LoRA 会将其分解为：

原始权重 W（冻结）
可训练部分：A ∈ ℝ^(d_model × r)，B ∈ ℝ^(r × d_model)

所以每个 LoRA 模块的参数量是： d_model * r + r * d_model = 2 * d_model * r

代入数值：

d_model = 4096
r = 64
每层有 2 个 LoRA（q 和 v）
总层数 = 32

总可训练参数量 = 32 layers × 2 (q+v) × 2 × 4096 × 64 ≈ 32 × 2 × 2 × 4096 × 64

计算：

4096 × 64 = 262,144
×2 = 524,288（每层每个 proj）
×2 = 1,048,576（每层 q+v）
×32 = 33,554,432 ≈ 33.5M 参数

对比原始 7B 模型（70 亿参数），可训练参数仅占约 0.48%，非常高效。

接下来是 优化器显存分配。以 AdamW 为例，每个可训练参数需要存储：

参数本身（fp16 或 bf16）：2 bytes
一阶动量（momentum）：通常 fp32，4 bytes
二阶动量（variance）：fp32，4 bytes

所以每个参数共需 2 + 4 + 4 = 10 bytes

总优化器显存 ≈ 33.5M × 10 bytes ≈ 335 MB

再加上：

梯度（fp16）：33.5M × 2 = 67 MB
参数副本（用于 checkpointing 或通信）：约 67 MB

总计可训练部分显存 ≈ 335 + 67 + 67 ≈ 470 MB

而前向/反向传播的激活值（activations）才是大头。对于 7B 模型，batch_size=1, seq_len=2048 时，激活显存可能高达 10~15 GB，因此我们通常用 Gradient Checkpointing 来 trade time for memory。

面试官追问：'如果显存只有 24G，你如何配置 batch size 和 gradient accumulation？会不会考虑 GaLore 或 DoRA 这些新方法？'

这是个很好的工程问题。

在 24G 显存下，我们实测 Llama-3-7B + LoRA（r=64）：

单卡最大 batch_size ≈ 2（seq_len=2048）
所以我们会设 global_batch_size=32，用 gradient accumulation steps=16

至于 GaLore（Gradient Low-Rank Projection）和 DoRA（Weight-Decomposed Low-Rank Adaptation），我们确实在关注：

GaLore：它不引入额外参数，而是直接在优化器层面做梯度低秩投影，理论上更省显存，但收敛稳定性在长序列任务上还有待验证；
DoRA：将权重分解为 magnitude + direction，能更好地保留预训练知识，在数学推理任务上表现优异。

但在金融场景，稳定性和可解释性优先于 SOTA，所以我们目前仍以标准 LoRA 为主，但会在 A/B 测试中逐步引入 DoRA。

二、强化学习专题：从基础算法到 GRPO 异常处理

Q3：了解强化学习的什么算法？强化学习最新的 PO 算法有哪些？

面试官提问：'你简历里写了熟悉强化学习。能说说你知道哪些 RL 算法？特别是最近一年，Policy Optimization（策略优化）方向有什么新进展？'

我的回答：

我从经典到前沿梳理一下。

经典算法：

Value-based：DQN、Double DQN、Dueling DQN —— 适合离散动作空间；
Policy-based：REINFORCE（蒙特卡洛策略梯度）；
Actor-Critic：A2C、A3C、PPO（Proximal Policy Optimization）—— 目前最稳定的 on-policy 算法；
Off-policy：DDPG、TD3、SAC（Soft Actor-Critic）—— 连续控制的标杆。

在大模型时代，PPO 成为 LLM RLHF 的默认选择，因为它通过 clipped probability ratio 限制策略更新步长，避免训练崩溃。

近两年的 PO 新算法（2023–2026）：

DPO（Direct Preference Optimization）
- 核心思想：绕过 reward modeling，直接用偏好数据优化策略。
- 优势：训练更稳定，无需采样 - 奖励拟合 - 策略更新的循环。
- 缺点：对偏好数据质量敏感。
IPO（Identity Preference Optimization）
- DPO 的改进版，用 MSE loss 替代 logistic loss，缓解 overfitting。
KTO（Kahneman-Tversky Optimization）
- 引入行为经济学中的损失厌恶心理，对正负样本不对称加权。
GRPO（Group Relative Policy Optimization）
- 重点！ 这是 2024 年 Google 提出的新算法，专为 group-wise preference 设计。
- 传统 DPO/PPO 只处理 pairwise（A > B），而 GRPO 可处理一组响应的相对排序，比如 [A, B, C] 中 A 最好，C 最差。
- 在代码生成、多轮对话等任务中效果显著。
ORPO（Odds Ratio Preference Optimization）
- 将语言建模 loss 与偏好 loss 联合优化，提升生成 fluency。

面试官追问：'那你详细说说 GRPO 的 loss 形式？它和 PPO 有什么本质区别？'

GRPO 的核心在于 group-level 的 log-odds ratio。

假设我们有一个 prompt，生成了 K 个 responses：{y₁, y₂, …, yₖ}，并有人工标注的排序（或自动评分）。GRPO 定义每个 response 的优势为：

$$ A(y_i) = \log \frac{p_\theta(y_i|x)}{\frac{1}{K-1} \sum_{j \neq i} p_\theta(y_j|x)} $$

然后 loss 是：

$$ \mathcal{L}{GRPO} = -\frac{1}{K} \sum{i=1}^K \sigma(s_i) \cdot A(y_i) $$

其中 $s_i$ 是第 i 个 response 的标量得分（比如人工打分），σ 是 sigmoid，将得分映射为'被选中概率'。

与 PPO 的区别：

PPO 需要显式 reward model，且每次只比较两个样本；
GRPO 端到端利用 group 信息，无需 reward model，且能捕捉更细粒度的偏好差异；
GRPO 更适合 多候选生成 + 排序 场景，比如金融报告生成中选出最优表述。

Q4：GRPO 训练时，如果一组 score 都是 0 或 1，怎么办？

面试官提问：'假设你在用 GRPO 训练一个金融摘要生成模型，但某一批数据的 human score 全是 0，或者全是 1。这时候 loss 会怎样？你怎么处理？'

我的回答：

这是个非常实际的问题！在真实标注中，确实会出现 label homogeneity（标签同质化），比如：

所有生成结果都很差 → 全 0；
所有结果都符合要求 → 全 1。

此时，GRPO 的 loss 会出现梯度消失或爆炸。

原因在于：当所有 $s_i$ 相同，σ($s_i$) 也相同，那么 loss 中的 $A(y_i)$ 虽然有差异，但乘上几乎相同的权重后，有效梯度信号极弱。

我们的解决方案有三层：

1. 数据层面：拒绝全同质 batch

在 dataloader 中加入过滤逻辑：若 batch 内 score 的方差 < ε（如 0.1），则跳过该 batch 或重新采样。
或者强制每个 batch 至少包含一个高分和一个低分样本（stratified sampling）。

2. Loss 层面：引入 baseline normalization

对 $A(y_i)$ 做 batch-level 标准化： $$ \hat{A}(y_i) = \frac{A(y_i) - \mu_A}{\sigma_A + \epsilon} $$ 即使 σ($s_i$) 相同，标准化后的 advantage 仍有区分度。

3. 训练策略：混合 GRPO + SFT

在早期 warm-up 阶段，先用 SFT（Supervised Fine-Tuning）稳定模型；
当收集到足够多样化的偏好数据后，再切换到 GRPO；
或者采用 curriculum learning：先训 easy samples（score 差异大），再训 hard samples。

补充：我们还在探索 uncertainty-weighted GRPO —— 如果 human score 置信度低（比如多个标注者分歧大），就降低该 batch 的 loss 权重。

三、Agent 架构设计：从模块拆解到金融场景落地

Q5：Agent 一般由哪几大部分组成？

面试官提问：'现在大家都在做 Agent。你觉得一个完整的 LLM Agent 应该包含哪些核心模块？'

我的回答：

一个 production-ready 的 LLM Agent 通常包含以下 五大核心组件：

1. Memory（记忆）

短期记忆：当前对话上下文（context window）；
长期记忆：向量数据库存储的历史交互、用户画像、外部知识；
工作记忆：类似 scratchpad，用于中间推理步骤（如 ReAct 中的 Thought-Action-Observation）。

2. Planning（规划）

将复杂任务分解为子目标（task decomposition）；
支持回溯（backtracking）和重规划（re-planning）；
常用方法：Tree-of-Thoughts、Plan-and-Execute。

3. Tool Use（工具调用）

能调用外部 API（如股票行情、财报查询、计算器）；
需要 robust 的 function calling schema（如 OpenAI 的 JSON mode）；
在金融场景，工具包括：同花顺 API、Wind、Python 代码解释器等。

4. Reasoning（推理）

Chain-of-Thought（CoT）、Self-Consistency、Program-Aided Language Models（PAL）；
对于金融分析，常结合 symbolic reasoning（如规则引擎）与 neural reasoning。

5. Reflection / Self-Correction（反思）

生成后自我评估（self-critique）；
若发现错误，触发修正 loop；
可结合 verifier 模型或 rule-based checker。

面试官追问：'那在金融场景，这些模块有什么特殊要求？'

非常关键！金融 Agent 必须满足：

准确性 > 创造性：不能'编造'财报数据；
可追溯性：每个结论必须附带数据来源（如'根据 2025 年 Q3 财报…'）；
合规性：避免给出投资建议（需 disclaimer）；
实时性：股价、新闻需分钟级更新。

因此，我们的 memory 模块会对接实时行情流，tool use 严格限定在授权 API 范围内，reasoning 模块会插入 fact-checking step。

Q6：什么是 Agentic RL？它和传统 RL 有什么不同？

面试官提问：'最近有篇论文叫 'Agentic Reinforcement Learning'，你了解吗？它解决了什么问题？'

我的回答：

Agentic RL（Agentic Reinforcement Learning）是 2025 年由 DeepMind 和 Stanford 联合提出的新范式，核心思想是：让 Agent 在环境中通过自主探索、工具使用和长期规划来学习，而非被动接受 state-action-reward 三元组。

与传统 RL 的区别：

维度	传统 RL	Agentic RL
状态空间	固定、低维（如 Atari 像素）	动态、高维、符号 + 感知混合
动作空间	预定义离散/连续动作	自主生成工具调用序列（如 `search("AAPL") → get_price() → calculate_pe()`）
奖励信号	环境直接提供	稀疏、延迟，甚至需 self-supervised reward（如 correctness verifier）
学习目标	最大化累计 reward	实现复杂 goal（如'分析特斯拉未来三年盈利能力'）

在金融场景，Agentic RL 特别适合：

自动化投研：Agent 自主爬取数据、运行财务模型、生成报告；
交易策略探索：在模拟环境中试错，避免实盘风险。

关键技术挑战包括：

Credit Assignment：如何将最终 report 质量归因到中间 tool call？
Exploration vs Exploitation：在无限工具组合中高效探索；
Safety：防止 Agent 调用危险操作（如高频交易 API）。

目前主流方案是结合 LLM as policy + Monte Carlo Tree Search (MCTS) 做 planning，再用 GRPO 或 DPO 做 offline policy improvement。

Q7：GUI Agent 和 Code Agent 有什么区别？各自的技术难点？

面试官提问：'你提到了工具调用。那 GUI Agent（比如操作网页）和 Code Agent（比如写 Python）在技术实现上有什么不同？'

我的回答：

这是两个热门但差异巨大的方向。

Code Agent

目标：生成可执行、正确、高效的代码；
输入：自然语言需求（如'画一个 AAPL 近一年股价走势图'）；
输出：Python/SQL/JS 代码；
核心技术：
- Code LLM（如 CodeLlama、StarCoder2）；
- Execution-based feedback（运行代码看是否报错）；
- Unit test generation（自动生成测试用例）；
难点：
- 环境依赖：代码能否运行取决于库版本、数据格式；
- 安全性：防止生成恶意代码（如 os.system("rm -rf /")）；
- 调试能力：能否根据 error trace 自我修复。

GUI Agent

目标：在图形界面（网页/App）中完成任务，如'在同花顺 App 里查看宁德时代研报'；
输入：屏幕截图 + DOM 树 + 用户指令；
输出：UI 操作序列（click, type, scroll…）；
核心技术：
- Vision-Language Model（如 Qwen-VL）理解 UI 元素；
- Action space discretization（将像素坐标映射到可点击区域）；
- Memory-augmented navigation（记住页面结构）；
难点：
- UI 多样性：不同 App 布局差异巨大；
- 动态元素：弹窗、加载动画干扰识别；
- 鲁棒性：轻微 UI 变更导致 agent 失效。

在金融场景：

Code Agent 用于量化策略回测、数据可视化；
GUI Agent 用于自动化操作内部投研系统（节省分析师时间）。

我们目前更侧重 Code Agent，因为 GUI 操作涉及合规和安全风险更高。

四、AI for Software Engineering（AI4SE）：大模型如何改变开发范式？

Q8：了解软件工程相关的吗？比如 AI for SE？

面试官提问：'你们做 Agent，肯定要写很多工程代码。你了解 AI for Software Engineering 吗？比如 GitHub Copilot 背后的技术？'

我的回答：

当然！AI4SE 是当前大模型落地最成功的领域之一。

核心方向包括：

1. Code Generation

模型：Codex、CodeLlama、DeepSeek-Coder；
技术：Fill-in-the-middle（FIM）、infilling、multi-file context；
挑战：跨文件一致性、API 使用正确性。

2. Code Completion & Autocomplete

实时预测下一行代码；
需要 low-latency inference（<200ms）；

3. Code Review & Bug Detection

用 LLM 分析 PR diff，指出潜在 bug 或风格问题；
结合 static analysis tools（如 SonarQube）提升精度。

4. Test Generation

自动生成 unit tests / integration tests；
评估指标：line coverage、mutation score。

5. Documentation Generation

从 code 生成 docstring，或从 doc 生成 example code。

特别地，在金融系统开发中，我们关注：

可审计性：所有 AI 生成代码必须可追溯、可 review；
确定性：禁止使用随机性高的生成（如 np.random 无 seed）；
性能约束：生成的代码必须满足 latency/throughput SLA。

我们正在探索 Agent-driven DevOps —— 比如一个 Agent 能自动：

读取 Jira ticket；
生成代码 + 单元测试；
提交 PR；
根据 CI 反馈 self-debug。

这需要强大的 code understanding + execution + reflection 能力。

五、反问环节：聚焦业务方向

我提问：'请问团队目前在金融大模型方向的具体业务重点是什么？是偏 research 还是偏 engineering？'

面试官回答：

我们目前全力投入 金融智能 Agent 的产品化，属于 强工程导向。具体包括：

构建面向个人投资者的 'AI 投顾助手'；
为机构客户开发 '智能研报生成与问答系统'；
探索 Agentic Workflow 在量化策略研发中的应用。

团队需要能快速落地、解决实际问题的同学，不要纯 paper 复现。

结语：给后来者的建议

这场面试让我深刻意识到：大模型岗位已从'调参炼丹'转向'系统构建 + 领域深耕'。

如果你想冲击金融科技公司的算法岗，建议：

夯实基础：RAG、LoRA、RLHF 必须能手推公式、估算显存；
动手做项目：哪怕是一个 mini financial agent，也要跑通 data → train → deploy 全链路；
理解金融业务：知道 PE、PB、ROE 是什么，比背 100 个 transformer tricks 更重要；
关注 Agentic AI：这是未来 2–3 年的核心战场。