LangChain4j 实战：dynamicMaxResults、dynamicMinScore、dynamicFilter 怎么落地

LangChain4j 面试题：检索器怎么做？ContentRetriever、动态过滤、TopK 和阈值讲透

LangChain4j 的ContentRetriever把‘从哪里拿知识’这件事抽得很清楚，但也正因为抽得清楚，很多细节都需要你自己定策略。
这篇我就拿最常用的EmbeddingStoreContentRetriever来讲，为什么单纯写个 TopK 往往远远不够。

🦅个人主页
🐼GitHub主页

先看真实问题：为什么检索链路经常不是‘没找到’，而是‘找回来一堆不该要的东西’

RAG 问答出错时，很多人第一反应是换模型，但实际排一圈你会发现，常见问题是召回范围太大、租户没隔离、业务域没收敛、低分 chunk 也被塞进了 prompt。
所以检索器真正要解决的是相关性和边界，而不是把向量库搜一下这么简单。

• 不同场景适合的 TopK 不一样，FAQ 和规则解释不一定该拿同样多片段
• 没有元数据过滤，多租户系统最容易串知识
• 不设最小分数阈值，很多边缘噪音会白白占 token

一张表先看懂：检索器最值得优先调的几个旋钮

举个具体例子：多租户知识库：同一句问题，不同租户看到的知识必须不同

1. 同样一句“退款时效多久”，A 租户和 B 租户看到的规则文档完全不同。
2. 后端把tenantId放进 query metadata，再用 dynamicFilter 做过滤。
3. 当问题很短、歧义比较大时，maxResults 可以放大一点；当问题很精准时，maxResults 可以收小。
4. 如果召回分数普遍偏低，系统就直接返回‘当前知识不足’，不要硬答。

企业里的典型应用场景

• 多租户客服知识库：同一句退款问题，不同商家必须查到各自的规则和政策。
• 内部制度问答：同一知识库里有 HR 制度、财务制度、法务制度，需要按业务域过滤。
• 海外/本地双规则中心：同一个问题根据国家站点、语言和业务线走不同召回范围。

如果按企业项目落地，我会这样走完整闭环

1. 入口层先识别租户、语言、业务域和渠道，这些字段必须在检索前准备好。
2. 查询层根据问题长度、业务域和用户角色动态决定 TopK、minScore、metadata filter。
3. 召回层只负责把候选内容搜回来，不急着注入模型，先做过滤和质量判断。
4. 判定层对空召回、低分召回、噪音过高场景做拒答或转人工，避免模型硬答。
5. 回答层只吃通过质检的知识片段，并把引用来源和分数一起返回给前端或日志系统。
6. 评估层沉淀检索日志、低分问答、空召回样本，为后续切块和规则优化提供数据闭环。

代码示例：EmbeddingStoreContentRetriever + 动态过滤

构建检索器

ContentRetrieverretriever=EmbeddingStoreContentRetriever.builder().embeddingStore(embeddingStore).embeddingModel(embeddingModel).dynamicMaxResults(query->query.text().length()<15?6:3).dynamicMinScore(query->query.text().contains("退款")?0.78:0.70).dynamicFilter(query->{StringtenantId=query.metadata().invocationParameters().get("tenantId");StringbizType=query.metadata().invocationParameters().get("bizType");returnmetadataKey("tenantId").isEqualTo(tenantId).and(metadataKey("bizType").isEqualTo(bizType));}).build();

AI Service 传入 InvocationParameters

publicinterfaceRuleAssistant{Stringchat(@UserMessageStringquestion,InvocationParametersparameters);}RuleAssistantassistant=AiServices.builder(RuleAssistant.class).chatModel(chatModel).contentRetriever(retriever).build();InvocationParametersparameters=InvocationParameters.from(Map.of("tenantId","tenant_a","bizType","refund_rule"));Stringanswer=assistant.chat("退款时效多久？",parameters);

低分召回时主动拒答

publicStringanswerWithGuard(Stringquestion,InvocationParametersparameters){List<Content>contents=retriever.retrieve(Query.from(question,Metadata.from(parameters.toMap())));booleanallLowScore=contents.stream().allMatch(content->content.metadata().score()!=null&&content.metadata().score()<0.70);if(contents.isEmpty()||allLowScore){return"当前知识不足，建议转人工处理。";}returnassistant.chat(question,parameters);}

企业级代码示例：企业级检索通常会先做 QueryContext，再做动态检索

检索编排服务

@Service@RequiredArgsConstructorpublicclassKnowledgeRetrieveFacade{privatefinalContentRetrievercontentRetriever;privatefinalRetrieveAuditRepositoryretrieveAuditRepository;publicRetrieveResultsearch(KnowledgeRetrieveCommandcommand){QueryContextcontext=QueryContext.builder().tenantId(command.tenantId()).bizType(command.bizType()).language(command.language()).operatorId(command.operatorId()).queryText(command.question()).build();Queryquery=Query.from(command.question(),Metadata.from(Map.of("tenantId",context.tenantId(),"bizType",context.bizType(),"language",context.language())));longstart=System.currentTimeMillis();List<Content>contents=contentRetriever.retrieve(query);longcost=System.currentTimeMillis()-start;booleanlowQuality=contents.isEmpty()||contents.stream().allMatch(item->item.metadata().score()!=null&&item.metadata().score()<0.72);retrieveAuditRepository.save(RetrieveAuditEntity.builder().tenantId(context.tenantId()).bizType(context.bizType()).question(command.question()).resultCount(contents.size()).costMillis(cost).lowQuality(lowQuality).build());if(lowQuality){returnRetrieveResult.reject("当前知识不足，建议转人工处理");}returnRetrieveResult.success(contents);}}

SQL 示例：知识分段主表

createtablekb_segment_index(idbigintprimarykeyauto_increment,segment_idvarchar(64)notnullunique,tenant_idvarchar(64)notnull,biz_typevarchar(64)notnull,source_doc_idbigintnotnull,source_namevarchar(200)null,segment_nointnotnull,text_previewvarchar(500)null,created_timedatetimenotnulldefaultcurrent_timestamp);

系统设计时我会优先拆哪几层

召回层

• 先把召回范围缩到对的租户和业务域，再谈相似度排序
• 固定 TopK 适合 demo，动态 TopK 更适合真实项目

过滤层

• metadata 是过滤的前提，所以知识入库阶段就要把字段打齐
• 常见过滤条件就是租户、业务域、来源、权限范围、更新时间

拒答层

• 检索分数过低时，拒答往往比胡答更靠谱
• 这层最好和前端、人工系统配合起来，别只返回一个冷冰冰的空字符串

真正上线时最容易卡住的点

1. 所有 query 都用同一个 TopK 和 minScore，场景一多就会明显不合适。
2. 没有租户过滤，跨租户知识串线是非常危险的线上事故。
3. 一味追求回答率，低分内容也照样塞 prompt，最后用户只会觉得‘答得很自信但不对’。

监控和指标建议盯哪些

• 平均召回条数、平均 minScore 命中率
• 低分拒答率
• 按租户和业务域拆分的召回质量
• 检索耗时、空召回率、噪音召回率

如果面试官问我这块怎么设计，我会这样答

如果面试官问 LangChain4j 的检索器怎么设计，我会重点讲maxResults、minScore和filter这三个控制点。项目里我更倾向用动态策略，而不是写死一个 TopK。因为真正决定 RAG 质量的，常常不是模型，而是你到底把哪些内容放进了 prompt，以及有没有把不该进来的内容挡在外面。

结语

检索器看起来只是一个配置点，但在真实项目里，它其实是知识边界和召回质量的第一道门。

你们项目里更常见的问题，是召回太少，还是召回太多导致 prompt 被噪音撑满？