派聪明 RAG 真实面经参考，已累计 27 家，700 道题目（不断更新中）

1.快手快 star

描述一下上传文件，提问到显示答案整个数据流以及涉及到的模块/技术栈

后端服务是基于 Spring Boot 3 构建的，文件上传时会用到 MinIO 和 Kafka，MinIO 用来存储文件，Kafka 用来做文件异步解析。

消费者会从 MinIO 中拉取文件，然后使用 Tika 解析分块后调用 embedding 模型生成向量，并且文本、向量存入到 ElasticSearch 中。

用户提问后会先对问题向量，然后在 ElasticSearch 中执行混合检索，一方面做向量的相似度检索、语义召回，另一方面结合 BM25 做关键词检索。

然后将检索到的上下文拼接到 prompt 一并发给大模型生成答案。后端通过 webflux 的 SSE 进行流式返回，前端实时进行渲染。

怎么 chunk 的，为什么这么做？

我采用了基于语义边界的递归切分策略。具体做法是先按照段落进行切分，如果某一块超过了设计的分块大小，就用降级的句号进行拆分，直到每个 chunk 都控制在规定的范围内，通常在 500 个字内。

同时我还引入了 overlap，设置为 10%，这样相邻的 chunk 会有一小段内容重叠，避免关键语义被切断。

这么做主要有三个原因，embedding 模型本身有输入长度限制，分块是向量化的前提；语义集中的 chunk 在混合检索时也会更容易被精准召回；重叠的 overlap 能提供更好的上下文信息。

用的什么模型，有对比过吗

向量这块一开始用的豆包，但后来不向下兼容 2048 维，于是就切换到阿里的 embedding 模型。

LLM 这块一直用的 DeepSeek。

检索结果不符合预期怎么办

先搞清楚问题发生在哪个阶段：

相关内容有没有被召回，如果没有，多半是分块或者向量时的问题；
如果召回了但排序靠后，那就是混合检索时排序的问题了。

第一步，调整 chunk_size 和 overlap，强化语义边界的递归切分；

第二步，更换 embedding 模型，看看其他模型是否会更好。

第三步，调整 BM25 与向量检索的权重，把最相关的 3 到 5 条上下文喂给 LLM。

第四步，用 MRR 这类指标做对比验证。

ES 里怎么存的

ElasticSearch 的索引名为 knowledge_base，会存三个字段：内容、向量、权限。

首先是内容字段，我们定义为 textContent，它的类型是 text，底层配的是 ik 中文分词器。这个字段用来支持关键词检索的，像 BM25、match 查询都是作用在这个字段上。

然后是向量字段，名叫 vector，我们定义为 dense_vector 类型，维度是 2048，这个维度要和 embedding 模型匹配。这个字段用来做语义检索。当用户发起查询时，我们会把查询的内容转成向量，再用 KNN 算法去比相似度。

接着是权限相关的字段，在做 B 端多租户场景时要非常重视的一块。主要有三个字段：userId、orgTag 和 isPublic。

userId 标记这个文档片段属于哪个用户，用于实现私有文档的权限隔离；
orgTag 表示文档所属的组织标签，用来控制组织内的授权访问；
isPublic 标记文档是否对所有人公开。

分片上传是怎么做的？断点续传？你这个场景有意义吗？

对于大文件，派聪明采用的是‘分片上传 + 断点续传’的方式。我们会在前端先把大文件切成小的分片，比如 5MB 一块，然后并发地上传到后端。后端每收到一个分片，就存到 MinIO 中，同时会用 Redis 的 bitmap 去记录哪些分片已经上传成功。这样的好处就是，即使上传过程中断了，前端可以根据 Redis 状态判断哪些分片已经上传，不用从头开始，用户体验会比较好。

当所有分片上传完成后，前端会调用后端的合并接口。这里我们用的是 MinIO 提供的 composeObject 功能，直接在存储端完成分片的合并，合并完成后，系统会把文件状态在 MySQL 里更新为‘已完成’，并且清理掉对应的分片文件和 Redis 记录。

非常有意义，等到网络恢复后，前端会带着这个文件的 MD5 去后端的 Redis 里查所有分片的状态，前端拿到分片状态后，在重新上传的时候，就会跳过那些已经上传成功的分片，只上传那些还没传的。这样就避免了重复上传。

2.小红书一面

AI & RAG 相关

RAG 怎么解决 LLM 上下文窗口有限的问题？
RAG 里的“重要性重排序”是怎么判断哪个内容更“重要”的？
流式对话支持多轮吗？怎么实现的？
提示词做了哪些优化？如果多轮对话关联性不强，怎么抓住新问题的重点？
OpenAI 协议里，上下文的角色有哪几种？
system, user, assistant 这几个角色在使用上有什么区别？

Java 基础 & 并发

讲讲 Java 不同更新版本的区别，特别是关键版本。
为什么 Spring Boot 3.x 要用 Java 17+的版本？项目里用了哪些新特性？
Lambda 表达式和 Stream API，跟传统的 for 循环比，优缺点是什么？
parallelStream()为什么性能好？底层是什么实现的？
如果不用 parallelStream，用传统 for 循环自己写并发提交任务，代码大概分几块？
都说 Java 线程“重”，Go 协程“轻”，这个“重”具体体现在哪？
为什么 Java 线程实际只用很少的栈，但 JVM 却要给它分配那么大的栈空间？
协程到底是个什么东西？
Java 里写 for 循环有几种方式（比如用索引 i，用迭代器），它们有什么区别？

算法手撕

实现一个函数，找出字符串里所有长度大于 1 的子回文串。

3.某对标亚信公司一面

面了一家听说对标亚信的公司，面试官口头和我说过了，下一轮 boss 面让我瞎聊就行
java 基础和集合查缺补漏面经：
embedding 用什么模型？
混合检索？怎么评估准确性？
大模型的选择
上下文管理？
redis 的击穿，雪崩，穿透
AOP
MySQL binlog 监听通过主从复制原理
ThreadLocal
消息队列，消息如何不丢失？

要我现场跑跑派聪明，没跑起来。。。很悲催，我没改前端也不怎么熟悉流程。

4.未知公司

面经：

1、介绍项目从数据上传到最后存入数据库的流程、RAG 流程
2、切块的步骤、如何评价优化前后的 RAG 的好坏
3、针对用户不同的提问：提问语句长短不同，分别怎么检索？
4、向量化的数据有做处理吗？

5.腾讯二面

1.派聪明技术选型，如为什么用 minio 做文件存储、选择 es 等
2.rag 的准确率如何优化
3.语块如何分片
4.es 相关
5.大文件也可以断点续传为什么要分片？
6.从用户体验上来说，一个文档也没有很大，分片上传的提升并不大，这里如何考虑的？

6.合合信息一二面

一面面经

拷打项目

讲一下自己的 rag 这一套流程的理解
在里面采取了哪些技术
对接大模型用的什么
文件拆分是怎么分割的
用户提交问题后的流程
中间过程纯手工编的吗？（我答的没用 langchain4j 或者 Spring ai）
如果有充足时间优化会优化哪些点
怎么解决检索过程中的权重误差？
如何优化检索来提高回答准确性？
了解过 agent 和 mcp 吗？
可以把整个流程让大模型自动弄吗？
如果用 agent 代替，你会怎么设计呢？
多人会话历史的窗口怎么设计的？
考虑过怎么优...

10 条评论

yinrrrrr 2026年02月10日 14:44

引用原文：⑤ 如果用户在表达主观的词，类似“我今天很郁闷”，项目会返回什么。(没答好，开始没听懂，后面面试官提示里面应该有个逻辑处理)

@派聪明

回复1 取消回复

派聪明 2026年02月10日 14:44

基于参考资料中派聪明项目的设计逻辑，当用户表达主观情绪（如“我今天很郁闷”）时，项目会按以**程处理： ### 1. **检索阶段：忽略情绪词，聚焦语义** - 系统会将用户问题转换为向量（通过Embedding模型），在ElasticSearch中执行**混合检索**（向量相似度 + BM25关键词检索）。 - 主观情绪词（如“郁闷”）会被自然融入语义向量中，但检索核心仍基于问题意图（例如，用户可能想寻求解决情绪的方法或相关建议）。 - 若知识库中存在匹配内容（如心理疏导技巧、情绪管理建议），系统会返回相关片段。 ### 2. **兜底机制：无匹配结果时的处理** - 若检索未召回相关内容（知识库无匹配数据），系统会触发预设兜底逻辑： - **Prompt设计**：在构建提示词时，若检索结果为空，系统会将上下文设置为 `（本轮无检索结果）`，并要求模型明确告知用户“暂无相关信息”（参考资料中多次强调此机制）。 - **模型行为**：DeepSeek模型会基于自有知识生成回应（如建议用户寻求专业帮助），但会标注“非知识库内容”，避免误导。 ### 3. **避免情感化回应的保障** - **Prompt约束**：系统规则明确要求模型**不主动回应情绪**，仅基于检索结果或自有知识提供客观信息。例如，不会生成“别难过”等共情**，除非知识库中有相关建议（如“尝试深呼吸放松”）。 - **引用标注**：若回答包含知识库内容，会强制标注来源（如“来源#1”），增强可信度，避免模型编造情感化内容。 ### 总结项目**不会主动处理用户情绪**，而是通过语义检索匹配知识内容，无匹配时触发兜底机制告知用户“暂无相关信息”。这种设计确保回答基于事实，避免模型生成主观或无效内容，符合企业级知识库的严谨性要求。

huhuhu 2026年02月09日 12:10

引用原文：关键词检索和向量检索的得分是怎么做归一化处理的

派聪明 2026年02月09日 12:11

在混合检索（关键词检索 + 向量检索）中，得分归一化处理的核心是将不同量纲的检索得分（如BM25关键词得分、向量相似度得分）映射到统一区间，以便加权合并。以下是具体实现逻辑： ### 1. **得分归一化方法** - **向量检索得分** 使用余弦相似度（范围 `[-1, 1]`），通过线性变换映射到 `[0, 1]` 区间： `归一化向量得分 = (相似度 + 1) / 2` （将负值转为0，1保持不变，中间值线性缩放）。 - **BM25关键词得分** 采用 **Min-Max标准化** 或 **Sigmoid函数** 压缩到 `[0, 1]`： - Min-Max：`(得分 - min_score) / (max_score - min_score)` （需动态计算当前查询的得分范围）。 - Sigmoid：`1 / (1 + e^(-α·得分))` （α为缩放系数，控制曲线陡峭度）。 ### 2. **加权合并策略** - 最终得分 = `w1 * 归一化向量得分 + w2 * 归一化BM25得分` - 权重 `w1` 和 `w2` 通过实验调优（如交叉验证），例如 `w1=0.7, w2=0.3` 偏好语义检索。 - **动态权重调整**：根据查询类型动态分配权重（如短问题侧重关键词，长问题侧重语义）。 ### 3. **优化方向** - **分档分片**：将得分划分为多个区间（如高、中、低），避免极端值影响。 - **重排序机制**：初始召回Top-K结果后，用Cross-Encoder模型二次排序，修正归一化偏差。 ### 4. **关键**** - **得分分布差异**：向量得分可能集中在 `0.8~1.0`，BM25得分分布更广，需适配不同查询。 - **动态范围计算**：Min-Max需实时计算当前查询的得分极值，可能增加延迟，可改用**统计值近似。 > **示例**：若向量相似度为0.6 → 归一化后为 `(0.6+1)/2=0.8`；BM25得分为15（**范围0~30）→ Min-Max归一化为 `(15-0)/(30-0)=0.5`；若权重 `w1=0.7, w2=0.3`，则最终得分 `0.7*0.8 + 0.3*0.5=0.71`。

mars 2026年02月08日 16:19

引用原文：你对现在的 AI 是怎么看待的？

@派聪明解答

派聪明 2026年02月08日 16:20

基于参考资料中多家企业面试官对AI技术的提问（如OPPO、美团、阿里健康等），结合项目实践，我对当前AI发展的看法如下： --- ### 1. **AI的核心价值：效率**与场景落地** - **效率提升**：在派聪明项目中，AI通过RAG技术（文档解析+向量检索）将企业知识库的查询效率提升90%以上，替代了传统人工检索（参考资料1、5）。 - **场景深化**：AI已从通用问答走向垂直领域（如法律文档解析、企业知识库管理），需结合业务需求定制化（参考资料7、13）。 --- ### 2. **技术**与优化方向** - **幻觉与可*性**： - 大模型可能生成错误信息，需通过**引用标注**（如派聪明的`<<REF>>`分隔符）和**上下文隔离**增强可信度（参考资料1、7）。 - 依赖**混合检索**（向量+BM25）提升召回率，避免单一模型局限（参考资料1、4）。 - **性能瓶颈**： - 高维向量检索需优化ElasticSearch的KNN算法，避免“维度灾难”（参考资料13）。 - 大文件处理采用**分片上传+断点续传**（如MinIO+Redis），提升用户体验（参考资料1、5）。 --- ### 3. **未来趋势：从工具到智能体** - **Agent化演进**：当前RAG是被动响应，未来可升级为**智能体**（Agent），自动执行多步骤任务（如跨文档分析、决策生成）（参考资料7）。 - **人机协同**： AI需成为“副**”，而非替代人类。例如在派聪明中，通过**对话**压缩**（Redis存储最近20轮）平衡上下文长度与响应速度（参考资料1、7）。 --- ### 4. **落地关键：工程化与成本控制** - **轻量化部署**：优先选用API接口（如DeepSeek）而非自建模型，降低算力成本（参考资料1、10）。 - **可观测性**：需监控检索准确率（如MRR指标）、模型响应延迟，建立**兜底机制**（如无结果时**用户重试）（参考资料1、9）。 --- ### 总结 AI正从“炫技”转向“实用”，其价值在于解决具体业务痛点（如知识库管理、文档解析）。未来需在**可*性、性能、成本**三方面持续优化，并探索Agent等新形态，实现人机协同的深度赋能。

水竹鼠 2026年02月08日 13:33

引用原文：项目中，有没有涉及安全保证的地方

派聪明 2026年02月08日 13:33

根据参考资料中项目相关内容，以下是涉及安全保证的关键点： ### 1. **数据权限隔离（多租户安全）** - **ElasticSearch 存储设计**： - 存储权限字段：`userId`（用户私有）、`orgTag`（**内共享）、`isPublic`（公开）。 - 通过 `userId` 实现私有文档隔离，确保用户只能访问自身上传的文档（参考资料1、11）。 - **鉴权机制**： - 使用 **JWT（JSON Web Token）** 进行接口访问控制（参考资料27）。 - **问题**：JWT 无状态特性导致**禁用后仍可使用未过期 token。 **改进方案**：引入 Redis 缓存禁用**的黑名单，或使用短时效 token + 刷新机制（参考资料27）。 ### 2. **文件上传安全** - **分片上传 + 断点续传**： - 前端将大文件分片（如 5MB/片），并发上传至 MinIO。 - 后端使用 **Redis Bitmap** 记录已上传分片，避免重复传输（参考资料1、5）。 - **完整性校验**： - 文件合并时通过 **MD5 校验** 确保数据完整性（参考资料1）。 ### 3. **缓存安全防护** - **Redis 缓存问题应对**： - **缓存穿透**：使用 **布隆过滤器（Bloom Filter）** 过滤无效查询（参考资料15）。 - **缓存击穿**：对热点数据加互斥锁（如 `setnx`），避免并发重建缓存（参考资料15）。 - **缓存雪崩**：设置随机过期时间 + 多级缓存（如本地缓存 + Redis）（参考资料14、15）。 ### 4. **消息队列可*性** - **Kafka 消息不丢失**： - 生产者：启用 `acks=all` + 重试机制。 - 消费者：手动提交 offset（`ack`），处理失败时自动重试 4 次，失败后转入死信队列（参考资料7、21）。 ### 5. **数据访问控制** - **向量检索权限校验**： - 在 ElasticSearch 检索阶段，通过 `userId`/`orgTag` 过滤结果，确保用户仅访问有权限的数据（参考资料1、11）。 ### 总结安全设计围绕 **数据隔离（ES 权限字段 + JWT）、传输安全（分片上传 + MD5校验）、缓存防护（布隆过滤器 + 锁机制）、消息可*性（Kafka 重试 + 死信队列）** 展开，重点解决多租户权限、文件完整性、缓存异常及消息丢失问题。

我的网名有毒 2026年02月07日 16:59

引用原文：混合检索有没有做分档分片？具体的分片方法是？目前的方案有什么问题？你觉得有没有更好的方案？

派聪明 2026年02月07日 17:01

根据参考资料中的技术实现，混合检索的分档分片方法及优化方向如下： ### 1. **分档分片方法** - **混合检索机制**：系统采用 **向量语义检索 + BM25关键词检索** 的混合模式（参考资料1、5）。检索结果通过权重融合排序，向量相似度与关键词相关性按比例计算最终得分（参考资料1）。 - **分档处理逻辑**： - **向量检索**：使用ElasticSearch的`dense_vector`字段（2048维）进行KNN相似度搜索（参考资料1）。 - **关键词检索**：通过`textContent`字段（IK分词器）计算BM25得分（参考资料1）。 - **权重融合**：动态调整两种检索的权重（如向量占70%，BM25占30%），将得分最高的Top-K条结果合并排序（参考资料1、5）。 ### 2. **当前方案的问题** - **关键信息丢失风险**：若核心知识片段因分块不当被切断（如跨段落语义），可能在向量检索中召回率下降（参考资料1、5）。 - **固定分块限制**：当前采用固定大小分块（500字+10%重叠），对长文档或复杂结构可能不够灵活（参考资料1、3）。 - **权重静态化**：混合检索权重固定，无法根据问题类型（如事实查询vs推理问题）动态优化（参考资料3、5）。 ### 3. **优化方案** - **动态分块策略**： - 引入**语义感知分块**：基于NLP模型识别段落/章节边界，避免语义割裂（参考资料1）。 - **自适应分块大小**：对技术文档采用大块（800字），对对话场景采用小块（200字）（参考资料3）。 - **多级分档检索**： 1. **初筛**：用BM25快速召回候选文档。 2. **精排**：在候选结果中执行向量检索，按相关性分档（如Top10、Top30）。 3. **融合**：按问题类型动态分配权重（如事实查询侧重BM25，推理问题侧重向量）（参考资料5、16）。 - **上下文增强**： - 增加**分块重叠率**至15%-20%，减少语义断层（参考资料1）。 - 对检索结果进行**语义去重**，避免重复片段影响LLM生成（参考资料3、5）。 ### 4. **技术落地建议** - **监控指标**：使用MRR（Mean Reciprocal Rank）评估关键信息召回位置，迭代优化权重（参考资料1、5）。 - **A/B测试**：对比动态分块 vs 固定分块在长文档场景的召回率差异（参考资料3、16）。 - **LLM辅助优化**：利用大模型自动分析问题类型，动态调整检索策略（如Agent框架）（参考资料3、6）。 > **总结**：当前混合检索通过向量+BM25融合实现分档，但存在分块*化、权重固定问题。优化方向是引入动态分块、多级分档和LLM自适应策略，提升复杂场景下的精准召回。

我的网名有毒 2026年02月07日 16:40

引用原文：用户他可能前后两次回答的问题，完全不同，这个你怎么区分

派聪明 2026年02月07日 16:40

在派聪明项目中，针对用户前后两次问题完全不同的情况，主要通过以下方式区分和处理： 1. **对话**管理**：使用Redis存储用户对话**，但设置长度上限(最多保留20条)，避免上下文信息过载导致混淆。 2. **问题语义分析**： - 对每个新问题进行向量化处理，与**问题向量计算相似度 - 当相似度低于阈值时，判定为全新话题，清空相关**上下文 - 保留必要的系统级指令(如引用格式要求)和用户**** 3. **检索策略调整**： - 对于语义跨度大的问题，增加向量检索权重，降低关键词检索比重 - 采用"问题分类+定向检索"策略，识别问题类型(事实/分析/创意等)后匹配相应知识库 4. **Prompt设计**： - 在提示词中明确区分"引用材料"和"用户问题"，使用特殊标记`<<REF>>`隔离上下文 - 对跨度大的问题，在prompt中添加"请基于以下知识库内容回答"等**语 - 设置"若检索内容不相关，请告知"的兜底指令 5. **会话状态重置**： - 当检测到话题切换时，自动重置会话状态，但保留用户权限等元数据 - 对多轮对话中突然转向的问题，采用"主题漂移检测"机制，必要时启动新会话这种设计确保了即使问题跨度大，系统仍能准确区分上下文，提供精准回答。

水竹鼠 2026年02月07日 16:29

引用原文：向量化的数据有做处理吗？

派聪明 2026年02月07日 16:29

根据参考资料中的项目描述，**向量化的数据未进行额外处理**，具体说明如下： 1. **存储方式** 向量数据由阿里embedding模型生成后，直接存入ElasticSearch的`dense_vector`字段（参考资料1、5、7）。例如： ```plaintext 字段名：vector 类型：dense_vector 维度：2048（与模型匹配） ``` 2. **检索逻辑** - 用户提问时，问题通过相同embedding模型转换为向量（参考资料1）。 - 在ElasticSearch中执行**KNN相似度检索**（参考资料1、13），直接比较向量距离（如余弦相似度），未对向量进行归一化或降维处理（参考资料13提到维度灾难但未采用降维方案）。 3. **分块与向量的关联** 文档分块（chunk）后生成向量，但分块策略（语义边界+重叠）仅影响向量生成的上下文完整性，未对向量数据本身做优化（参考资料1、5）。 4. **技术选型依据** 项目选择直接存储原始向量，原因包括： - **模型兼容性**：向量维度需与embedding模型严格匹配（参考资料1）。 - **检索效率**：ElasticSearch原生支持KNN检索，无需额外处理（参考资料7、13）。 - **避免信息损失**：降维可能丢失语义信息，而原始向量能保留更多细节（参考资料13）。 **结论**：项目中的向量数据为embedding模型输出的原始2048维向量，未进行归一化、降维或其他预处理，直接用于ES的语义检索。

水竹鼠 2026年02月07日 09:50

引用原文：为什么 Spring Boot 3.x 要用 Java 17+的版本？项目里用了哪些新特性？

派聪明 2026年02月07日 09:50

Spring Boot 3.x要求Java 17+版本的主要原因： 1. Java 17是**支持(LTS)版本，提供更好的稳定性和**支持 2. 全面拥抱Java新特性，如模块系统、Pattern Matching等 3. 性能提升和安全性增强 4. Spring团队决定紧跟Java主流版本项目中使用的Java新特性(基于Spring Boot 3.x特性)： - Records简化数据类定义 - Pattern Matching for switch表达式 - Sealed Classes限制继承 - Text Blocks(字符串块文本)简化多行字符串 - 新的HTTP**端API - 可能使用虚拟线程(Project Loom) (注：参考资料中未明确列出项目具体使用的Java新特性，以上是基于Spring Boot 3.x和Java 17特性的推断)

水竹鼠 2026年02月06日 11:54

引用原文：提示词做了哪些优化？如果多轮对话关联性不强，怎么抓住新问题的重点？

派聪明 2026年02月06日 11:54

根据提供的参考资料，针对提示词优化及多轮对话关联性问题的解决方案如下： --- ### **提示词优化措施** 1. **系统规则前置** - 在提示词开头明确声明关键规则（如：必须标注引用编号、无结果需礼貌告知），约束模型行为。 2. **语义隔离** - 检索结果用特殊符号包裹（如 `<<REF>>...<<END>>`），明确区分用户问题与知识库内容，避免混淆。 3. **引用标注机制** - 为每个知识片段分配临时编号（如 `[1]`），强制模型在回答时使用“来源#1”格式标注，增强可追溯性。 4. **空结果兜底** - 当检索结果为空时，设置特殊标记（如“（本轮无检索结果）”），**模型避免编造答案。 5. ****对话管理** - 通过Redis存储最近20条对话**，超限自动裁剪，控制上下文长度并保持性能。 --- ### **处理多轮对话关联性不强的问题** 1. **上下文隔离设计** - 即使**对话关联性弱，通过符号分隔（如 `<<REF>>`）强制模型区分“当前问题”与“**内容”，避免被不相关**干扰。 2. **问题重定向机制** - 在提示词中明确要求模型聚焦当前问题： > “若检索结果与当前问题无关，请忽略**对话，基于知识库或自有知识作答。” 3. **动态上下文裁剪** - 超过长度限制时，优先保留最近对话，裁剪旧**，确保模型关注最新交互。 --- ### **核心逻辑总结** | **场景** | **解决方案** | |------------------------|-----------------------------------------------------------------------------| | **提示词优化** | 规则前置 + 语义隔离 + 引用标注 + 空结果兜底 + **管理 | | **多轮对话关联性弱** | 上下文符号隔离 + 问题重定向指令 + 动态**裁剪 | 通过结构化提示词和上下文隔离机制，模型能精准区分不同阶段的问题，即使**对话不相关，也能聚焦当前需求生成答案。

阿琳 2026年02月04日 15:30

引用原文：向量文件如何存储在 es 里面？

派聪明 2026年02月04日 15:31

在ElasticSearch中，向量文件（实际是文本块的向量表示）通过以下方式存储： ### 1. **索引结构** - **索引名称**：`knowledge_base` - **核心字段**： - `textContent`（`text`类型）：存储原始文本内容，使用`ik`中文分词器，支持关键词检索（BM25/Match查询）。 - `vector`（`dense_vector`类型）：存储2048维向量（与阿里embedding模型匹配），用于KNN向量检索。 - 权限字段：`userId`（用户隔离）、`orgTag`（**标签）、`isPublic`（是否公开）。 ### 2. **数据流程** 1. **文本分块**：文档按语义边界切分为500字以内的块（含10%重叠）。 2. **向量化**：调用阿里embedding模型将文本块转换为2048维向量。 3. **存入ES**：文本块存入`textContent`，向量存入`vector`，权限信息存入对应字段。 ### 3. **检索原理** - **用户提问** → 转为向量 → 在ES中执行混合检索： - **语义检索**：通过`vector`字段用KNN算法计算相似度。 - **关键词检索**：通过`textContent`字段用BM25算法匹配关键词。 - **结果融合**：将两种检索结果加权排序，取Top-K上下文输入LLM生成答案。 ### 4. **关键设计** - **向量维度匹配**：确保ES的`dense_vector`维度与embedding模型输出一致（2048维）。 - **权限隔离**：通过`userId`/`orgTag`实现多租户数据隔离。 - **分词优化**：`textContent`使用`ik`分词器提升中文关键词检索效果。 > **注**：ES不存储原始文件，仅存储文本块及其向量表示。原始文件通过MinIO持久化，Kafka异步触发向量化流程后存入ES。