去年出分那几天，我在帮家里一个孩子折腾志愿填报。翻投档表、查位次、核对招生章程，连续三个晚上熬到凌晨，发现真正难的不是“选学校”，而是几十万条数据根本翻不完。当时正好在折腾 Java 生态里的黑马框架 LangChain4j，顺手就用它做了个 AI 志愿填报顾问原型，把院校库、位次换算、政策问答和自然语言对话串成一条完整链路。这篇文章就是当时从零到能跑通的全过程复盘，适合那些想用 Java 做 LLM 应用、但又不想引入 Python 技术栈的开发者。志愿填报这个场景，天然适合被 AI 改造。它不是单纯问一句“我能上什么学校”就能结束的简单问答，而是需要结合考生分数、省内位次、选科组合、院校历年录取数据、招生计划变化、体检受限条款等多维度信息做判断。信息源多且分散，格式以 PDF、网页表格为主，对普通家庭来说，真正困难的是信息检索和交叉比对。这个项目把 LangChain4j 的 RAG、工具调用、记忆管理、结构化输出全部用上，最终做成一个既能聊天解释、又能精确查数的顾问式应用。1. 志愿填报顾问：这个项目到底解决什么问题1.1 高考出分后的三天，家长在慌什么志愿填报的关键窗口往往只有几十个小时，但需要处理的信息量非常大。考生拿到分数后，第一件事是把分数换算成省内位次，再拿着位次去对比目标院校过去三年的最低投档位次。这里有个最常见的坑：每年试卷难度不一样，分数线也会浮动，只看绝对分完全不靠谱，必须看位次。除了位次，还要考虑院校专业组的选科要求、身体条件限制、单科成绩要求、专业录取规则是“分数清”还是“专业级差”等等。我做过一次用户访谈，发现家长最典型的提问方式是：“孩子考了 620 分，位次大概一万名，能报哪些学校？”“XX大学的计算机专业比去年涨了多少分？”“物理组能不能报临床医学？”这些问题表面上是在问学校，实际上是要把位次、专业限制、历年数据、政策规则串起来。传统搜索工具很难回答这种复合型问题，因为答案散落在几十个网页里，需要自己判断哪条信息是当年的、哪条已经过期。1.2 LangChain4j 凭什么能接住这个需求早期我考虑过直接用 Python 的 LangChain，但项目团队一直是 Java 技术栈，为了一个小应用再引入 Python 服务和模型管理，维护成本不划算。后来看到 LangChain4j，发现它把 Java 生态缺失的那块拼图补齐了。它提供了一套清晰的分层抽象：聊天模型、嵌入模型、向量存储、消息记忆、内容检索器、工具调用、AI 服务。也就是说，在 Python LangChain 里你会用到的能力，它基本都有，而且模块划分得更直观。LangChain4j 还有一个很适合做业务系统的特性：它不强求你用某种固定流程。你可以先只接入一个 ChatModel 做问答，再慢慢加上 Memory、Retriever、Tools，每一步都是增量改造，不会推倒重来。志愿填报顾问这个项目一开始只有简单的模型调用，后来才逐步加入知识库检索和工具调用，整个演进过程非常顺。比起直接用 HTTP 裸调大模型接口，LangChain4j 省掉了我自己维护消息队列、JSON 解析和对话上下文拼接的重复工作。从项目影响范围看，这个应用可以做成微信小程序、Web 端甚至呼叫中心辅助座席。它不是一个只能演示的玩具，而是能把“查数据、做筛选、给建议”这件事做成一个可运营的服务。这也是我坚持用 Java 去做 LLM 应用的原因：团队现有的人才能直接上手，部署、监控、灰度发布都能复用已有的基础设施。2. 数据先行：把院校投档线变成 AI 能检索的格式2.1 公开数据采集与清洗做 AI 顾问最怕的不是模型不聪明，而是它没有数据。志愿填报顾问这个项目的第一步，就是先把数据仓库建起来。所有数据必须来自官方公开渠道，包括各省级招生信息发布平台、院校官网的招生章程，绝不能靠模型记忆里的“常识”来编录取数据。因为志愿填报涉及考生前途，数据和规则必须可追溯、可复核。我做的数据清洗流程一般分四步：抽取、清洗、去重、归一。原始数据很多是 PDF 或图片表格，PDF 里经常出现合并单元格、跨页断行、特殊符号，直接解析会产出大量脏数据。我的做法是先用表格解析工具把 PDF 转成结构化表格，再对每一行的院校代码、专业名称、计划数、最低分、最低位次做字段级校验。比如某所高校连续两年名称不一致的问题，就得维护一份院校别名表，把“某工业大学（XX校区）”和“某工业大学”归并成同一条记录。数据归一化是另一个容易忽略的环节。不同年份的试卷难度不同，分数没有直接可比性，所以我在数据库里同时存原始分数和对应位次。位次是判断录取概率最稳定的锚点。每一年的数据都要标明年份和省份，避免 AI 在回答中把不同省份的数据混在一起。这个步骤如果做不干净，后面一切检索和推荐都是空中楼阁。2.2 文档切分与向量化生产数据清洗完以后，会分成两条路：结构化的分数位次数据放进关系数据库，供工具调用精确查询；政策规则、专业介绍、院校说明这类非结构化文本，则切成文档片段，放进向量知识库做 RAG。为什么同一份数据要拆两份？因为功能不同。精确查询适合用 SQL，比如“位次是否达到最低投档位次”，这需要计算和比较，不能靠语言模型猜。而“什么是专业级差”“某专业的就业方向”“选科限制有哪些”这类问题，没有严格的数值计算，更适合从知识库检索段落后让模型整理成自然语言回答。文档切分是 RAG 效果的命门。切得太碎，比如几十个字一段，上下文语义不完整，检索出来的片段经常答非所问；切得太长，比如几千字一段，向量相似度会被无关内容稀释，而且塞进 Prompt 里也容易爆上下文。我测试下来，中文文本单段控制在 300 到 600 字比较合适，既能承载一个完整的招生规则条目，也不会让单次检索结果占用太多 token。切分时还要把“院校名称+年份+省份”写进元数据，检索后才能按省份、年份做过滤。向量化时，我直接用了 LangChain4j 的 EmbeddingModel 接口，统一嵌入模型生成向量。这里有个硬性要求：写入向量库和查询时用的必须是同一个嵌入模型，否则维度不匹配，相似度也没有意义。数据量大以后，内存向量库不够用，我换成了支持持久化的向量数据库，LangChain4j 对主流向量库基本都有适配。建索引时，我把同一所院校不同年份的文档片段编成同一个文档 ID，方便后续整体更新和删除。2.3 Retriever 的关键参数怎么调我用的检索器是 EmbeddingStoreContentRetriever，核心参数就两个：maxResults 和 minScore。maxResults 决定每次检索返回多少候选片段，设得太大会让 prompt 变得又长又杂，设得太小又可能丢信息。在志愿填报场景里，我默认取 5 个片段，既能覆盖多个维度，又不会让模型的注意力被冲散。minScore 是容易踩坑的地方。它是相似度阈值，低于这个值的片段会被过滤掉。一开始我设成 0.5，结果经常把毫不相关的专业介绍也捞上来，AI 就开始一本正经地胡说。后来调到 0.7，检索结果干净不少。但要注意，minScore 不是越高越好，如果知识库文档措辞和用户口语提问差异大，阈值太高会直接检索不到。我的经验是先跑一遍典型的测试问题，统计正常命中分数，再在中间值上留一点余量。另外，每次检索时我还会带上省份和年份过滤器，相当于在向量召回之前就先做一轮数据隔离，避免“某省考生问到了另一省的数据”这种尴尬错误。3. 对话层：把顾问该有的素质做出来3.1 模型参数与记忆配置AI 志愿填报顾问不是一次性问答工具，用户会进行多轮追问。比如先问“有哪些学校推荐”，再问“XX学校怎么样”，然后追问“能不能把就业情况也说说”。这种场景必须配置对话记忆。LangChain4j 里我用的是 MessageWindowChatMemory，只保留最近 20 条消息。为什么不是越多越好？因为每条历史消息都会重复计入上下文，20 条窗口大概对应 5000 到 8000 token，既能覆盖一个完整咨询流程，又不会让请求太慢、太贵。超过窗口后，较早的消息会自动淘汰，避免上下文无限膨胀。模型参数方面，我把 temperature 调到了 0.2。这个参数控制回答的随机性，温度越高，模型越“放飞”，在数据敏感的志愿填报场景里，放飞等于灾难。0.2 意味着模型在组织语言时有一点灵活性，但在数据和规则描述上基本保持稳定。还有 maxTokens，我根据回答类型设置了上限，普通问答给 800，需要返回推荐列表的给 1500，防止模型过度输出无关内容。用 LangChain4j 时，模型接入非常直接。不同模型提供商只需要换一个实现类，核心代码结构基本不变。我的配置大致是这样的：ChatLanguageModel model = OpenAiChatModel.builder() .baseUrl(System.getenv("LLM_BASE_URL")) .apiKey(System.getenv("LLM_API_KEY")) .modelName("your-model-name") .temperature(0.2) .maxTokens(1500) .build();这里 baseUrl 和 apiKey 都从环境变量读，不写死在代码里。实际选型时，我们用的是某国产模型平台提供的兼容接口，服务稳定性和中文理解能力都过关。LangChain4j 的好处是模型换起来成本低，我测试阶段换过两三个模型，只改了配置，业务代码一行没动。3.2 提示词工程的核心约束提示词是这个项目的灵魂。我见过很多 AI 应用效果差，不是模型不行，而是系统提示词没有把边界讲清楚。志愿填报顾问的 System Prompt 我写了三版，最终沉淀出四条硬性约束：第一，身份约束。AI 是“志愿填报信息顾问”，不是“录取保证人”，所有回答都只是信息整理和参考，不能承诺录取结果。第二，数据边界。回答必须基于检索到的知识库内容和工具返回的数据库结果，没有数据支撑的问题要直接说不知道，不许编造。第三，格式约束。推荐类回答必须按固定结构输出，包含院校名称、年份、最低位次、匹配判断、依据说明，方便前端渲染。第四，免责约束。最终填报决定以官方发布为准，AI 只辅助决策。Prompt 写作上有一个很实用的技巧：给模型“拒绝回答”的出口。如果你把 prompt 写得太满，模型会觉得必须给出一个答案，于是强行编数据。我在 prompt 里明确写了一句：当检索结果不足以支持回答时，请直接回复“该问题暂时缺少可靠数据，建议前往官方平台核实”。这句话看着简单，实际上大幅降低了幻觉率。3.3 流式输出与交互体验志愿填报问题往往需要引用大量数据，一次性生成完整回答可能要等好几秒。为了不等太久，我接了 StreamingChatLanguageModel，用 TokenStream 把内容一边生成一边推送。用户端表现为打字机效果，第一帧几百毫秒内就能看到文字，心理等待时间大幅缩短。实现上也不复杂，监听 onToken 和 onComplete 回调，把增量文本通过 WebSocket 推给前端就行。流式输出的一次小坑是中断处理。如果用户在一个回答还没结束时就发了新问题，服务端必须取消旧的 TokenStream，否则会出现两个回答交错。我在实际项目里给每个会话维护了一个 CancellationToken，新问题到达时先取消旧任务再启动新任务，这个逻辑虽然简单，但非常重要。除了流式，我还做了输入意图识别。用户第一句话可能是“查学校”，也可能是“问专业”，甚至是“我自己 620 分能上什么”。我让模型先判断意图类型，再决定走 RAG 还是工具调用。严格来说这不是必须的步骤，因为 LangChain4j 的 AiServices 会自动根据参数决定是否调用工具，但显式做一次意图分类，能让后续路由更可控，也方便做统计报表。4. 工具调用与业务闭环4.1 用 @Tool 把数据库查询交给模型光有知识库还不够。很多关键问题是数值查询，比如“位次一万二能报哪些学校”，这类问题不能靠向量相似度回答，我必须让模型去调用一个真实查询工具，从关系数据库里把符合条件的院校捞出来。LangChain4j 支持工具调用，我只需要在普通类的方法上加 @Tool 注解，再把这个类传给 AiServices。模型在对话中判断需要查询时，会自动带上参数调用这个方法，并把我返回的结果拼接进回答。我设计的第一版有两个核心工具：一个是按位次区间查院校，一个是按选科和专业查限制条件。为什么会设计成工具而不是把数据库整个塞进 prompt？因为数据库有几十万行，任何模型都不可能一次性吃下。工具调用的本质是给模型一双“手”，它先理解用户意图，再通过精确计算完成检索，最后组织语言输出。这也符合一个顾问的真实工作方式：先查资料，再说话。4.2 核心工具实现与参数校验工具方法不能直接对着数据库表写裸 SQL，因为模型的输入是自然语言，参数可能不干净。我的工具方法入口长这样：public class ConsultantTools { private final SchoolRepository repository; @Tool("根据省内位次和分数区间查询可选院校，返回院校、专业组、年份、最低位次") public List<SchoolHit> querySchoolByRank( @ToolParam("考生省内位次") int rank, @ToolParam("向上浮动区间，默认3000") int span) { // 参数校验 if (rank <= 0 || span <= 0 || span > 10000) { throw new IllegalArgumentException("参数越界"); } return repository.findByRankRange(rank - span, rank + span); } }这里最重要的不是 SQL 写法，而是参数校验。模型在抽取“位次”时可能出错，它可能把分数当成位次，也可能把“一万二”解析成 12000，这个没问题，但如果解析成 1.2 就完蛋了。我在工具里做了严格的范围检查，位次必须为正整数，跨度不能超过一万，否则直接抛异常。LangChain4j 捕获到异常后会把错误信息回传给模型，模型通常会自己纠正参数再调用一次，这个机制比我在外层硬编码容错要优雅得多。位次换算和分数线的匹配逻辑，我坚持用关系数据库完成，不用大模型计算。比如考生分数对应的位次，应当由官方发布的一分一段表换算，我把它做成一个独立的换算工具。模型要做的是提取出考生的分数，然后交给工具函数去查表返回位次，再继续后续检索。这条链路上每一步都有据可查，不会出现“AI 心算”的离谱错误。4.3 结构化输出与结果卡片工具查询返回的是结构化数据，但如果直接把这些 List 塞给用户，体验会很差。我让 AiServices 最终返回一个固定结构的对象，比如推荐结果包含学校名称、院校代码、近三年最低位次、考生位次与最低位次的差值、是否建议冲刺/稳妥/保底、参考理由。模型会根据工具结果和知识库补充内容，自动填好这几个字段。LangChain4j 的 AiServices 支持把返回结果映射到自定义 record 类型，非常顺手。我定义了一个结果对象：public record SchoolRecommendation( String schoolName, int year, int minRank, int gap, String suggestion, String reason ) {}模型在输出前会自动按照这个结构来组织回答，省掉了我做 JSON 解析和字段校验的大量工作。前端拿到这个对象后，可以直接渲染成卡片式的推荐列表，用户体验比一长串文字好很多。结构化输出还能顺便约束模型：它不能只给一句话“这个学校可以报”，必须给出依据。4.4 冲稳保策略的落地方式“冲稳保”是志愿填报中最高频的策略概念，但它是很主观的经验判断，不能让模型自由发挥。我用规则固定了判断标准：考生位次比院校近三年最低位次高 5% 到 15%，算“稳”；高 15% 以上，算“保”；低 5% 以内，算“冲”；低超过 5%，就不推荐硬冲。这个规则写死在 Java 代码里，模型只负责解释规则和引用数据，不负责发明算法。这么设计是因为规则稳定、可解释、可测试。如果用 prompt 让模型判断“是否可冲”，它的标准每轮可能都不一样，用户会觉得这个 AI 不稳定。规则固定后，哪怕模型换了一个，推荐结论也不会漂移，这对实际运营非常重要。5. 常见问题排查与避坑记录5.1 幻觉怎么压都压不住怎么办志愿填报 AI 最恐怖的行为就是编造分数线。我用三招压制：第一，prompt 里给了明确的“不知道”出口；第二，检索向量库加大了 minScore，宁可查不到也不给低质量片段；第三，所有硬性数据都走工具调用，模型自身不具备编造数字的机会。三招一起上之后，幻觉率明显下降，但依然没有降到零。问题往往出在模型会把不同年份的数据串着说，比如用 2021 年的位次回答 2023 年的问题。后来我把年份也变成了工具参数和检索过滤条件。每次用户报出分数和位次时，系统默认绑定到当年的数据，跨年份对比时需要明确说明，比如“2023 年位次相比 2022 年变化”。最终形成一套回归测试集，包含二十几个常见问题，每次改动后都跑一遍，人工检查回答里有没有编造的数据点。5.2 检索结果“答非所问”的排查思路RAG 应用出了检索问题，第一反应不是调表面参数，而是要看召回阶段到底召回了什么。我习惯给检索器加一层 debug 日志，把每个查询的 Top 5 片段和相似度分数打出来。有一次回收结果总是混入和年份无关的旧数据，排查发现是切分时把多所院校的文本混进了同一个文档片段。后来我规定每个片段必须从院校名称开始，并且在切分时把院校名作为强制前缀。检索结果不稳定的另一个原因，是嵌入模型和查询问题之间的表达差异。“孩子考了 620 分能上什么学校”和知识库里的“某高校最低投档线”语义差距很大，纯向量匹配很难建立联系。我的办法是在问题进入检索前先做一次轻量改写，让模型把口语改写为检索式表达，比如补全省份和年份。这个技巧对提升召回率很有效，代价是增加了一轮模型调用，但整体效果值得。5.3 上下文、并发和数据更新问题多轮对话里，检索片段会不断累积，用户聊到第十轮时，历史消息加上检索片段很容易把上下文占满。我除了限制记忆窗口，还给每轮检索结果做了“按需截断”：默认只保留命中分数最高的前 3 个片段进入上下文，而不是把 5 个全塞进去。字段也要精简，如果片段太长就先裁掉开头结尾的无效段落。这是用效果换速度的取舍，实测可行。并发方面，模型调用是外部 HTTP 请求，不能直接开一大堆线程去等。我用 Java 的异步特性处理流式输出，同时给工具数据库查询加上连接池和超时控制。每个会话的模型调用增加一个简单限流，防止某个恶意调用把额度打爆。数据更新则固定为年度流程：每年新数据公布后，先重建结构化数据库的年份分区，再整体清空向量库重新构建索引。这里有一个必须强调的教训：绝不能只增量更新，因为旧索引片段里可能残留过期政策，会导致回答自相矛盾。5.4 隐私和合规红线项目里涉及考生分数、位次等个人敏感信息。我的原则是：所有考生信息只存在内存会话里，不落库；日志里对考生姓名、联系方式做脱敏处理；原始分数和位次只用于查询，不写入数据库。交流中生成的推荐结果可以留存做运营分析，但必须去除可识别个人身份的信息。还要强调一点，志愿填报顾问只是一个信息整理工具，它的输出不能替代官方文件和学校招生章程。我在应用界面和 prompt 里都加了提示，引导用户对关键信息做二次核实。这不是免责话术，而是这类产品该有的底线。6. 后续还能怎么扩展项目做到这一步，已经可以当成一个完整的 MVP 用了。但志愿填报顾问的想象空间远不止于此，我手头已经规划了几个后续方向。第一个方向是“志愿表体检报告”。用户把自己的志愿表填进来，系统逐个院校进行位次比对，给出整体梯度分析，指出哪几个志愿太激进、哪几个太保守、顺序是否合理。这个功能不需要新的大模型能力，把已有的工具查询结果聚合一下就能实现，商业价值非常高，因为用户填完表之后最焦虑的就是想让人帮忙看一眼。第二个方向是引入招生计划变化提醒。每年院校的招生计划数会变化，计划增加或减少直接影响录取位次。我可以做一个订阅功能，用户关注某几所院校后，计划一更新就推送提醒。这就从“问答”升级成了“决策陪伴”，用户粘性会强很多。第三个方向是结构化生成 PDF 版志愿参考表。把推荐结果和对话依据自动排版成一份可打印的文档，对不太会用手机的长辈用户非常友好。技术上用模板引擎配合结构化输出就能搞定，成本很低。第四个方向是更细粒度的专业匹配。现在推荐结果以院校维度为主，后续可以沉淀专业录取数据和就业口碑，按“专业+院校”联合推荐。这需要更大规模的数据治理，但一旦做出来，产品价值会比院校维度推荐高一个量级。其实回看这个项目，LangChain4j 给我最大的帮助不是省了多少代码，而是让 Java 团队能无缝进入 LLM 应用开发。很多人以为大模型应用必须配 Python、必须写 Agent 框架，实际用 LangChain4j 做下来，该有的东西都有，工程化反而更顺手。如果说有什么经验是最值得分享的，那就是别一上来就追复杂架构。先把知识库和工具链做扎实，让模型每次都站在数据基础上回答问题，AI 顾问就已经具备了可用性。最后再补一个小诀窍：每次给用户的推荐理由里，都要附带一句“依据某年官方数据”这样可追溯的说明。这不仅让回答更可信，还能倒逼自己的系统始终把数据链路维护在可控状态。
去年出分那几天，我在帮家里一个孩子折腾志愿填报。翻投档表、查位次、核对招生章程，连续三个晚上熬到凌晨，发现真正难的不是“选学校”，而是几十万条数据根本翻不完。当时正好在折腾 Java 生态里的黑马框架 LangChain4j，顺手就用它做了个 AI 志愿填报顾问原型，把院校库、位次换算、政策问答和自然语言对话串成一条完整链路。这篇文章就是当时从零到能跑通的全过程复盘，适合那些想用 Java 做 LLM 应用、但又不想引入 Python 技术栈的开发者。志愿填报这个场景，天然适合被 AI 改造。它不是单纯问一句“我能上什么学校”就能结束的简单问答，而是需要结合考生分数、省内位次、选科组合、院校历年录取数据、招生计划变化、体检受限条款等多维度信息做判断。信息源多且分散，格式以 PDF、网页表格为主，对普通家庭来说，真正困难的是信息检索和交叉比对。这个项目把 LangChain4j 的 RAG、工具调用、记忆管理、结构化输出全部用上，最终做成一个既能聊天解释、又能精确查数的顾问式应用。1. 志愿填报顾问：这个项目到底解决什么问题1.1 高考出分后的三天，家长在慌什么志愿填报的关键窗口往往只有几十个小时，但需要处理的信息量非常大。考生拿到分数后，第一件事是把分数换算成省内位次，再拿着位次去对比目标院校过去三年的最低投档位次。这里有个最常见的坑：每年试卷难度不一样，分数线也会浮动，只看绝对分完全不靠谱，必须看位次。除了位次，还要考虑院校专业组的选科要求、身体条件限制、单科成绩要求、专业录取规则是“分数清”还是“专业级差”等等。我做过一次用户访谈，发现家长最典型的提问方式是：“孩子考了 620 分，位次大概一万名，能报哪些学校？”“XX大学的计算机专业比去年涨了多少分？”“物理组能不能报临床医学？”这些问题表面上是在问学校，实际上是要把位次、专业限制、历年数据、政策规则串起来。传统搜索工具很难回答这种复合型问题，因为答案散落在几十个网页里，需要自己判断哪条信息是当年的、哪条已经过期。1.2 LangChain4j 凭什么能接住这个需求早期我考虑过直接用 Python 的 LangChain，但项目团队一直是 Java 技术栈，为了一个小应用再引入 Python 服务和模型管理，维护成本不划算。后来看到 LangChain4j，发现它把 Java 生态缺失的那块拼图补齐了。它提供了一套清晰的分层抽象：聊天模型、嵌入模型、向量存储、消息记忆、内容检索器、工具调用、AI 服务。也就是说，在 Python LangChain 里你会用到的能力，它基本都有，而且模块划分得更直观。LangChain4j 还有一个很适合做业务系统的特性：它不强求你用某种固定流程。你可以先只接入一个 ChatModel 做问答，再慢慢加上 Memory、Retriever、Tools，每一步都是增量改造，不会推倒重来。志愿填报顾问这个项目一开始只有简单的模型调用，后来才逐步加入知识库检索和工具调用，整个演进过程非常顺。比起直接用 HTTP 裸调大模型接口，LangChain4j 省掉了我自己维护消息队列、JSON 解析和对话上下文拼接的重复工作。从项目影响范围看，这个应用可以做成微信小程序、Web 端甚至呼叫中心辅助座席。它不是一个只能演示的玩具，而是能把“查数据、做筛选、给建议”这件事做成一个可运营的服务。这也是我坚持用 Java 去做 LLM 应用的原因：团队现有的人才能直接上手，部署、监控、灰度发布都能复用已有的基础设施。2. 数据先行：把院校投档线变成 AI 能检索的格式2.1 公开数据采集与清洗做 AI 顾问最怕的不是模型不聪明，而是它没有数据。志愿填报顾问这个项目的第一步，就是先把数据仓库建起来。所有数据必须来自官方公开渠道，包括各省级招生信息发布平台、院校官网的招生章程，绝不能靠模型记忆里的“常识”来编录取数据。因为志愿填报涉及考生前途，数据和规则必须可追溯、可复核。我做的数据清洗流程一般分四步：抽取、清洗、去重、归一。原始数据很多是 PDF 或图片表格，PDF 里经常出现合并单元格、跨页断行、特殊符号，直接解析会产出大量脏数据。我的做法是先用表格解析工具把 PDF 转成结构化表格，再对每一行的院校代码、专业名称、计划数、最低分、最低位次做字段级校验。比如某所高校连续两年名称不一致的问题，就得维护一份院校别名表，把“某工业大学（XX校区）”和“某工业大学”归并成同一条记录。数据归一化是另一个容易忽略的环节。不同年份的试卷难度不同，分数没有直接可比性，所以我在数据库里同时存原始分数和对应位次。位次是判断录取概率最稳定的锚点。每一年的数据都要标明年份和省份，避免 AI 在回答中把不同省份的数据混在一起。这个步骤如果做不干净，后面一切检索和推荐都是空中楼阁。2.2 文档切分与向量化生产数据清洗完以后，会分成两条路：结构化的分数位次数据放进关系数据库，供工具调用精确查询；政策规则、专业介绍、院校说明这类非结构化文本，则切成文档片段，放进向量知识库做 RAG。为什么同一份数据要拆两份？因为功能不同。精确查询适合用 SQL，比如“位次是否达到最低投档位次”，这需要计算和比较，不能靠语言模型猜。而“什么是专业级差”“某专业的就业方向”“选科限制有哪些”这类问题，没有严格的数值计算，更适合从知识库检索段落后让模型整理成自然语言回答。文档切分是 RAG 效果的命门。切得太碎，比如几十个字一段，上下文语义不完整，检索出来的片段经常答非所问；切得太长，比如几千字一段，向量相似度会被无关内容稀释，而且塞进 Prompt 里也容易爆上下文。我测试下来，中文文本单段控制在 300 到 600 字比较合适，既能承载一个完整的招生规则条目，也不会让单次检索结果占用太多 token。切分时还要把“院校名称+年份+省份”写进元数据，检索后才能按省份、年份做过滤。向量化时，我直接用了 LangChain4j 的 EmbeddingModel 接口，统一嵌入模型生成向量。这里有个硬性要求：写入向量库和查询时用的必须是同一个嵌入模型，否则维度不匹配，相似度也没有意义。数据量大以后，内存向量库不够用，我换成了支持持久化的向量数据库，LangChain4j 对主流向量库基本都有适配。建索引时，我把同一所院校不同年份的文档片段编成同一个文档 ID，方便后续整体更新和删除。2.3 Retriever 的关键参数怎么调我用的检索器是 EmbeddingStoreContentRetriever，核心参数就两个：maxResults 和 minScore。maxResults 决定每次检索返回多少候选片段，设得太大会让 prompt 变得又长又杂，设得太小又可能丢信息。在志愿填报场景里，我默认取 5 个片段，既能覆盖多个维度，又不会让模型的注意力被冲散。minScore 是容易踩坑的地方。它是相似度阈值，低于这个值的片段会被过滤掉。一开始我设成 0.5，结果经常把毫不相关的专业介绍也捞上来，AI 就开始一本正经地胡说。后来调到 0.7，检索结果干净不少。但要注意，minScore 不是越高越好，如果知识库文档措辞和用户口语提问差异大，阈值太高会直接检索不到。我的经验是先跑一遍典型的测试问题，统计正常命中分数，再在中间值上留一点余量。另外，每次检索时我还会带上省份和年份过滤器，相当于在向量召回之前就先做一轮数据隔离，避免“某省考生问到了另一省的数据”这种尴尬错误。3. 对话层：把顾问该有的素质做出来3.1 模型参数与记忆配置AI 志愿填报顾问不是一次性问答工具，用户会进行多轮追问。比如先问“有哪些学校推荐”，再问“XX学校怎么样”，然后追问“能不能把就业情况也说说”。这种场景必须配置对话记忆。LangChain4j 里我用的是 MessageWindowChatMemory，只保留最近 20 条消息。为什么不是越多越好？因为每条历史消息都会重复计入上下文，20 条窗口大概对应 5000 到 8000 token，既能覆盖一个完整咨询流程，又不会让请求太慢、太贵。超过窗口后，较早的消息会自动淘汰，避免上下文无限膨胀。模型参数方面，我把 temperature 调到了 0.2。这个参数控制回答的随机性，温度越高，模型越“放飞”，在数据敏感的志愿填报场景里，放飞等于灾难。0.2 意味着模型在组织语言时有一点灵活性，但在数据和规则描述上基本保持稳定。还有 maxTokens，我根据回答类型设置了上限，普通问答给 800，需要返回推荐列表的给 1500，防止模型过度输出无关内容。用 LangChain4j 时，模型接入非常直接。不同模型提供商只需要换一个实现类，核心代码结构基本不变。我的配置大致是这样的：ChatLanguageModel model = OpenAiChatModel.builder() .baseUrl(System.getenv("LLM_BASE_URL")) .apiKey(System.getenv("LLM_API_KEY")) .modelName("your-model-name") .temperature(0.2) .maxTokens(1500) .build();这里 baseUrl 和 apiKey 都从环境变量读，不写死在代码里。实际选型时，我们用的是某国产模型平台提供的兼容接口，服务稳定性和中文理解能力都过关。LangChain4j 的好处是模型换起来成本低，我测试阶段换过两三个模型，只改了配置，业务代码一行没动。3.2 提示词工程的核心约束提示词是这个项目的灵魂。我见过很多 AI 应用效果差，不是模型不行，而是系统提示词没有把边界讲清楚。志愿填报顾问的 System Prompt 我写了三版，最终沉淀出四条硬性约束：第一，身份约束。AI 是“志愿填报信息顾问”，不是“录取保证人”，所有回答都只是信息整理和参考，不能承诺录取结果。第二，数据边界。回答必须基于检索到的知识库内容和工具返回的数据库结果，没有数据支撑的问题要直接说不知道，不许编造。第三，格式约束。推荐类回答必须按固定结构输出，包含院校名称、年份、最低位次、匹配判断、依据说明，方便前端渲染。第四，免责约束。最终填报决定以官方发布为准，AI 只辅助决策。Prompt 写作上有一个很实用的技巧：给模型“拒绝回答”的出口。如果你把 prompt 写得太满，模型会觉得必须给出一个答案，于是强行编数据。我在 prompt 里明确写了一句：当检索结果不足以支持回答时，请直接回复“该问题暂时缺少可靠数据，建议前往官方平台核实”。这句话看着简单，实际上大幅降低了幻觉率。3.3 流式输出与交互体验志愿填报问题往往需要引用大量数据，一次性生成完整回答可能要等好几秒。为了不等太久，我接了 StreamingChatLanguageModel，用 TokenStream 把内容一边生成一边推送。用户端表现为打字机效果，第一帧几百毫秒内就能看到文字，心理等待时间大幅缩短。实现上也不复杂，监听 onToken 和 onComplete 回调，把增量文本通过 WebSocket 推给前端就行。流式输出的一次小坑是中断处理。如果用户在一个回答还没结束时就发了新问题，服务端必须取消旧的 TokenStream，否则会出现两个回答交错。我在实际项目里给每个会话维护了一个 CancellationToken，新问题到达时先取消旧任务再启动新任务，这个逻辑虽然简单，但非常重要。除了流式，我还做了输入意图识别。用户第一句话可能是“查学校”，也可能是“问专业”，甚至是“我自己 620 分能上什么”。我让模型先判断意图类型，再决定走 RAG 还是工具调用。严格来说这不是必须的步骤，因为 LangChain4j 的 AiServices 会自动根据参数决定是否调用工具，但显式做一次意图分类，能让后续路由更可控，也方便做统计报表。4. 工具调用与业务闭环4.1 用 @Tool 把数据库查询交给模型光有知识库还不够。很多关键问题是数值查询，比如“位次一万二能报哪些学校”，这类问题不能靠向量相似度回答，我必须让模型去调用一个真实查询工具，从关系数据库里把符合条件的院校捞出来。LangChain4j 支持工具调用，我只需要在普通类的方法上加 @Tool 注解，再把这个类传给 AiServices。模型在对话中判断需要查询时，会自动带上参数调用这个方法，并把我返回的结果拼接进回答。我设计的第一版有两个核心工具：一个是按位次区间查院校，一个是按选科和专业查限制条件。为什么会设计成工具而不是把数据库整个塞进 prompt？因为数据库有几十万行，任何模型都不可能一次性吃下。工具调用的本质是给模型一双“手”，它先理解用户意图，再通过精确计算完成检索，最后组织语言输出。这也符合一个顾问的真实工作方式：先查资料，再说话。4.2 核心工具实现与参数校验工具方法不能直接对着数据库表写裸 SQL，因为模型的输入是自然语言，参数可能不干净。我的工具方法入口长这样：public class ConsultantTools { private final SchoolRepository repository; @Tool("根据省内位次和分数区间查询可选院校，返回院校、专业组、年份、最低位次") public List<SchoolHit> querySchoolByRank( @ToolParam("考生省内位次") int rank, @ToolParam("向上浮动区间，默认3000") int span) { // 参数校验 if (rank <= 0 || span <= 0 || span > 10000) { throw new IllegalArgumentException("参数越界"); } return repository.findByRankRange(rank - span, rank + span); } }这里最重要的不是 SQL 写法，而是参数校验。模型在抽取“位次”时可能出错，它可能把分数当成位次，也可能把“一万二”解析成 12000，这个没问题，但如果解析成 1.2 就完蛋了。我在工具里做了严格的范围检查，位次必须为正整数，跨度不能超过一万，否则直接抛异常。LangChain4j 捕获到异常后会把错误信息回传给模型，模型通常会自己纠正参数再调用一次，这个机制比我在外层硬编码容错要优雅得多。位次换算和分数线的匹配逻辑，我坚持用关系数据库完成，不用大模型计算。比如考生分数对应的位次，应当由官方发布的一分一段表换算，我把它做成一个独立的换算工具。模型要做的是提取出考生的分数，然后交给工具函数去查表返回位次，再继续后续检索。这条链路上每一步都有据可查，不会出现“AI 心算”的离谱错误。4.3 结构化输出与结果卡片工具查询返回的是结构化数据，但如果直接把这些 List 塞给用户，体验会很差。我让 AiServices 最终返回一个固定结构的对象，比如推荐结果包含学校名称、院校代码、近三年最低位次、考生位次与最低位次的差值、是否建议冲刺/稳妥/保底、参考理由。模型会根据工具结果和知识库补充内容，自动填好这几个字段。LangChain4j 的 AiServices 支持把返回结果映射到自定义 record 类型，非常顺手。我定义了一个结果对象：public record SchoolRecommendation( String schoolName, int year, int minRank, int gap, String suggestion, String reason ) {}模型在输出前会自动按照这个结构来组织回答，省掉了我做 JSON 解析和字段校验的大量工作。前端拿到这个对象后，可以直接渲染成卡片式的推荐列表，用户体验比一长串文字好很多。结构化输出还能顺便约束模型：它不能只给一句话“这个学校可以报”，必须给出依据。4.4 冲稳保策略的落地方式“冲稳保”是志愿填报中最高频的策略概念，但它是很主观的经验判断，不能让模型自由发挥。我用规则固定了判断标准：考生位次比院校近三年最低位次高 5% 到 15%，算“稳”；高 15% 以上，算“保”；低 5% 以内，算“冲”；低超过 5%，就不推荐硬冲。这个规则写死在 Java 代码里，模型只负责解释规则和引用数据，不负责发明算法。这么设计是因为规则稳定、可解释、可测试。如果用 prompt 让模型判断“是否可冲”，它的标准每轮可能都不一样，用户会觉得这个 AI 不稳定。规则固定后，哪怕模型换了一个，推荐结论也不会漂移，这对实际运营非常重要。5. 常见问题排查与避坑记录5.1 幻觉怎么压都压不住怎么办志愿填报 AI 最恐怖的行为就是编造分数线。我用三招压制：第一，prompt 里给了明确的“不知道”出口；第二，检索向量库加大了 minScore，宁可查不到也不给低质量片段；第三，所有硬性数据都走工具调用，模型自身不具备编造数字的机会。三招一起上之后，幻觉率明显下降，但依然没有降到零。问题往往出在模型会把不同年份的数据串着说，比如用 2021 年的位次回答 2023 年的问题。后来我把年份也变成了工具参数和检索过滤条件。每次用户报出分数和位次时，系统默认绑定到当年的数据，跨年份对比时需要明确说明，比如“2023 年位次相比 2022 年变化”。最终形成一套回归测试集，包含二十几个常见问题，每次改动后都跑一遍，人工检查回答里有没有编造的数据点。5.2 检索结果“答非所问”的排查思路RAG 应用出了检索问题，第一反应不是调表面参数，而是要看召回阶段到底召回了什么。我习惯给检索器加一层 debug 日志，把每个查询的 Top 5 片段和相似度分数打出来。有一次回收结果总是混入和年份无关的旧数据，排查发现是切分时把多所院校的文本混进了同一个文档片段。后来我规定每个片段必须从院校名称开始，并且在切分时把院校名作为强制前缀。检索结果不稳定的另一个原因，是嵌入模型和查询问题之间的表达差异。“孩子考了 620 分能上什么学校”和知识库里的“某高校最低投档线”语义差距很大，纯向量匹配很难建立联系。我的办法是在问题进入检索前先做一次轻量改写，让模型把口语改写为检索式表达，比如补全省份和年份。这个技巧对提升召回率很有效，代价是增加了一轮模型调用，但整体效果值得。5.3 上下文、并发和数据更新问题多轮对话里，检索片段会不断累积，用户聊到第十轮时，历史消息加上检索片段很容易把上下文占满。我除了限制记忆窗口，还给每轮检索结果做了“按需截断”：默认只保留命中分数最高的前 3 个片段进入上下文，而不是把 5 个全塞进去。字段也要精简，如果片段太长就先裁掉开头结尾的无效段落。这是用效果换速度的取舍，实测可行。并发方面，模型调用是外部 HTTP 请求，不能直接开一大堆线程去等。我用 Java 的异步特性处理流式输出，同时给工具数据库查询加上连接池和超时控制。每个会话的模型调用增加一个简单限流，防止某个恶意调用把额度打爆。数据更新则固定为年度流程：每年新数据公布后，先重建结构化数据库的年份分区，再整体清空向量库重新构建索引。这里有一个必须强调的教训：绝不能只增量更新，因为旧索引片段里可能残留过期政策，会导致回答自相矛盾。5.4 隐私和合规红线项目里涉及考生分数、位次等个人敏感信息。我的原则是：所有考生信息只存在内存会话里，不落库；日志里对考生姓名、联系方式做脱敏处理；原始分数和位次只用于查询，不写入数据库。交流中生成的推荐结果可以留存做运营分析，但必须去除可识别个人身份的信息。还要强调一点，志愿填报顾问只是一个信息整理工具，它的输出不能替代官方文件和学校招生章程。我在应用界面和 prompt 里都加了提示，引导用户对关键信息做二次核实。这不是免责话术，而是这类产品该有的底线。6. 后续还能怎么扩展项目做到这一步，已经可以当成一个完整的 MVP 用了。但志愿填报顾问的想象空间远不止于此，我手头已经规划了几个后续方向。第一个方向是“志愿表体检报告”。用户把自己的志愿表填进来，系统逐个院校进行位次比对，给出整体梯度分析，指出哪几个志愿太激进、哪几个太保守、顺序是否合理。这个功能不需要新的大模型能力，把已有的工具查询结果聚合一下就能实现，商业价值非常高，因为用户填完表之后最焦虑的就是想让人帮忙看一眼。第二个方向是引入招生计划变化提醒。每年院校的招生计划数会变化，计划增加或减少直接影响录取位次。我可以做一个订阅功能，用户关注某几所院校后，计划一更新就推送提醒。这就从“问答”升级成了“决策陪伴”，用户粘性会强很多。第三个方向是结构化生成 PDF 版志愿参考表。把推荐结果和对话依据自动排版成一份可打印的文档，对不太会用手机的长辈用户非常友好。技术上用模板引擎配合结构化输出就能搞定，成本很低。第四个方向是更细粒度的专业匹配。现在推荐结果以院校维度为主，后续可以沉淀专业录取数据和就业口碑，按“专业+院校”联合推荐。这需要更大规模的数据治理，但一旦做出来，产品价值会比院校维度推荐高一个量级。其实回看这个项目，LangChain4j 给我最大的帮助不是省了多少代码，而是让 Java 团队能无缝进入 LLM 应用开发。很多人以为大模型应用必须配 Python、必须写 Agent 框架，实际用 LangChain4j 做下来，该有的东西都有，工程化反而更顺手。如果说有什么经验是最值得分享的，那就是别一上来就追复杂架构。先把知识库和工具链做扎实，让模型每次都站在数据基础上回答问题，AI 顾问就已经具备了可用性。最后再补一个小诀窍：每次给用户的推荐理由里，都要附带一句“依据某年官方数据”这样可追溯的说明。这不仅让回答更可信，还能倒逼自己的系统始终把数据链路维护在可控状态。