Skip to content

PH面经

约 2324 字大约 8 分钟

2026-04-25

面经整理

Hiknow知识分享平台深度融合AI大模型与IM长连接集群,提供流畅实时对话。基于RAG技术,智能关联企业知识库,实现精准

问答、文档摘要与知识推荐,并结合AI创作与自动标签功能,全链路提升知识获取与生产效率。

核心技术栈

Spring、Spring Boot、Spring Cloud、Mybatis、Mybatis-Plus、Redis、Redisson、Spring AI Alibaba、Netty、

ElasticSearch、Milvus、MySQL

主要职责:

  1. 为满足平台海量用户实时交互需求,基于Netty+SpringBoot+Nacos搭建高并发WebSocket集群,实现单机承载连接数10万+且消息延迟稳定控制在100ms以内。

  2. 针对分布式环境群聊消息同步挑战,通过Redis Pub/Sub消息总线与异步确认机制,实现2000人群聊消息端到端平均延迟稳定在15ms以内。

  3. 为解决读扩散方案查询延迟高的问题,采用写扩散策略异步预生成未读消息,使消息列表查询延迟从200ms降至20ms。

  4. 为提升知识库检索效率,引入ElasticSearch设计多字段索引与权重优化,实现搜索响应时间P99控制在100ms以内且召回率达95%。

  5. 为提升用户问题解决效率,通过Spring AI Alibaba接入通义千问大模型,使问题单提交率下降60%且平均问答耗时<2秒。

  6. 为增强大模型专业领域知识准确性,采用RAG技术结合Milvus向量检索,实现检索精度MRR@5达0.89,故障定位准确率提升至92%。

项目背景

前司是一家视频物联行业的龙头企业,主要专注于物联网领域的数字化解决方案,主营产品:

  • 硬件产品:摄像机、球机、IPC、交换机、NVR、CVR等设备;
  • 软件产品:综合安防管理平台、智能分析服务器、智慧办公一体化平台;

整体的业务目标就是在物联网的领域内容提供一体式的解决方案。公司会生产很多的硬件产品,售卖给客户(经销商)或者用户。

对于客户和用户而言,在购买了我们的设备后,不可避免的会遇到设备出现故障的问题:

  • 没有Hiknow知识分享平台之前,我们的处理方式是:区域技术支持会去现场先处理相关问题,然后会升级到总部技术支持,当总部的技术支持解决的不掉的时候,会在OA系统中提交问题单指派给对应设备的研发来处理这个问题。
  • 有Hiknow知识分享平台之后,我们的处理方式变是:区域技术支持直接通过Hiknow知识分享平台找到问题的解决方案,如果找不到的话,就直接通过Function Call的方式直接提交问题单,升级问题到对应产品的研发来处理这个问题。

Hiknow知识分享平台的价值:

  • 减少问题处理流程的复杂度,提高问题处理的响应,加快问题解决的速度;
  • 研发侧维护相应的知识库,沉淀出规范的文档,对于后续业务的发展路线具有参考意义;

面试遇到的问题

说下你的在这个项目的角色以及主要承担的工作是什么?

作为核心开发骨干在项目的前期参与相关技术栈的选型以及在项目中参与核心模块的开发。

其中我负责的选型主要分为两个方面:

  • 长链接管理集群中涉及到的技术栈:
    • 其中主要对比的计数栈为Spring Boot WebSocket和Netty
    • 长链接管理集群的建立方式:Spring Boot + Nacos + Netty 双端口应用和Netty纯应用网关架构;
  • 企业级知识库RAG增强检索涉及到的技术栈:
    • 基础框架:Spring AI、Spring AI Alibaba和LangChain4j
    • 向量存储:Milvus、Redis和ES

其次在项目开启的周期中,我负责整个企业级AI知识库RAG的全流程,其中设计到文档的收录、文档的切割、文档的存储、向量的存储以及增强检索的流程的实现。

长链接集群的搭建

  1. 整个系统的用户规模、机器规模和日活连接数大概是多少?
  2. 消息发送的全链路是什么?(可以从建立链接 –> 网关负载均衡 –> 链接信息的存储 –> 客户端发送消息 –> 接受到消息 –> 持久化消息 –> 单聊或群聊消息的转发)
  3. 链接的保活机制以及链接信息的存储是怎么做的?
  4. 使用Redis来存储链接信息,那是否会形成大Key问题,你们是怎么判断一个key是大Key的?那对于这样的大Key你们的解决策略是什么?(一个Key化成多个Key Hash取模常规方式,三主三从集群模式搭建)
  5. 单聊和群聊为什么要区分开来?为什么单聊不采用发布订阅的模式?
  6. 在项目运行期间单聊消息和群聊消息的比重是多少,通过什么方式建立的监控机制?
  7. 监控中显式后期单聊消息会比群聊消息占比更多, 那遇到过什么问题吗,你是如何解决的?
  8. 目前是在第一阶段30万+连接,那么后期如果要变成100万+,你觉得你这个架构下你的系统需要做出哪些改变?
  9. 单机承载连接数10万+,你是怎么测试出来的?其中是否会去做一些服务器系统参数设置相关的工作?你是怎么设置的?
  10. 2000人群聊消息的延迟在15ms以内,你们是如何得出这个阶段的,测试的方式什么?

RAG的流程

  1. RAG的整体流程

  2. 你们用的是什么模型?私有化部署的吗?(因为前司是阿里云企业用户,直接用的百炼平台的qwen3-max模型)

  3. 为什么会选择这个模型?那么向量化的模型又是那个?

  4. 文档切割的方式(演进过程:不切割 –> 固定字符切割 –> 冗余字符切割)

  5. 文档向量存储的方式?

  6. 随着文档数量的增多,向量数据库中的规则也在不断的增加,如何保证召回的效率?(可以定期分类回归向量数据库来实现,文本内容片重复率来进行过滤)

  7. Milvus中有多少种索引类型,分别有什么区别,你们采取的是哪种,为什么要采取这种?

  8. 在整个RAG的过程中,如果文档中出现了图片或者视频相关的内容是如何处理的?(图片可以采用OCR的方式提取,视频的话目前是业务上限制了)

  9. 图片使用了OCR的方式来处理,那么如何保证OCR的效果?一般来讲文档中的图片的内容是那些,OCR的文本能否准备描述这个图片?

  10. 除了OCR的方式来处理这个图片还有什么方式,有没有考虑过使用多模态大模型?了解多模态大模型吗?

  11. 你们对于文档的内容如何来做风控处理的,你们的风控是前置还是兜底?

  12. 不同类型的文档是怎么来切割的?PDF、TEXT、DOCX或者是Excel类型的文本?

  13. 你在做向量召回的时候如何来保证召回的效果,评判的指标是什么?

  14. 你出了RAG还有哪些内容?(工作流:意图识别、Function Call)

  15. 意图识别是怎么做的?一共有几个意图?(意图识别判断是固定内容查询还是解决方案,其实就是判断问题是否需要RAG,到底哪些内容需要RAG,走传统的ES能否也会有更好的效果,传统的ES就会通过Function Call来实现)

  16. 了解Graph RAG 、Multi-modal RAG、 Hybrid RAG吗?听说过吗?

  17. 你觉得你这个RAG流程后续的发展方向是什么?最终的产品形态是什么?

  18. 你们RAG的效果是如何检测的,通过什么方式?(主动测试:人工打标 –> 建立自动化流程;被动手机:反馈系统、回答点赞点踩数据收集)

  19. 大模型输出的内容通常会比较耗时,你们是怎么保证用户体验的?(流式输出、用户对输出慢的容忍度较高、ES作为兜底的熔断策略)

  20. 对于意图识别的准确性做了哪些保证?(前期利用当前的query来做意图识别,后面通过聊天记忆中的query来实现意图识别)

  21. 这个项目大概运行了多久?你觉得RAG效果怎么样?是否有真正在帮助你们解决问题?如何体现出来的呢?