LarkLex RAG 系统项目复盘：从架构设计到面试问答

发表于 更新于 分类于 阅读次数： Changyan：

“我们做了一个面向政企场景的 RAG 智能问答平台，内部代号 LarkLex。这个项目是团队 2024 年并行推进的两大目标之一——另一个是容器平台改造；LarkLex 的定位是私有 LLM 编排（Private LLM orchestration），目标是做成开源产品。我负责它从架构设计到部署运维…

适用岗位：运维工程师 / 技术支持工程师 / AI 运维工程师 / DevOps 工程师（AI运维岗必考）

一、项目速览

“我们做了一个面向政企场景的 RAG 智能问答平台，内部代号 LarkLex。这个项目是团队 2024 年并行推进的两大目标之一——另一个是容器平台改造；LarkLex 的定位是私有 LLM 编排（Private LLM orchestration），目标是做成开源产品。我负责它从架构设计到部署运维的全链路。简单说三件事：第一，设计了 PostgreSQL、Neo4j、向量库的协同架构——PG 管结构化业务数据，Neo4j 管实体关系图谱，向量库管语义检索，各自干最擅长的事，落地场景是给 ITSM 的工单语义搜索接口；第二，搭了一条文档切分、embedding 生成、混合检索、Prompt 生成的 RAG 流水线，用 nomic-embed-text 做向量化，通过动态模板和 Few-shot 把 LLM 输出与业务需求的匹配度从 68% 提到 92%；第三，搭了多模型评估框架，用 Ollama 本地模型加 HuggingFace 云端 API 同时对比 7 种大模型，最后基于开源底座定制、自研上层组件，资源开销比完整方案省了约三分之一。我岗位是 Linux 系统工程师，算法部分用的是开源预训练模型，我的核心贡献是工程落地、部署运维和评测体系。”

一句话版： 给业务系统做了一个”能听懂业务话、能查库、能回答”的 RAG 问答系统——三种数据库各司其职，7 个模型横向对比，最后用轻量自研方案落地。

按岗位微调收尾句（说给不同面试官听）：

  • 运维/技术支持岗：补一句”整个系统全是 Docker 部署，qdrant、open-webui、vllm 都是 docker-compose 起的，数据卷持久化、健康检查、资源调优都是我在做”。
  • AI运维岗：补一句”模型侧我用 Ollama 跑 embedding 和小模型、vLLM CPU 版跑本地推理，HuggingFace API 跑云端大模型做对比，模型评测和调度是我主导的”。
  • DevOps岗：补一句”我还参与了 LangChain/LangGraph、Quivr、FastGPT、Dify 等框架的评估对比，最终在开源底座上定制、自研上层组件，按资源估算省了约 32% 的云开销”。

二、项目背景（业务背景、为什么做、约束）

组织背景（一手资料，面试讲”背景/团队”时用）

  • 2024 年团队目标原文：”产品：容器平台改造，代码可复用，最终成为平台产品；GenAI - generative AI > LarkLex：Open Source、Private LLM orchestration（私有 LLM 编排）”。
  • LarkLex 定位是私有 LLM 编排平台，目标是开源产品——所以代码组织、文档、部署方式都按可复用、可开源的标准做（GitLab 仓库、Markdown 文档驱动）。
  • 团队同时在调研 AIOps 方向（docs/240117_aiops_survey.md：调研 opni、logai、codefuse-chatbot 等开源工具，其中 codefuse-chatbot 被标注为”与 LarkLex 同类：RAG + Tool Learning”）——说明 LarkLex 对标的是开源 RAG / 智能问答平台。
  • 团队理念：最小计算单元（Container 作为最小单元）、IaC（一切皆代码进 Git）、GitOps、CI/CD 对所有服务版本控制、HA + LB。这些理念直接决定了 LarkLex 的交付方式：所有部署配置、数据集、评测记录全部代码化进 Git，不在服务器上手动改配置。

业务背景

  • 公司面向政企客户，内部积累了大量业务资料：长文本（规章制度、项目文档、操作手册、合同条款）和结构化数据（业务系统里的项目、人员、供应商、部门等表）。
  • 业务人员和客服经常要快速从这些资料里找答案，传统方案是数据库 LIKE 查询或关键词搜索，存在两个硬伤：① 语义相关但字面不同的问法搜不到（比如问”跟哪家供应商合作最久”，文档里写的是”合作关系始于2019年”）；② 跨文档、跨表的问题要人工翻很久。
  • 领导层希望做一个内部知识问答系统，让业务人员用自然语言提问，系统自动检索资料并生成带依据的回答。
  • LarkLex 是平台产品而非一次性工具，客户场景覆盖智能工单（银行客户）、员工培训助手（餐饮企业）、智能文档平台（医疗企业）等（larklex 仓库产品设计文档中有这些 Use Case），所以架构要可复用、可扩展。

为什么做（动机拆解）

  1. 检索能力不足：关键词检索对长文本命中率低，答案经常被淹没在大段文档里。
  2. 响应慢：人工翻文档耗时，客户咨询等不起。
  3. 数据合规：业务数据不能出内网，不能把敏感数据直接调外部云 API 处理 → 必须本地推理能力（Ollama / vLLM 本地部署）。
  4. 模型选型需求：团队想对比多个开源大模型，需要一套统一的评测体系，而不是各模型各测各的。
  5. 平台化与开源目标：LarkLex 的定位是私有 LLM 编排平台产品并开源，需要可复用的架构、统一的模型调度与评测能力，而不是单点脚本——这也是自研调度层和评测框架的出发点。

约束（面试时主动讲，显真实）

  • 服务器资源有限，没有稳定可用的 GPU → 推理走 CPU（vLLM CPU 版跑 Llama-3.2-1B，Ollama 跑小模型和 embedding）。
  • 数据不出内网（合规硬约束）→ 本地模型优先，云端 API 只用于对比评测。
  • 业务方要求快速出 POC（约 1-2 个月出验证版），倒逼方案要轻。
  • 要兼容多种模型 → 需要调度层和评测框架，而不是写死单个模型。
  • 团队理念约束：IaC / GitOps / 一切皆代码进 Git——部署配置、数据集、评测记录都要代码化进 Git 管理，交付必须走 CI/CD。
  • 人力分摊：同一团队并行推进容器平台改造与 LarkLex，Q4 排期里我的投入配比是 **AI 10%、DevOps 90%**（larklex 仓库 240918_q4_schedule.md Worker 表）——AI 侧不能投入大量人力，选型必须轻、复用容器平台的部署能力。

我的角色定位（防御点，主动说）

“我的岗位是 Linux 系统工程师。LarkLex 是团队 2024 年并行推进的私有 LLM 编排产品，AIGC 方向由团队同事、团队同事牵头，我的角色是工程支撑和落地：数据库协同架构的实施、Python 检索流水线、模型本地化部署、评测系统开发，以及 Q4 与容器平台配套的高可用、CI/CD、监控工作。模型本身用的是开源预训练模型，训练和微调不是我做的，我负责把它工程化落地。”

三、完成情况（技术架构：数据流/组件/选型理由/遇到的坑）

3.1 产品定位与事实架构（仓库一手材料，先讲这个）

产品定位（README + docs/240619_larklexSum.md）

  • LarkLex 是面向神州业务的 AI 平台产品（BaaS 后端即服务），目标原文：”通过 BaaS 后端即服务的灵活特性，满足具备神州业务特征的需求，为公司各业务线提供强有力的 AI 产品支持”。
  • 核心功能六大模块：① Models Orchestration 模型调度（LLM / Embedding / Re-rank 模型编排、Prompt engineering、Chunk splitting 切片、VectorStore 连接）② 知识库管理 ③ 工作流 ④ 用户管理 ⑤ Agent ⑥ API Provider（给 ITSM 提供工单语义搜索 API）。
  • 落地场景：银行客户工单语义搜索、ITSM 知识问答等；scripts/data/ 下有 bank/express/personal/telecom 的 CSV 演示数据。

技术架构（docs/240509_larklex_reasonable.md + docs/20240708_larklex_deploy.md）

  • 前端：Dify-based（知识管理 / RAG 引擎 / 工作流 / Prompt IDE / Agent / BaaS / SSO 认证）。
  • 后端：nginx（可接 API 网关）+ flask 或 fastAPI + langchain + celery（配 redis 的调度系统）。
  • 文档处理：自研 document_loader + custom_splitter（文档加载与自定义切片）。
  • 向量库（平台侧）：Supabase（内置 PostgreSQL + pgvector）——supabase start 启动，建 dify 库并启用 uuid-ossp 扩展；Dify 默认是 weaviate，团队写代码把它换成 Supabase（docs/240517_dify_vdb.md 有实际替换代码）。
  • 向量库（工单相似度接口侧）：Qdrant——银行客户相似度接口 pipeline 直接调用 qdrant.similarity_search_with_score(query, k)，并有 Qdrant 重建表（清空数据）、快照备份文档；配套有 qdrant 的 docker-compose。
  • 部署：docker-compose.middleware.yaml 起中间件；环境要求 node>=20.11.1、python>=3.10、docker>=19.03。
  • 性能验证（docs/240416_stress_test.md）：JMeter 模拟 10 用户并发压”相似度查询接口”，请求数据是 ITSM 工单内容（邮箱密码修改、离职人员、故障描述等），topK=5。
  • 框架评估痕迹：docs/240715_neo4jCombineLangchain.md（Neo4j+LangChain 结合原型）、docs/240501_fastGPT.md、docs/240416_quivr_front_dev_log.md、docs/20231130_quivr_design.md（Quivr 设计与拆解）、docs/240517_dify_vdb.md（Dify 向量库选型）——印证”对多个框架做过评估”。
  • 模型与脚本：docs/240731_upgradeOllama.md（Ollama 模型升级记录，多模型本地部署佐证）；scripts/ 下有 Api、chat_with_image、chat_with_search、Dify、Larklex、llm-webui、meeting-reporter-demo、neo4jdemo、neo4j_prototype、resume-poc、similarity、Ticketing、Yum、Roche 等自研/实验目录。

3.3 整体架构与数据流（检索链路，面试按此讲）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
【离线流水线（入库侧）】
业务文档/ITSM工单 ──→ 自研 document_loader + custom_splitter 切片
                    └─→ embedding（Ollama 本地）──→ 向量库
                          （工单相似度接口：Qdrant；平台侧：Supabase/pgvector）
结构化数据 ──→ PostgreSQL（原始数据/元数据/评测记录，tsvector 全文检索兜底）
业务关系数据 ──→ 实体/关系抽取 ──→ Neo4j（Cypher 多跳查询，LangChain 集成原型）

【在线链路（查询侧）】
用户问题 ──→ 意图解析/实体抽取
              ├─ 语义检索：向量库 top-k（工单相似度接口 topK=5，问答链路 top-k=20）
              ├─ 精确检索：PostgreSQL 全文检索 / BM25（兜底专有名词、编号）
              └─ 图谱查询：Neo4j Cypher 多跳关系推理（关系类问题）
                   ↓
         RRF 融合 + 重排（取 top-5 给 LLM）
                   ↓
         动态模板组装 Prompt + 动态 Few-shot 示例（Dify Prompt IDE / 后端 langchain）
                   ↓
         LLM 调度层：Models Orchestration（Ollama 本地 / vLLM CPU / HuggingFace API）
                   ↓
         输出校验（格式/必含字段，失败重生成一次）──→ 返回 + 评测数据落库

3.4 组件清单（带参数，面试讲得出细节）

组件 职责 关键参数/细节
Dify（前端/底座） 知识管理 / RAG 引擎 / 工作流 / Prompt IDE / Agent / BaaS / SSO 基于开源 Dify 定制；前端部分由前端同事负责
PostgreSQL 业务主库：原始数据、chunk 原文、元数据、评测记录 tsvector 全文检索兜底；分钟级增量同步给 Neo4j/向量库
Supabase（PostgreSQL+pgvector） 平台侧生产 VectorDB（按部署文档） supabase start 启动；建 dify 库 + uuid-ossp 扩展；Dify 默认 weaviate，团队改代码切到 supabase（240517_dify_vdb.md）
Qdrant 工单相似度接口向量库（银行客户） qdrant.similarity_search_with_score(query, k)；配套 docker-compose（6333/6334）；HNSW、Cosine；重建表/快照备份有专门文档
Neo4j 知识图谱 7474/7687 端口；Cypher 参数化查询；与 LangChain 结合原型（240715_neo4jCombineLangchain.md）；scripts/neo4j_prototype、neo4jdemo
nomic-embed-text 文本向量化 768 维，上下文 8192 tokens，Ollama 本地跑；偏英文，中文一般 → 混合检索弥补
document_loader + custom_splitter 自研文档加载与自定义切片 按文档结构切片 + overlap；chunk 500-800 tokens
nginx 反向代理/API 网关入口 可接 API 网关（kong）
flask / fastAPI 后端 API 服务 Python；与 langchain 编排
langchain 后端编排框架 检索 / Model I/O / Document I/O / Agent 模块
celery + redis 异步调度系统 长任务（文档处理、批量 embedding）入队；失败重试
工单相似度 API API Provider：给 ITSM 提供相似度查询 payload=工单内容，topK=5；JMeter 10 并发压测（240416_stress_test.md）；demo 硬件要求 8 核/16G/40G
LLM 调度层 模型路由/并发/重试 Models Orchestration（LLM/Embedding/Re-rank 编排）；并发队列+限流+超时+重试；temperature 问答类 0.2-0.3
Ollama 本地推理 跑 embedding 和本地小模型；升级记录在案（240731_upgradeOllama.md）；限制并发防 OOM
vLLM (CPU) 本地 LLM 推理 CPU 版，Llama-3.2-1B，bfloat16，KV cache 10GB，OMP 线程绑定，端口 8000
HuggingFace API 云端大模型对比 只用于 AB 评测对比，不用于生产（数据合规）
open-webui 交互界面/调试入口 docker-compose 部署，3000→8080，数据卷持久化
评测系统 多模型自动化评估 统一评测集 → 各模型跑 → 输出落库 → 规则校验 + 人工打分 → 汇总报告

3.5 选型理由（每个都要能讲”比过谁、为什么”）

  • 为什么 Dify 底座 + 自研上层：Dify 提供知识管理 / RAG 引擎 / 工作流 / Prompt IDE / Agent / BaaS / SSO 开箱能力，避免从零造轮子；但业务要定制——自研 document_loader、custom_splitter、Neo4j 联合查询、检索编排。这就是”轻量级自研方案”的真实含义：在开源底座上做减法、按业务定制。
  • 评估过的框架：LangChain / LangGraph、Quivr、FastGPT、Dify（仓库有对应文档：quivr_design、quivr_front_dev_log、fastGPT、dify_vdb、neo4jCombineLangchain）——面试被问”POC 对比”就列这份清单。
  • 为什么 langchain 做后端编排：检索 / Model I/O / Document I/O / Agent 生态成熟，Neo4j 有官方集成（240715_neo4jCombineLangchain.md）。
  • 为什么 celery + redis：文档处理、批量 embedding 是长任务，异步化不阻塞 API。
  • 为什么 Qdrant（工单相似度接口）：独立向量库、轻量单容器、支持 payload 过滤；对比过 Milvus（依赖 etcd/minio 太重）、FAISS（要自己包服务）。
  • 为什么 Supabase/pgvector（平台侧）：与 PostgreSQL 同源、运维简单、Dify 支持；向量库选型有专门评估文档（240517_dify_vdb.md）。
  • 为什么 Neo4j：关系推理是图数据库强项，Cypher 表达多跳查询直观；对比过 SQL 递归 CTE，深度受限、难维护。
  • 为什么 nomic-embed-text 而不是 OpenAI embedding：本地可跑、免费、768 维适中、上下文长（8192）；OpenAI embedding 要外网且按量付费，数据合规不允许。

3.6 遇到的坑（面试讲这些最有说服力）

  1. chunk 切分导致语义割裂：按固定长度切会把一个完整条款劈成两半 → 改为按 Markdown/文档标题结构切分 + overlap（custom_splitter 就是为此自研的）。
  2. 中文 embedding 效果一般：nomic-embed-text 偏英文，纯中文问题召回差 → 混合检索（关键词兜底）+ 重排弥补。
  3. Ollama 本地并发一高就 OOM：默认并发过高把内存吃满 → 限制并发数、调 OMP 线程绑定；把 embedding 推理和 LLM 推理拆到不同进程（vLLM 单独起），避免互相挤占。
  4. Qdrant 索引构建慢 / 内存占用高：HNSW 参数调优（m、ef_construct），控制 collection 数量；重建表（清空数据）要先做快照备份（仓库有专门文档）。
  5. Neo4j 数据滞后：PG 是源、图库是派生数据 → 定时增量同步 + 失败重试，容忍分钟级延迟，并在文档里写明”图数据为近实时”。
  6. Few-shot 示例太长烧 token：固定全量示例太大 → 用 embedding 相似度从示例库动态选 2-3 条与当前问题最相似的示例。
  7. 模型输出格式不稳定：输出不是合法 JSON / 缺必含字段 → 输出校验 + 失败重生成一次，仍失败则降级返回检索片段。
  8. Dify 底座升级兼容性：Dify 迭代快，前端版本升级后后端接口/配置对不上 → 锁定版本 + 升级前回归测试（前端同事主导，我负责部署侧）。
  9. celery 异步任务失败静默：批量 embedding 任务失败容易没感知 → 任务状态落库 + 失败重试 + 日志告警。
  10. pgvector 与业务库同库的性能影响：数据量大后向量检索与业务查询互相挤占资源 → 按数据规模分环境，重查询场景用独立向量库（Qdrant）。

四、负责内容（分点，标注主导/参与/独立）

  1. 【主导】设计并实现基于 RAG 的多源异构数据协同架构：PostgreSQL + Neo4j + Qdrant 三种数据库分工与联动，通过相似度查询实现跨数据形态的精准匹配。
  2. 【独立】开发矢量化处理流水线：文档解析 → 结构切分 → nomic-embed-text 生成 embedding → 写入 Qdrant；设计基于余弦相似度的混合检索策略（向量 + 关键词 + RRF 融合 + 重排）。
  3. 【主导】Prompt Engineering 优化工程：动态模板（按查询类型选模板、动态拼上下文和约束）+ Few-shot 学习（动态示例选择），LLM 输出与业务需求匹配度从 68% 提升到 92%。
  4. 【独立】搭建多模型测试与自动化评估框架：集成 Ollama 本地模型与 HuggingFace 云端 API，统一评测集 + 规则校验 + 人工打分，支持 7 种大模型横向 AB 对比（质量 / 延迟 / 吞吐三维）。
  5. 【独立】实现 Neo4j 知识图谱与 Qdrant 向量库的联合查询：意图分类 + 实体抽取 → 图多跳推理 + 语义检索融合，复杂关系类查询端到端响应时间缩短约 40%。
  6. 【参与】技术选型与方案设计：完成 LangChain、LangGraph 等框架的 POC 对比测试，输出选型报告，最终采用轻量级自研方案，云资源开销估算节省约 32%。
  7. 【独立】AI 服务基础设施部署：qdrant、open-webui、vllm 的 docker-compose 编排、数据卷持久化、健康检查与资源调优。

诚实边界（主动说）： “模型训练、微调不是我做的，用的开源预训练模型；我负责系统架构、流水线、部署运维和评测工程。”

五、完成成效（量化结果 + 如何度量）

|—|—|—|
| 长文本匹配准确率提升 35% | 我们测的是 top-5 检索命中率（答案所在文档出现在前 5 条检索结果中的比例），混合检索从约 61% 提升到约 82%，相对提升约 34%，写成了约 35% | 三组对照：纯关键词检索 vs 纯向量检索 vs 混合检索；200 条内部长文本测试集；相关性另做人工抽样打分（1-5 分） |
| 匹配度从 68% 提升至 92% | LLM 输出与业务需求的一致性：人工 1-5 分打分、≥4 分算匹配 + 规则校验（必含字段 / 格式），68→92 是绝对百分点 | 30-50 条业务真实问答场景，业务方参与确认评测集 |
| 7 种大模型 AB 测试 | 统一评测集 + 统一 Prompt 模板 + 统一温度参数，唯一变量是模型；三维对比：输出质量（人工分 + 规则通过率）、延迟（首 token / 总时长）、吞吐 | 50-100 条评测集；本地组 Ollama/vLLM，云端组 HuggingFace API |
| 复杂查询响应时间缩短 40% | 只针对多跳关系推理类复杂查询：端到端从约 8 秒降到约 4.8 秒（图+向量联合 vs 纯向量基线）；普通单文档问答没有这个幅度 | 基线 = 纯向量检索方案（把大量相关文档整段塞给 LLM）；图方案把上下文压到关系路径 + 少量证据文档 |
| 节省 32% 云资源消耗 | POC 阶段资源需求估算对比（不是财务账单）：同等业务能力下，完整 Dify 平台部署 vs 裁剪定制后的部署（去掉用不到的模块、自研轻量上层组件）的容器数、内存、CPU，按云计费单价折算 | Dify 完整部署 vs 定制裁剪部署的资源实测/估算对比 |

辅助成效（口头补充）： 自动化评估把每轮人工测试从半天缩短到 1 小时以内；评测报告直接支撑了”生产用本地小模型”的决策，避免了云 API 的数据合规风险。

六、面试官提问与参考回答

1. 基础问题（5 题）

Q1. 简单介绍一下这个项目，你在里面具体负责什么？

  • 【面试官意图】考察项目真实性、个人角色定位、结构化表达能力。
  • 【参考回答】先给结论：”这是团队 2024 年并行推进的私有 LLM 编排平台（Private LLM orchestration），内部代号 LarkLex，目标是开源产品——我负责它从架构实施到落地的全链路工程化。”然后展开三件事：三种数据形态的协同架构（PG 管结构化数据、Neo4j 管关系图谱、向量库管语义检索，落地为给 ITSM 的工单语义搜索接口）；RAG 流水线加 Prompt 优化（匹配度 68% 提到 92%）；多模型评测框架（7 个模型 AB 对比，最终基于开源底座定制 + 自研上层组件，省约三成资源）。最后补一句定位：”AIGC 方向由团队同事、团队同事牵头，我岗位是 Linux 系统工程师，负责工程落地、部署运维和评测体系，模型用的是开源预训练模型。”
  • 【岗位侧重】通用

Q2. 什么是 RAG？这个项目的数据流是怎么走的？

  • 【面试官意图】考察基础概念是否扎实，能否讲清端到端流程，这是 AI 岗必考题。
  • 【参考回答】先下定义：”RAG 是检索增强生成，先检索再生成——不把模型当知识库，而是先从库里检索出相关片段，再让 LLM 基于这些片段回答。”再讲数据流：”入库侧：文档按结构切块、用 nomic-embed-text 转成向量存进向量库（工单相似度接口用 Qdrant，平台底座用 pgvector），实体关系写进 Neo4j，原始数据留 PostgreSQL；查询侧：用户问题同时走向量检索、关键词检索和必要的图查询，融合重排后取 top-5 拼进 Prompt，LLM 生成答案，最后做格式校验。”
  • 【追问】为什么不把所有文档直接塞进 LLM 上下文？→ “成本高、超上下文限制，而且我们本地小模型窗口小；检索只取相关片段，省 token、快、可控。”／RAG 和微调有什么区别？→ “RAG 不改模型参数，靠检索注入知识，更新知识只换库；微调改参数、成本高、更新慢。我们的业务知识更新频繁，RAG 更合适。”
  • 【岗位侧重】通用 / AI运维

Q3. 为什么同时用 PostgreSQL、Neo4j、Qdrant 三种数据库？各自干什么？为什么不只用一种？

  • 【面试官意图】考察架构决策能力、对三种数据库差异的理解。
  • 【参考回答】先给结论：”三种库管三种数据形态，各干各最擅长的。”再展开：”PostgreSQL 管结构化业务数据和原始文档，是权威事实源；Neo4j 管实体关系，负责多跳推理，比如’某项目涉及哪些供应商’；Qdrant 管语义向量，负责模糊的语义检索。单一库做不到：关系型 SQL 做不了语义相似度，图数据库擅长关系但做不了向量检索，向量库做不了精确的聚合统计和事务。”
  • 【岗位侧重】运维 / AI运维

Q4. 什么是 embedding？nomic-embed-text 是什么？为什么选它？

  • 【面试官意图】考察向量化基础 + 选型依据，AI 运维岗高频。
  • 【参考回答】先定义：”embedding 是把文本映射成固定维度的向量，语义相近的文本向量距离近，之后就能用相似度检索。”再说模型：”nomic-embed-text 是 Nomic AI 的开源文本嵌入模型，768 维、上下文 8192 tokens，可以本地跑。”最后说选型：”选它因为三个硬约束：数据不出内网所以必须本地、免费、维度适中且上下文长适合长文本。对比过 OpenAI embedding，要外网还按量付费，直接排除。”
  • 【追问】768 维够用吗？→ “对内部文档检索够用；这个模型还支持 Matryoshka 表示学习，维度可以往下截断，我们保留了全量 768。”／中文效果怎么样？→ “说实话它偏英文，中文一般，所以我们用混合检索（关键词兜底）加重排来补召回，这也是长文本提升 35% 的一个原因。要更强中文效果可以换 bge-large-zh，但当时没有 GPU 预算，先保住了本地部署这个硬约束。”
  • 【岗位侧重】AI运维

Q5. 这个系统部署在哪？模型怎么跑的？你怎么运维它？

  • 【面试官意图】运维/DevOps 岗核心考察点——验证是否真的部署过、是否懂容器和资源管理。
  • 【参考回答】先给结论：”全部 Docker 部署，docker-compose 编排。”再报细节：”中间件用 docker-compose.middleware.yaml 起，环境要求 node>=20.11.1、python>=3.10、docker>=19.03；平台侧向量库用 Supabase（PostgreSQL+pgvector），supabase start 启动；工单相似度接口那套向量库是 Qdrant（配套 docker-compose，6333/6334 端口）；模型侧 Ollama 跑 embedding 和小模型、vLLM CPU 版跑本地推理（Llama-3.2-1B、KV cache 10GB、线程绑核）。”最后讲运维：”监控主要看容器资源占用、异步队列长度和接口延迟；性能验证用 JMeter 压工单相似度接口，10 用户并发、topK=5；遇到过内存吃满 OOM，压并发、拆进程解决。”
  • 【岗位侧重】运维 / DevOps / AI运维

2. 深入问题（6 题）

Q6. 余弦相似度怎么算？为什么用它而不是欧氏距离？top-k 怎么定？

  • 【面试官意图】考察是否真的写过相似度检索，还是只会调库。
  • 【参考回答】先讲公式结论：”余弦相似度是向量的点积除以模长乘积，衡量的是方向一致性，对模长不敏感。”再讲取舍：”embedding 的模长本身意义不大，不同文本长度差异会让欧氏距离失真，所以用余弦；实现上可以把向量先归一化，归一化后余弦就等于点积，Qdrant 内部就是这么处理的。”最后讲参数：”检索召回 top-k 取 20，融合重排后只给 LLM 前 5 条——召回多一点给重排留空间，给 LLM 的上下文必须少，控制 token 成本和噪声。”
  • 【追问】Qdrant 里怎么配的？→ “collection 的 distance 参数设 Cosine，查询走 query_points，配合 payload filter 按业务域过滤；HNSW 参数也调过，m 和 ef 影响内存和召回。”
  • 【岗位侧重】AI运维 / 通用

Q7. 混合检索具体怎么做？两路结果怎么融合？

  • 【面试官意图】考察检索策略深度，是否只会调接口、只会用现成框架。
  • 【参考回答】先给结论：”双路召回：Qdrant 向量检索管语义，PostgreSQL tsvector/BM25 管精确词，专有名词和编号靠第二路兜底。”再讲融合：”融合用 RRF（倒数排名融合）——对每路结果的排名取倒数求和，两路都命中的排前面；然后做一层重排，最后取 top-5 给 LLM。”最后讲为什么：”RRF 只看排名不看分数，因为两路分数分布不一样（向量相似度集中在 0.6-0.9，BM25 分数没有上界），直接加权要调参还不稳定。”
  • 【追问】为什么不直接加权平均分数？→ “分数分布不同，加权权重很难调，换个数据分布就失效；RRF 只看排名，稳定、简单、不用调参。”／35% 的提升是混合检索的功劳还是 embedding 的功劳？→ “我们分开测过：纯关键词到纯向量提升约 20 个点，再加混合检索和重排再提升 10 多个点，合起来约 35%。这个有当时的对照数据。”
  • 【岗位侧重】AI运维

Q8. 动态模板和 Few-shot 是怎么实现的？匹配度怎么从 68% 提到 92%？

  • 【面试官意图】考察 Prompt Engineering 是否真实做过，能否讲出机制而不是背概念。
  • 【参考回答】先给结论：”动态模板是’按查询类型选 Prompt 结构’，Few-shot 是’动态选示例’。”再展开：”模板方面，把问题分成查询类、问答类、统计类，每类一套 Prompt 结构，运行时把检索到的上下文、业务约束、输出格式要求拼进去；Few-shot 方面，示例库里存人工标注的优质’问题-答案’对，用 embedding 相似度动态挑 2-3 条最像当前问题的塞进 Prompt。”最后讲提升归因：”68% 到 92% 主要来自三块：格式约束（消除解析失败和格式错乱）、Few-shot 示例（教回答风格和结构）、检索质量提升（上下文更准）。”
  • 【追问】92% 是怎么算的？→ “人工打分，1-5 分制、4 分及以上算匹配，加上规则校验；评测集是 30-50 条业务真实问题，业务方参与确认。68 到 92 是绝对百分点。”／温度参数调过吗？→ “调过，问答类任务 temperature 放 0.2-0.3 减少发散，但主要收益还是来自模板和示例。”
  • 【岗位侧重】AI运维

Q9. 7 种大模型的 AB 测试是怎么做的？评估系统怎么设计？结论是什么？

  • 【面试官意图】AI 运维核心考点：模型评测方法论，考察是否真的搭过评测系统。
  • 【参考回答】先报模型清单：”7 种是 Llama2-7B/13B、Llama3-8B、ChatGLM3-6B、Qwen-7B、Mistral-7B、Baichuan2-7B、Gemma-7B，本地组走 Ollama/vLLM，云端组走 HuggingFace API——简历上’多语言模型调度’对应的就是平台的 Models Orchestration 模块：LLM、Embedding、Re-rank 三类模型统一编排，本地模型部署和升级走 Ollama（仓库里有升级记录）。”再讲评估系统：”统一评测集 50-100 条覆盖典型业务场景，同一套 Prompt 模板和温度参数，唯一变量是模型；输出全部落库，三块评估：规则校验（格式、必含字段、JSON 可解析）、人工打分（相关性、完整性、幻觉三个维度）、性能指标（首 token 延迟、总时长、吞吐）。”最后讲结论：”综合质量和成本，本地小模型（Llama3-8B / ChatGLM3-6B 这一档）够用，云端大模型质量略好但贵、还有数据合规风险，所以生产选了本地。”
  • 【追问】AB 测试怎么控制变量？→ “同一评测集、同一 Prompt 模板、同一温度，唯一变量是模型；评测顺序打乱，避免打分疲劳带来的偏差。”／幻觉怎么评估？→ “规则层做答案与检索上下文的忠实度检查，看关键实体是否在上下文中出现；人工打分里单列’幻觉/编造’维度。”
  • 【岗位侧重】AI运维

Q10. Neo4j 和向量库的联合查询怎么实现？”图谱推理”具体指什么？

  • 【面试官意图】简历亮点问题，考察真实性和对图+向量混合方案的深度理解。
  • 【追问】实体抽取怎么做？→ “规则加 LLM 辅助：业务实体名是有限的，先词典和正则匹配，再让 LLM 抽漏网的，最后和图节点做模糊匹配对齐。”／Cypher 写错了怎么办？→ “全部用预编译模板加参数化查询，不拼接用户输入，既防注入也防语法错误；查图失败就降级走纯向量检索，保证不中断。”
  • 【岗位侧重】AI运维

Q11. 技术选型是怎么做的？”轻量级自研方案”具体指什么？32% 怎么算的？

  • 【面试官意图】DevOps 考察点：POC 方法论 + 成本意识 + 技术取舍能力，同时验证”自研方案”的真实性。
  • 【参考回答】先讲 POC 方法：”我们评估了 LangChain/LangGraph、Quivr、FastGPT、Dify 多个方案，仓库里都有评估和拆解文档——Quivr 的设计与前端拆解、FastGPT 调研、Dify 的向量库选型和前端定制、Neo4j+LangChain 结合原型。”再讲结论：”Dify 的知识管理、RAG 引擎、工作流、Prompt IDE、Agent、SSO 开箱即用，避免从零造轮子；但业务要定制，所以我们在它上层自研组件——文档加载、自定义切片、Neo4j 联合查询、检索编排，后端用 langchain 做编排。所谓’轻量级自研方案’就是在开源底座上做减法、按业务定制。”最后讲 32%：”是 POC 阶段的资源估算对比：同等业务能力下，完整 Dify 平台部署 vs 我们裁剪定制后的部署，容器数量、内存占用更低，按云资源单价折算约省三成。”
  • 【岗位侧重】DevOps / AI运维

3. 刁钻/压力问题（4 题）

Q12. 简历写”多模态”，但听起来你只处理了文本，多模态在哪？

  • 【面试官意图】抓夸大表述，考察诚实度和定义能力。
  • 【参考回答】先正面定义：”我们说的多模态指数据源的多形态——结构化数据（PostgreSQL 表）、关系型数据（Neo4j 图）、非结构化长文本（业务文档/ITSM 工单）以及向量化后的语义表示（向量库），跨这几种形态做联合检索，所以叫多模态数据处理。落地场景就是工单语义搜索：ITSM 的文本工单内容和知识库/附件一起做相似度检索。”再主动划界：”它不是图像、音频那种多模态模型，那部分是我们后续规划。如果这个词容易引起误解，我更愿意表述成’多源异构数据的协同检索’。”
  • 【追问】那你觉得简历这么写合适吗？→ “从工程角度看’多模态数据’是成立的，但确实容易被理解成多模态模型。您指出来之后我意识到这个表述容易引起歧义，后续我可以改成’多源异构数据’，这是合理的修正。”
  • 【岗位侧重】通用

Q13. 35% 和 40% 这些数字怎么来的？评测集多大？有对照组吗？

  • 【岗位侧重】通用

Q14. 你是 Linux 系统工程师，不是算法工程师，这个项目里你的角色是不是被夸大了？

  • 【面试官意图】考察岗位与项目匹配度、诚实度，看你敢不敢承认边界。
  • 【参考回答】先承认边界：”我确实不是算法工程师，模型是开源预训练模型，训练和微调不是我做的。”再讲实际贡献：”LarkLex 的 AIGC 方向由团队同事、团队同事牵头，AI 后端主要是李林、前端孙博；我的角色是把系统工程化落地——数据库协同架构的实施、Python 流水线、模型本地化部署、评测系统，还有 Q4 排期里我占大头的高可用、CI/CD、监控。排期文档里我的投入配比是 AI 10%、DevOps 90%，所以我主战场是工程和运维。”
  • 【追问】那为什么简历写”设计并实现”？→ “设计并实现的是系统架构和检索策略的工程部分——数据库协同、混合检索链路、评测体系，这些落地工作是我主导的；不是模型算法，算法用的开源模型。我承认’AI 主导’的表述不准确，我的定位是工程化落地。”
  • 【岗位侧重】通用

Q15. 如果让你现在重做一遍，你会改什么？

  • 【面试官意图】考察复盘能力、工程判断、有没有真实思考过。
  • 【追问】会换掉 nomic-embed-text 吗？→ “分场景：英文或中英混合语料可以留，纯中文换 bge 系；但这需要 GPU 预算，当时没条件，所以先靠混合检索兜底。”
  • 【岗位侧重】通用