最近面试了一家AI公司的大模型应用开发岗位，面试官问了很多关于Gemini 1.5的问题。有些问题我答得不错，有些问题答得不太好，回来之后整理了一下，分享给大家。

Gemini 1.5是Google在2024年推出的大模型系列，包括Gemini 1.5 Pro和Gemini 1.5 Flash。它最大的亮点是超长上下文窗口，Pro版本支持100万token的上下文，Flash版本支持100万token（后来扩展到100万以上），而且推理速度快、成本低。

这篇文章就来分享一下我被问到的那些Gemini 1.5相关的面试题，以及我整理的答案和思路。希望对正在准备AI相关面试的朋友有帮助。

问题一：Gemini 1.5的核心技术亮点是什么

这是面试官问的第一个问题，比较基础。

我的回答是：Gemini 1.5最大的技术亮点是超长上下文窗口。Gemini 1.5 Pro支持100万token的上下文，相当于大约75万个英文单词，或者50万左右的中文字。这意味着可以一次性输入整本书、整个代码库、几个小时的视频，模型都能理解和处理。

除了超长上下文，Gemini 1.5还有几个亮点：

  • 多模态能力强，支持文本、图片、音频、视频的混合输入
  • 推理能力强，在复杂推理、代码生成、数学问题上表现优秀
  • Flash版本速度快、成本低，适合大规模应用
  • MoE（混合专家）架构，在保持高性能的同时降低了推理成本

面试官追问：100万token的上下文是怎么实现的？

这个问题我答得不太好。我说了大概是用了改进的注意力机制和位置编码，但具体细节说不清楚。后来查了资料，Gemini 1.5用的是稀疏MoE架构，配合改进的注意力机制（可能是Ring Attention或者类似的分布式注意力），以及RoPE位置编码的外推，实现了超长上下文。具体的技术细节Google没有完全公开，但核心思路是通过模型架构创新和工程优化，让注意力计算的复杂度不会随着上下文长度线性增长。

问题二：Gemini 1.5和GPT-4o有什么区别

这个问题是想考察我对不同大模型的了解程度。

我的回答从几个方面做了对比：

上下文窗口：Gemini 1.5 Pro支持100万token，GPT-4o支持128K token（后来扩展了）。在长上下文方面，Gemini 1.5有明显优势。

多模态：两者都支持多模态，但Gemini 1.5在长视频和长音频的理解上有优势，因为上下文窗口大，可以一次性输入几个小时的视频或音频。GPT-4o在实时交互方面更好，延迟更低。

推理能力：两者在推理能力上差不多，各有胜负。GPT-4o在一些基准测试上略好，Gemini 1.5在长上下文推理和代码理解上有优势。

速度和成本：Gemini 1.5 Flash的速度很快，成本很低，比GPT-4o便宜不少。在对成本敏感的大规模应用场景，Flash版本很有竞争力。

生态系统：GPT-4o背后有OpenAI的生态，包括API、插件、企业服务等，生态更成熟。Gemini 1.5和Google的生态整合，包括Google Workspace、Android、Cloud等，也有自己的优势。

面试官补充问：如果让你选，你会在什么场景用Gemini 1.5，什么场景用GPT-4o？

我的回答是：长文档处理、代码库分析、长视频理解这些需要超长上下文的场景，用Gemini 1.5。实时对话、多模态交互、对延迟要求高的场景，用GPT-4o。成本敏感的大规模应用，用Gemini 1.5 Flash。

问题三：Gemini 1.5的MoE架构是什么，有什么优缺点

这个问题考察的是对模型架构的理解。

我的回答是：MoE（Mixture of Experts，混合专家）是一种模型架构，它不是用一个大的神经网络处理所有输入，而是有多个"专家"网络，每个专家负责处理特定类型的输入。每次推理的时候，只有一部分专家被激活，其他专家不参与计算。

MoE的优点是：

  • 可以在不显著增加推理成本的情况下，扩大模型的参数量。因为每次只有部分专家被激活，推理成本和激活的参数量成正比，而不是和总参数量成正比。
  • 不同的专家可以 specialize 在不同的任务上，提高模型的整体能力。
  • 可以灵活地扩展模型，增加专家数量就能扩大模型容量。

MoE的缺点是：

  • 训练复杂，需要设计好的路由机制（router），决定每个token由哪些专家处理。
  • 推理时需要加载整个模型，虽然计算量小了，但内存占用还是很大。
  • 可能出现负载不均衡的问题，某些专家被过度使用，某些专家几乎不被激活。
  • 工程实现复杂，对硬件和系统优化要求高。

Gemini 1.5用的是稀疏MoE架构，总参数量很大，但每次激活的参数量是可控的，所以推理成本相对较低。

面试官追问：MoE和稠密模型（比如GPT-4）比，哪个更好？

我的回答是：各有优劣。稠密模型实现简单，推理延迟低，适合对延迟要求高的场景。MoE模型可以用更低的推理成本实现更大的模型容量，适合需要大模型能力但对成本敏感的场景。未来的趋势可能是两者结合，或者MoE成为主流，因为大模型的参数量还在增长，纯稠密模型的训练和推理成本太高了。

问题四：怎么用Gemini 1.5做长文档问答

这个问题是考察实际应用能力。

我的回答是：用Gemini 1.5做长文档问答，有两种主要方式。

第一种是直接把整个文档放进上下文。因为Gemini 1.5支持100万token的上下文，大部分文档（甚至整本书）都可以一次性放进去。然后直接提问，模型就能基于文档内容回答。这种方式简单直接，不需要额外的处理，而且模型能理解文档的整体结构和上下文，回答质量高。

第二种是RAG（检索增强生成）。如果文档特别长（超过100万token），或者有大量文档需要处理，可以用RAG的方式：先把文档切块，生成向量索引，提问的时候检索相关的文档块，然后把检索到的内容和问题一起传给模型。Gemini 1.5的长上下文可以容纳更多的检索结果，提高回答的准确性。

我还提到了一些注意事项：

  • 长文档要注意格式，用清晰的标题、段落、列表，帮助模型理解结构
  • 提问要具体，不要问太宽泛的问题
  • 可以让模型先总结文档，再基于总结回答，提高效率
  • 注意token成本，100万token的输入成本不低，要合理使用

面试官追问：直接放上下文和RAG，哪个效果好？

我的回答是：在上下文窗口能容纳的情况下，直接放上下文效果更好，因为模型能看到完整的文档，理解上下文关系。RAG可能会漏掉一些相关信息，因为检索不一定能找到所有相关的文档块。但如果文档超过了上下文窗口，或者文档数量很大，RAG是必要的。最好的方式是两者结合：用RAG检索相关内容，然后把检索到的内容放进长上下文里，让模型综合判断。

问题五：Gemini 1.5 Flash和Pro怎么选

这个问题考察对模型系列的了解。

我的回答是：Flash和Pro的定位不同，根据场景选择。

Gemini 1.5 Pro是旗舰模型，能力最强，支持100万token上下文，适合复杂推理、长文档理解、代码分析、多模态理解等需要高能力的场景。但成本较高，推理速度相对慢一些。

Gemini 1.5 Flash是轻量模型，能力稍弱但速度快、成本低，支持100万token上下文（后来扩展到100万以上），适合大规模应用、实时交互、简单任务处理等对速度和成本敏感的场景。

选择的原则是：

  • 任务复杂、需要高推理能力：用Pro
  • 任务简单、对速度和成本敏感：用Flash
  • 不确定的时候：先用Flash试试，效果不够再用Pro
  • 可以用Flash做预处理和筛选，用Pro做最终的复杂处理，平衡效果和成本

我还提到，Flash的能力其实很强，很多任务用Flash就够了，不一定需要Pro。在实际应用中，应该先评估任务的复杂度，选择最合适的模型，不要盲目用最贵的。

问题六：Gemini 1.5在代码理解方面有什么优势

这个问题和我应聘的岗位相关，因为岗位需要做代码相关的AI应用。

我的回答是：Gemini 1.5在代码理解方面有几个优势：

第一，超长上下文。可以把整个代码库（几十万行代码）一次性放进上下文，模型能理解代码之间的依赖关系、调用关系、整体架构。这是短上下文模型做不到的，短上下文模型只能看单个文件或者几个文件，很难理解整个代码库。

第二，多语言支持。Gemini 1.5支持多种编程语言，包括Python、JavaScript、Java、Go、Rust等，而且能理解不同语言之间的调用关系。

第三，推理能力强。能理解复杂的代码逻辑，追踪数据流向，找出bug，提出优化建议。

第四，支持代码生成和修改。不仅能理解代码，还能生成新代码、修改现有代码、写测试、写文档。

我举了一个例子：可以把整个GitHub仓库放进Gemini 1.5的上下文，然后问它"这个项目的架构是什么样的""某个功能是怎么实现的""这里有个bug，帮我找一下原因"，模型都能给出比较准确的回答。

面试官追问：长上下文做代码理解，有什么挑战？

我的回答是：主要挑战有几个。一是代码的结构化信息，比如函数调用关系、类继承关系，纯文本输入可能丢失一些结构信息，需要用特殊的格式保留。二是代码库很大的时候，虽然100万token能装下，但模型的注意力可能不够精准，有些细节会被忽略。三是成本问题，每次推理都要输入整个代码库，token成本很高。四是实时性，代码库更新之后，需要重新输入，不能增量更新。

问题七：Gemini 1.5的局限性是什么

这个问题考察对模型的全面认识，不是只知道优点。

我的回答是：Gemini 1.5虽然很强，但也有局限性：

第一，长上下文的"中间遗忘"问题。虽然支持100万token，但模型对上下文中间部分的信息 recall 率会下降，也就是"lost in the middle"问题。重要的信息放在开头和结尾效果更好，放在中间可能被忽略。

第二，推理成本高。100万token的输入，即使是Flash版本，成本也不低。在大规模应用中，token成本是一个需要考虑的问题。

第三，实时性不够。长上下文的推理延迟比较高，不适合需要实时响应的场景。

第四，多模态的视频理解还比较初级。虽然支持视频输入，但对复杂视频的理解能力有限，特别是长时间的视频，细节理解不够准确。

第五，幻觉问题。和所有大模型一样，Gemini 1.5也会产生幻觉，特别是在长上下文里，可能会编造一些不存在的信息。

第六，中文能力不如英文。虽然Gemini 1.5支持中文，但在中文理解和生成上，和英文还有差距，特别是在中文文化背景和专业术语上。

面试官对这个回答比较满意，点了点头。

问题八：如果让你基于Gemini 1.5做一个产品，你会做什么

这是一个开放性问题，考察产品思维和创造力。

我的回答是：我会做一个智能代码审查助手。

具体来说，这个产品可以：

  • 接入GitHub/GitLab，自动审查Pull Request
  • 把整个代码库和PR的改动放进Gemini 1.5的长上下文
  • 让模型审查代码质量、找出潜在bug、提出优化建议、检查安全漏洞
  • 生成审查报告，直接评论在PR上
  • 支持自然语言对话，开发者可以问模型"这段代码为什么有问题""怎么改比较好"

这个产品的价值是：提高代码审查的效率和质量，减少人工审查的工作量，帮助团队写出更好的代码。Gemini 1.5的长上下文特别适合这个场景，因为代码审查需要理解整个代码库的上下文，而不只是单个文件。

我还提到了商业模式：可以按团队订阅收费，或者按审查次数收费。先从开源项目和小团队开始，积累口碑，再拓展到中大型企业。

面试官追问：这个产品的技术难点是什么？

我的回答是：一是代码库的结构化处理，怎么把代码转换成模型容易理解的格式，保留依赖关系和调用关系。二是增量更新，代码库每天都在变，不能每次都重新输入整个代码库，需要做增量处理。三是准确性，代码审查不能出错，需要设计好的prompt和验证机制，减少幻觉。四是集成，要和现有的开发工具（GitHub、IDE、CI/CD）无缝集成。

面试后的总结

面试结束之后，我做了一些总结。

第一，对Gemini 1.5的技术细节了解还不够深入，特别是超长上下文的实现原理、MoE架构的细节，这些需要补一补。

第二，对不同大模型的对比还停留在表面，需要更深入地理解各自的技术路线和优劣势。

第三，实际应用经验还不够，很多问题都是理论上的回答，缺乏实际项目经验。需要多做一些项目，积累实战经验。

第四，开放性问题的回答还可以更好，产品思维和技术深度都需要提升。

总的来说，这次面试让我看到了自己的不足，也明确了学习的方向。大模型领域发展很快，需要持续学习，跟上技术的发展。

写在最后

以上就是我面试中被问到的关于Gemini 1.5的问题，以及我的回答和反思。

大模型面试和传统的技术面试不太一样，它不仅考察技术基础，还考察对前沿技术的了解、实际应用能力、产品思维。需要既懂技术原理，又懂实际应用，还要有自己的思考。

如果你也在准备大模型相关的面试，建议：

  • 深入理解主流大模型的技术原理和架构
  • 多动手做项目，积累实际应用经验
  • 关注行业动态，了解最新的技术进展
  • 培养产品思维，思考技术怎么落地成产品
  • 多做模拟面试，锻炼表达能力和应变能力

希望这篇文章能对你有帮助。如果你也有面试经历想分享，欢迎交流。