目前能做到:用户把文档丢进来,系统能把文字和图片里的内容全拆出来,变成结构化知识,做向量化后存进向量库,能在会话里记住上下文、支持多轮问答,还能按流程回溯状态。这套东西跑起来后,就成了企业做知识库和智能问答的一个可落地方案。

把这个结论往回拆开说。刚才说的“能记住上下文、支持回溯”,靠的是流程编排和状态管理模块。整个系统用了一种“状态机 + 条件分支”的模式来组织业务:每一步都有清晰的节点(node),节点之间按条件流转,可以保存中间结果,也能在必要时回溯到某个状态。LangGraph4j 就是用来做这件事的,它负责把不同的流程节点串起来,管条件判断,管状态存取。用这种方式,文档入库和问答两条主流程可以并行也可以根据条件分支走不同路径。
再往前看,系统把工作拆成了两大流程:一条是把文档处理进来并入库,另一条是问答流程。文档入库流程负责接收 PDF、Word、Markdown,拆文字、识别图片里的文字,把结果做向量化、存储索引,并把元信息写到关系型存储。问答流程负责把用户的问题转成检索指令,从向量库拿出类似片段,结合上下文、状态机的指引,调用大模型生成回答,回答的生成和检索过程都能被记录到全局状态里,以便多轮查询使用或者回溯。

关于具体怎么实现每一步,系统里有一套基于 Spring AI 的工具接口,把文档解析、知识抽取、向量生成、类似性检索这些能力封成“工具”。流程节点去调用这些工具,工具返回的中间结果统一丢到一个全局状态类里保存,既当作短期缓存,也方便流程控制。每个角色(像解析器、向量入库器、检索器、回答器)都被实现成一个流程节点,通过 LangGraph4j 的 Node 接口去挂上去,节点之间的条件流转配置清楚了,复杂场景也能拆得清楚。
文件解析这块用的是 Apache Tika,负责把多种格式的文档取文本。文档里如果有截图或图片,Tesseract OCR 来识别图片文字。识别完的文本喂给 Spring AI 去做向量嵌入和大模型调用,向量保存到 Pinecone 或 Qdrant 之类的向量数据库,作为类似性检索的基础。文档的元数据(上传人、时间、标签)又写到关系型数据库,通过 Spring Data JPA 管理。
为了支撑 Web 接口和测试,项目整体基于 Spring Boot 来做骨架,接口文档用 Swagger 或 knife4j 展示。Redis 用来缓存会话上下文、临时文件路径等快速访问的数据,Hutool 当工具类库用来处理一些文件和字符串的常见操作。版本方面,实践里提议的组合是:Spring Boot 3.2.x,Spring AI 1.0.0+,LangGraph4j 0.1.0+,Apache Tika 2.9.x,Tesseract OCR 5.3.x,向量库选 Pinecone 或 Qdrant 的最新稳定版,Spring Data JPA 3.2.x,Redis 7.0+,Hutool 5.8.x,Swagger/knife4j 保持最近稳定版本。这些版本只是提议,关键是兼容性和稳定性优先。
从用户交互角度来讲,系统提供了几个 HTTP 接口:上传文档的接口、智能问答接口、以及清空对话上下文的接口。用户把文档传上来后,后端会先做解析(Tika + OCR),把文本切片,调用嵌入工具生成向量,向量入库同时写入元数据;问答时会先做向量检索把相关段落找出来,再把这些证据和用户问题一并投给大模型去生成答案。整个过程的中间结果都可追溯,由于全局状态保存了每一步的输入输出。
实现过程里有几个细节值得注意。第一,文档解析不是简单“文本抽取”,需要做格式适配和文本清洗,像表格、脚注、代码块都要特殊处理,不然传给嵌入模型的内容噪声大,检索效果差。第二,OCR 的准确率直接影响知识质量,图片里字体、压缩痕迹、旋转这些都能引起识别错误,需要预处理和后处理流程来纠偏。第三,向量化策略要跟检索场景相匹配,短段落的切分长度、是否保留上下文窗口,会影响召回和准确度。第四,流程编排层必须能处理异常和回退,列如某一步失败要能重试,或回到上一个稳定状态继续流程,这样用户体验才不会断裂。LangGraph4j 在这几个场景里提供了符合预期的分支控制和状态回溯能力。
部署和运维方面,向量库选用云服务还是本地部署要看企业合规和成本;像 Pinecone 方便上手但会有外部依赖,Qdrant 更适合本地化部署。Redis 负责会话级缓存,减少重复计算,Spring Data JPA 管理元数据方便做审计和按时间查询。接口文档要做好,Swagger/knife4j 可以让前端和测试人员快速调通流程。要注意权限和审计链路,谁上传了哪个文档、谁做了什么查询,这些日志都要落地。
把这些模块拼起来看,核心是两部分能力:一是把碎片化、多格式的企业文档变成结构化、可检索的知识;二是把多轮对话和业务流程用可控的状态机来串联,保证问答既能利用历史上下文,又能按条件分支去不同处理路径。把这两条线做好,马上就可以把一个静态的文档库变成能被业务人员随时问答的“活”知识库。说起来这一套不算复杂,但真要把每个环节打磨好,还是得花不少功夫。