1. 项目概述与转型心路作为一名干了八年Java的老兵最近终于下定决心要往AI这个深水区里扎一扎。说实话转型这事儿心里挺没底的。过去八年我的世界是Spring Boot、MyBatis、微服务、JVM调优代码逻辑清晰问题边界明确。而AI尤其是大语言模型LLM和RAG检索增强生成这一套感觉像是另一个次元的东西充满了“炼丹”的玄学色彩。但趋势摆在这儿不学不行。我给自己定了个小目标第一周不搞虚的就动手从零搭建一个能实际跑起来的RAG文档问答系统。前面四天磕磕绊绊搞定了环境、基础概念和LangChain框架的初体验这第五到第七天才是真正见真章的时候——要把核心的检索增强流程给打通。这个“RAG文档问答系统”到底是个啥简单说它就像一个超级智能的图书管理员。你有一堆非结构化的文档比如公司内部的PDF手册、Word报告、网页文章当用户用自然语言提问时例如“我们公司今年的差旅报销政策有什么新变化”系统不会像传统搜索引擎那样只返回关键词匹配的文档列表而是会1. 从你的文档库中精准找到与问题最相关的文本片段2. 将这些片段作为“参考依据”或“上下文”连同用户的问题一起提交给大语言模型3. 让大模型基于这些可靠的上下文生成一个准确、可靠的答案。整个过程的核心价值在于既利用了LLM强大的理解和生成能力又通过检索环节约束了其“信口开河”的倾向让答案有据可查特别适合知识库、智能客服、内部助手这类对准确性要求高的场景。接下来这三天Day 5-7我的核心任务就是实现这个“检索”与“增强生成”的闭环。主要会围绕几个关键技术点展开文档的向量化Embedding、向量数据库的选型与使用我选了ChromaDB、检索策略的实现以及最后用LangChain把整个流程串起来。我会以一个Java开发者的视角记录下从“零AI基础”到“跑通第一个RAG Pipeline”的全过程包括每一步的代码、踩过的坑以及那些只有动手做了才能体会到的细节。2. 核心组件深度解析Embedding与向量数据库在真正动手写代码之前必须把几个核心概念和组件吃透。RAG的基石一是Embedding模型二是向量数据库。这两者配合才能完成从文本到可计算空间再到高效检索的魔法。2.1 Embedding模型把文字变成“数学点”你可以把Embedding理解为一个“文本编码器”。它把一段文字无论是一个词、一句话还是一整段转换成一个固定长度的数字列表也就是向量。这个向量在高维空间比如768维、1024维中代表了这个文本的“含义”。语义相近的文本它们的向量在空间里的距离通常用余弦相似度衡量就会很近。为什么是Embedding而不是关键词匹配这是RAG超越传统搜索的关键。比如用户问“如何喂养一只小猫”你的文档里可能写的是“幼猫的饲养指南”。关键词匹配“喂养” vs “饲养”可能效果不佳但好的Embedding模型能将这两个问题在语义空间里映射到非常接近的位置从而实现精准检索。模型选型实战我为什么选BGE开源Embedding模型很多像text-embedding-ada-002OpenAI、all-MiniLM-L6-v2、bge系列等。经过一番调研我选择了BAAI/bge-small-zh-v1.5。理由很实在对中文友好我的文档和问答场景以中文为主BGE是智源研究院开源的中文语义理解能力经过专门优化实测效果比一些通用英文模型好很多。尺寸与性能平衡bge-small模型体积相对较小加载和推理速度快对于我这种本地开发、资源有限的环境非常合适。它提供768维的向量在精度和效率之间取得了很好的平衡。社区活跃BGE系列在中文社区接受度高遇到问题容易找到资料和解决方案。一个关键的踩坑点模型加载与OOM在Java环境中通过Deep Java Library (DJL) 或 ONNX Runtime 来加载这类PyTorch模型时最容易遇到的就是OutOfMemoryError。这不仅仅是堆内存Heap的问题更是本地内存Native Memory的问题。模型本身、推理过程中的中间张量都会消耗大量的本地内存。注意如果你的应用在加载Embedding模型时崩溃报错java.lang.OutOfMemoryError: insufficient memory请首先检查你的JVM启动参数。除了常见的-Xmx堆内存必须设置-XX:MaxDirectMemorySize直接内存上限例如-XX:MaxDirectMemorySize2G来应对Native Memory的消耗。同时确保你的物理内存足够。2.2 向量数据库ChromaDB的入场理由检索的本质就是在存入的所有文档向量中快速找到与问题向量最相似的那几个。用传统关系型数据库做向量相似度计算效率是灾难级的。这就需要专门的向量数据库。为什么是ChromaDB在Milvus、Pinecone、Weaviate、Qdrant等一众选手中我选择ChromaDB作为起步原因如下极致简单开箱即用ChromaDB的设计哲学就是简单。它可以直接运行在内存中也可以持久化到磁盘。对于原型验证和小型项目你几乎不需要任何额外的基础设施比如独立的服务进程一个Python包或通过其HTTP客户端就能搞定。这大大降低了初期学习和部署的复杂度。与LangChain生态无缝集成LangChain对ChromaDB的支持是第一梯队的提供了非常简洁的封装几行代码就能完成集合创建、文档插入和相似性搜索让我能更专注于流程逻辑而不是底层API。足够轻量适合学习它的功能聚焦于核心的向量存储和检索没有那么多企业级特性带来的认知负担。作为学习RAG的第一个向量数据库它能让我快速建立起“存入-检索”的直观感受。关于“ChromaDB默认的距离函数”距离函数决定了如何计算向量之间的“相似度”。常见的有关欧几里得距离L2和余弦相似度。ChromaDB默认使用余弦相似度。这对于文本Embedding来说是更合适的选择因为余弦相似度关注的是向量的方向而非大小能更好地衡量语义上的相似性。在大部分情况下你不需要更改这个默认设置。3. 实战构建RAG Pipeline的完整实现理论清楚了开始动手。我将用Day 5到Day 7的时间分步构建整个系统。这里我会用Python作为实现语言因为它有最丰富的AI库生态但我会以Java工程师的思维来理解每一步并思考未来如何与Java后端集成。3.1 Day 5文档处理与向量化入库目标将一堆原始PDF/TXT文档处理成一段段文本转化为向量存入ChromaDB。第一步环境与依赖准备创建一个干净的Python虚拟环境安装核心包pip install langchain langchain-community langchain-chroma pypdf sentence-transformers这里sentence-transformers库让我们能方便地使用BGE等Embedding模型。第二步文档加载与分割Text Splitting这是至关重要的一步直接决定检索质量。你不能把整本100页的PDF作为一个向量存进去那样检索出来的“相关片段”可能仍然包含大量无关信息。from langchain_community.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter # 1. 加载文档 loader PyPDFLoader(./docs/公司手册.pdf) documents loader.load() # 2. 分割文档 text_splitter RecursiveCharacterTextSplitter( chunk_size500, # 每个文本块的最大字符数 chunk_overlap50, # 块与块之间的重叠字符数避免上下文断裂 separators[\n\n, \n, 。, , , , , ] # 按优先级分割 ) split_docs text_splitter.split_documents(documents) print(f原始文档页数{len(documents)} 分割后文本块数{len(split_docs)})实操心得chunk_size和chunk_overlap是“艺术”chunk_size500对于中文500个字符大约是一段到两段文字。太小会丢失上下文太大会引入噪声。需要根据你的文档类型技术文档段落长对话记录段落短和模型上下文窗口来调整。chunk_overlap50重叠部分保证了即使分割点在不恰当的位置比如一句话中间关键信息也能在相邻块中保持连续这对后续检索的连贯性很有帮助。这是一个容易被忽略但极其重要的参数。第三步初始化Embedding模型与向量库from langchain_chroma import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings # 1. 初始化Embedding模型 model_name BAAI/bge-small-zh-v1.5 model_kwargs {device: cpu} # 如果没有GPU就用CPU encode_kwargs {normalize_embeddings: True} # 归一化方便计算余弦相似度 embeddings HuggingFaceEmbeddings( model_namemodel_name, model_kwargsmodel_kwargs, encode_kwargsencode_kwargs ) # 2. 初始化ChromaDB向量库并一次性添加所有分割后的文档 # persist_directory 指定持久化目录如果为空则仅在内存中 vectorstore Chroma.from_documents( documentssplit_docs, embeddingembeddings, persist_directory./chroma_db # 数据将保存到此目录 ) print(文档向量化并存入ChromaDB完成)这个过程可能会比较耗时取决于文档数量和模型速度。看到进度条走完你的知识库就算建好了。3.2 Day 6实现检索与问答链目标根据用户问题从向量库中检索相关文本块并组合成提示词交给LLM生成答案。第一步相似性检索# 接上一天的代码或加载已持久化的向量库 # from_documents 会创建新的collection如果已存在会报错。加载用以下方法 # vectorstore Chroma(persist_directory./chroma_db, embedding_functionembeddings) query 今年的年假政策是怎么规定的 # 检索最相关的3个文本块 retrieved_docs vectorstore.similarity_search(query, k3) print(f检索到 {len(retrieved_docs)} 个相关片段) for i, doc in enumerate(retrieved_docs): print(f\n--- 片段 {i1} ---) print(doc.page_content[:200] ...) # 打印前200字符关键参数k它决定了返回多少个相关片段。k太小信息可能不全k太大会引入无关信息并增加LLM的上下文长度负担。一般从3-5开始调整。第二步构建提示词模板与问答链单纯的检索并显示片段不是终点我们要让LLM来消化这些片段并生成友好答案。这里用到LangChain的RetrievalQA链。from langchain.chains import RetrievalQA from langchain_community.llms import Ollama # 假设使用本地运行的Ollama Qwen模型 # 也可以使用OpenAI API: from langchain_openai import ChatOpenAI # 1. 初始化LLM # 使用本地模型例如Qwen2.5 llm Ollama(modelqwen2.5:7b, temperature0.1) # temperature调低让答案更确定、更基于上下文 # 2. 创建RetrievalQA链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 最常用的类型将所有检索到的文档“塞”进提示词 retrievervectorstore.as_retriever(search_kwargs{k: 3}), return_source_documentsTrue, # 是否返回源文档便于调试 verboseTrue # 打印链的详细执行过程学习时非常有用 ) # 3. 进行问答 result qa_chain.invoke({query: query}) print(\n 生成的答案 ) print(result[result]) print(\n 参考来源 ) for doc in result[source_documents]: print(f- {doc.metadata.get(source, N/A)} (Page {doc.metadata.get(page, N/A)}))chain_type的选择stuff是最简单直接的方式适合检索片段总长度不超过LLM上下文窗口的情况。如果文档很长可以考虑map_reduce或refine等更复杂但能处理长文档的链类型。3.3 Day 7优化、调试与系统集成思考系统能跑起来了但作为一个有追求的工程师不能止步于此。第七天我聚焦在优化效果和思考工程化上。优化一优化检索——重排序Re-ranking初版检索用的是简单的向量相似度similarity_search。但有时向量相似度最高的片段未必是回答这个问题最相关的片段。这时可以引入一个“重排序”模型对初步检索出的Top K个结果进行二次打分和排序。# 这是一个概念性示例LangChain有相关的重排序集成 # 1. 先用向量库检索出较多的候选例如 k10 base_docs vectorstore.similarity_search(query, k10) # 2. 使用一个交叉编码器Cross-Encoder模型对 (query, doc) 对进行相关性评分 # 3. 根据评分重新排序取Top 3作为最终上下文重排序模型如BGE-reranker计算量比Embedding模型大但精度提升显著。这是一种“召回后精排”的思路在效果要求高的场景值得引入。优化二优化回答——提示词工程默认的RetrievalQA链的提示词可能不够好。我们可以自定义引导LLM更好地利用上下文。from langchain.prompts import PromptTemplate custom_prompt PromptTemplate( input_variables[context, question], template请严格根据以下提供的上下文信息来回答问题。如果上下文信息不足以回答问题请直接说“根据已知信息无法回答此问题”不要编造信息。 上下文信息 {context} 问题{question} 请给出答案 ) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(), chain_type_kwargs{prompt: custom_prompt}, # 使用自定义提示词 return_source_documentsTrue )这个提示词明确指令了LLM要基于上下文并对未知问题做了约束能有效减少“幻觉”。调试与排查实录在开发过程中我遇到了几个典型问题问题运行similarity_search时报错“No embedding model is loaded. Set rag_embedding_model to a valid sentence_transformers model.”排查这个错误信息很明确。检查创建Chroma向量库时传入的embedding参数是否正确初始化。确保HuggingFaceEmbeddings模型名称正确且网络通畅首次运行需要下载模型。解决确认embeddings对象已成功创建。可以简单测试一下test_vec embeddings.embed_query(hello)看是否能正常生成向量。问题答案明显胡编乱造与提供的上下文无关。排查首先检查检索到的source_documents是否真的与问题相关。打印出来看看。如果不相关问题出在检索环节可能是Embedding模型不适合你的领域或者chunk_size设置不合理导致文本块语义破碎。如果相关但LLM还是乱答问题出在生成环节可能是LLM的temperature参数太高或者提示词没有强制要求它基于上下文。解决针对检索问题尝试更换Embedding模型或调整文本分割策略。针对生成问题使用上面提到的自定义提示词并降低temperature。从Python原型到Java集成的思考作为Java开发者最终肯定希望核心服务用Java来写。目前的探索路径是Python侧作为“AI能力层”专注于模型推理Embedding, Reranking, LLM和向量检索。可以封装成独立的HTTP服务使用FastAPI提供/embed,/search,/ask等端点。Java侧作为“业务逻辑层”处理用户请求、业务规则、数据持久化等。通过HTTP客户端调用Python服务提供的AI能力。协同文档处理、向量入库等离线任务可以用Python脚本完成将构建好的向量数据库如ChromaDB的持久化目录作为共享资产。Java服务在线查询时通过Python服务访问这个数据库。这种解耦架构让Java团队可以专注于熟悉的业务开发而AI部分的迭代优化由专门的团队或你自己在Python侧完成两者通过清晰的API契约进行交互。4. 一周总结与避坑指南回顾这从零开始的七天最大的感触是AI开发尤其是RAG是一个高度工程化的实践。它不像学习一门新语言或框架更像是在搭建一个精密的管道系统每个环节的细节都影响着最终出水的水质。给同样想转型的Java开发者的建议心态转变拥抱不确定性别再追求像Java世界里那种“一次编译到处运行”的确定性。AI模型的效果有概率性需要大量实验、评估和调优。接受这种不确定性用AB测试和评估指标来说话。动手优于空想RAG的概念看十遍不如动手搭一遍。从最简单的stuff链开始先让整个流程跑通获得正反馈再逐步深入优化每个模块。重视数据预处理文本分割Text Splitting是RAG系统中被低估但至关重要的一环。糟糕的分割会毁掉最好的模型。多花时间在这里尝试不同的chunk_size和separators观察对检索结果的影响。调试是核心能力RAG的调试是链式的。答案不好要沿着链路反向排查是LLM生成了垃圾还是检索的上下文是垃圾还是文本分割时就产生了垃圾学会使用verboseTrue、打印中间结果检索到的文档来定位问题。从简单工具开始像我一样从ChromaDB、LangChain这些对开发者友好的工具开始快速建立认知。不要一开始就追求大而全的架构。等理解了核心原理再根据实际需求评估是否需要迁移到Milvus、Weaviate等更强大的向量数据库或者更底层的框架。第一周只是一个开始。这个简单的系统还有巨大的优化空间引入更智能的文档解析处理表格、图片、实现多路检索关键词向量混合搜索、增加对话历史变成多轮问答、建立系统的评估体系用BLEU、Rouge或人工评估答案质量等等。但最重要的是我跨出了从零到一的第一步亲手摸清了RAG的每一根管道。对于一个习惯了Spring MVC的Java程序员来说这周在Jupyter Notebook里和向量、提示词打交道的经历无疑是打开了一扇新世界的大门。接下来的路还长但至少我知道下一个坑大概会在哪儿了。