TraceRAG从功能型 Demo 到面试级项目我的企业技术文档知识库问答系统设计很多 RAG 项目都会被概括成一句话上传文档切分文本写入向量库再让大模型回答问题。这类项目可以证明自己会使用 LangChain、Milvus 和大模型 API但在面试中很容易陷入同质化。因为绝大多数候选人都能完成“文档上传 向量检索 问答”的基础闭环。因此我没有把项目定位为泛化的“知识库问答系统”而是将其定位为TraceRAG一个面向企业技术文档的可观测、可追踪、可优化的 RAG 知识库问答系统。系统面向产品手册、技术说明书、论文、复杂 PDF 等非结构化资料提供从文档导入、解析、切分、混合检索、答案生成到会话历史管理的完整能力并重点关注 RAG 在企业落地过程中的可维护性、可解释性和可评测性。一、项目背景企业内部往往积累了大量 PDF、产品说明书、操作手册、技术规范和历史文档。这些资料存在几个典型问题文档格式复杂包含标题、表格、图片和多栏排版信息分散员工需要花费大量时间查找同一产品可能有多个名称、别名或型号传统关键词搜索难以理解自然语言问题直接让大模型回答容易出现幻觉也无法引用知识来源。因此项目目标并不是简单“接入一个聊天机器人”而是构建一套能够将企业文档转化为可检索知识并通过检索增强生成RAG提供可信回答的系统。二、项目定位与核心特色相比“功能全面的知识库问答系统”TraceRAG 的定位更明确面向复杂技术文档的、具备检索增强、链路追踪、故障降级和效果评测能力的企业级 RAG 系统。项目的设计重点可以归纳为三层。第一层基础 RAG 能力 文档上传 - 解析 - 切分 - 向量化 - 入库 - 问答 第二层检索增强能力 主体识别 - 普通检索 - HyDE - RRF 融合 - Reranker 重排 第三层企业化演进能力 会话历史 - 资源存储 - 任务状态 - 故障降级 - 观测与评测其中第三层是项目区别于普通 RAG Demo 的关键也是后续重点建设的方向。三、当前已实现功能1. 知识导入将复杂文档转化为可检索数据目前系统支持 PDF 和 Markdown 文档导入完整导入链路如下上传文档 - MinerU 解析 PDF - 转换为 Markdown - 图片提取并上传 MinIO - 文档切分为 Chunk - 识别文档或产品名称 - 生成 BGE-M3 稠密/稀疏向量 - 写入 Milvus已实现能力包括支持上传 PDF、Markdown 文档使用 MinerU 将 PDF 解析为 Markdown解析文档中的图片并上传至 MinIO将长文档切分为可检索的 Chunk自动识别文档名、产品名或实体名称使用 BGE-M3 生成稠密向量和稀疏向量将知识内容写入 Milvus 的kb_chunks集合将文档或产品名称写入kb_item_names集合为后续主体识别和过滤提供支持。这里的设计并不是直接对 PDF 原文粗暴切分而是先完成结构化解析再进行文本处理。这样可以为后续保留标题层级、图片引用和文档来源打下基础。2. 知识检索构建多路召回与重排链路用户提问后系统不会只做一次向量检索而是构建了多阶段检索流程用户问题 - 历史上下文改写 - 文档/产品主体识别 - 普通向量检索 - HyDE 增强检索 - 联网检索按需 - RRF 融合 - Reranker 重排 - 基于上下文生成答案已实现的核心能力包括根据用户问题识别关联文档、产品或实体根据历史会话改写上下文不完整的问题使用 BGE-M3 进行普通向量检索使用 HyDEHypothetical Document Embeddings增强召回支持多路检索结果通过 RRF 融合使用 Reranker 对候选文档进行二次排序基于高相关度 Chunk 生成最终答案支持在需要时接入 WebSearch MCP 补充外部信息。这条链路体现了项目对检索质量的关注。普通 RAG 往往是“问题 - 检索 - 生成”而本项目通过主体识别、多路召回、融合和重排尽量提高进入模型上下文的信息质量。3. 对话与流式输出能力系统具备基础会话能力MongoDB 保存用户问题、助手回答、关联文档和图片链接支持多轮对话上下文支持会话历史查询与管理支持 SSE 流式输出用户无需等待完整答案生成即可看到回答逐步返回。在实际体验中流式输出不一定降低模型总生成耗时但可以显著改善首字等待时间和交互感受。4. 外部服务与技术栈项目当前涉及的核心组件如下组件作用LangGraph编排导入与查询工作流FastAPI提供上传、问答、SSE 等 HTTP 接口Milvus存储向量与执行知识检索MongoDB保存会话历史与问答记录MinIO存储上传文件和解析出的图片资源MinerU解析复杂 PDF 文档阿里百炼 / Qwen提供大模型能力BGE-M3生成稠密向量与稀疏向量Reranker对召回结果进行相关性重排WebSearch MCP补充联网搜索能力四、系统主链路如何讲清楚面试时不需要从所有代码讲起而要优先讲清楚两条核心链路。1. 文档导入链路上传文档 - PDF 解析为 Markdown - 图片资源上传对象存储 - 文本切分 - 文档/产品名识别 - BGE-M3 向量化 - 写入 Milvus可以这样描述用户上传 PDF 后系统会调用 MinerU 将复杂 PDF 解析为 Markdown并将文档中的图片上传到 MinIO。随后按照 Chunk 策略切分文本提取文档或产品名称再通过 BGE-M3 生成稠密和稀疏向量最终写入 Milvus形成可检索的知识库。2. 用户问答链路用户提问 - 历史上下文改写 - 主体识别 - 向量检索 / HyDE 检索 - RRF 融合 - Reranker 重排 - 大模型生成答案 - 保存会话历史并 SSE 返回可以这样描述用户提问后系统先结合多轮历史改写问题再识别问题关联的产品或文档范围。检索阶段同时使用普通向量检索和 HyDE 检索通过 RRF 融合多个召回通道再使用 Reranker 进行精排最后将高相关度上下文交给大模型生成答案并保存完整对话记录。五、当前项目与面试级项目之间的差距目前项目已经具备完整 RAG 主链路不再是单纯的玩具 Demo。但如果希望在面试中体现更强的工程能力还需要补齐以下部分。1. 工程化部署不够完整当前项目仍较依赖本地环境、模型路径和外部服务地址新成员启动成本较高。主要缺口缺少统一的 Docker Compose缺少一键启动脚本.env配置项较多且缺少标准示例本地模型路径、远程服务地址依赖较强缺少环境检查与依赖健康检查。优化方向Docker Compose - Milvus - MongoDB - MinIO - API 服务 - 可选的模型服务 .env.example README 启动手册 健康检查接口 初始化脚本2. 稳定性与任务治理仍需加强MinerU、WebSearch、Reranker、LLM 服务都可能发生超时、鉴权异常或临时不可用。当前项目已具备部分降级思路但仍可继续完善为外部服务增加统一超时和重试策略对可降级能力建立明确的 fallback 路径为导入任务建立可靠状态机支持任务失败后的重试、恢复和人工干预对非幂等写入操作增加幂等控制记录失败阶段、失败原因和重试次数。建议的导入任务状态如下PENDING - PARSING - SPLITTING - EMBEDDING - INDEXING - SUCCESS 任意阶段 - FAILED - RETRYING3. 缺少完整的可观测性体系目前有日志但仍缺少真正的全链路观测能力。理想状态下每一次问答请求都应该能够追踪trace_id - 问题改写耗时 - 主体识别耗时 - 向量检索耗时 - HyDE 检索耗时 - RRF 融合耗时 - Reranker 耗时 - LLM 首 Token 时间 - 总 Token 用量 - 总响应耗时 - 错误与降级信息建议后续接入LangSmith追踪模型调用与 LangGraph 执行路径OpenTelemetry统一链路追踪协议Prometheus采集指标Grafana建立延迟、错误率、Token、任务状态看板。这是 TraceRAG 最值得强化的个人特色不仅让系统回答还能解释系统是如何得出回答的。4. 缺少数据驱动的 RAG 评测体系很多 RAG 项目都会说“我加了 HyDE、RRF 和重排”但面试官通常会继续追问这些策略真的有效吗提升了多少如果没有评测集和实验数据很难给出可信答案。建议构建 20 到 50 条标准问题覆盖精确事实问答产品型号与参数问题操作步骤问题多轮追问问题无答案问题易产生幻觉的问题。评测指标可包括指标含义RecallK正确文档是否出现在前 K 个召回结果中MRR正确结果的平均排名Context Precision进入模型上下文的内容有多少真正相关答案准确率回答是否正确覆盖关键事实幻觉率回答是否出现无依据内容平均响应时间检索到生成的端到端耗时TTFT首个 Token 返回时间后续可以形成这样的实验对比表策略Recall5答案准确率平均耗时普通向量检索待测待测待测普通检索 Reranker待测待测待测HyDE RRF Reranker待测待测待测这样项目优化过程就从“凭感觉调参”变成“由数据驱动的检索策略选择”。5. 知识库管理能力不足当前系统更接近单知识库原型距离企业知识资产管理平台还可以继续扩展。后续可以补充文档列表与详情页文档导入进度与任务状态删除文档及关联向量文档更新与重新索引文档版本管理多知识库隔离按部门、角色、用户控制权限检索阶段基于 Metadata 进行权限过滤。这部分能体现后端工程和企业业务建模能力而不仅仅是 AI 调用能力。6. 检索策略还有优化空间当前系统已经具备普通检索、HyDE、RRF、Reranker 等能力但检索质量仍值得持续优化。后续可尝试父子 Chunk 检索保留标题层级的 Section-aware Retrieval多查询扩展Query ExpansionBM25 与向量检索混合召回更完善的 Metadata Filter根据问题类型动态选择检索策略根据文档类型采用不同 Chunk 策略降低对item_name精确匹配的强依赖。例如技术手册适合按章节结构切分产品参数表适合按表格或字段切分长篇论文则可能更适合父子 Chunk 结构。7. 前端产品体验仍偏原型当前系统重点在于后端主链路可运行但企业知识库产品还可以继续完善前端体验文件上传进度导入任务状态与失败原因文档列表和知识库管理对话历史管理回答引用来源展示原始文档定位图片预览检索 Chunk 可视化用户反馈入口例如“有帮助 / 无帮助”。前端并不是项目的唯一重点但“引用来源可见”和“任务状态可见”能显著增强系统可信度。六、TraceRAG 的面试亮点应该怎么讲项目不应被包装成“我做了一个聊天机器人”而应该突出下面四个亮点。1. 复杂文档结构化处理系统面向复杂 PDF、产品手册和技术文档先通过 MinerU 解析为 Markdown再处理图片、标题和文本结构最终进行切分和向量化而不是直接把 PDF 文本粗暴切块。2. 多路检索增强在检索侧我实现了主体识别、普通向量检索、HyDE 增强检索、RRF 融合和 Reranker 重排通过多阶段检索提高召回质量与上下文相关性。3. 可追踪与可降级我重点关注 RAG 工程落地中的可观测性。后续会为每个 LangGraph 节点记录耗时、失败原因、调用次数和 Token 用量并对 MinerU、WebSearch、Reranker、LLM 等外部依赖设计超时、重试和降级机制。4. 数据驱动的效果评测我不会只凭主观感受调整 RAG 策略而是通过标准问题集对比普通检索、HyDE、RRF 和重排的 RecallK、答案准确率、响应耗时等指标形成可量化的优化闭环。七、总结TraceRAG 已经完成了从文档导入到智能问答的核心闭环上传文档 - 解析 - 切分 - 向量化 - Milvus 入库 用户提问 - 主体识别 - 多路检索 - 融合重排 - 大模型生成 - 保存历史与流式输出它当前已经具备功能型 RAG 项目的完整能力。下一阶段的重点不是盲目增加更多模型或工具而是围绕以下方向持续建设可观测可评测可降级可部署可管理可扩展。当系统能够清楚回答“答案来自哪里、哪一步耗时最多、哪种检索策略提升了多少、外部依赖失败后如何恢复”时它才真正具备企业级 RAG 项目的说服力。