Java 17调用Embeddings API：余弦相似度与FAQ拒答阈值
内容提要
本文介绍用Java 17调用Embeddings接口实现FAQ语义检索：将问题转为向量，通过余弦相似度匹配最相近条目，低于0.78阈值则拒答。强调阈值需用标注数据校准，相似度不等于正确概率；生产系统应预存向量、分层评估召回与答案有效性，并注意脱敏与知识库版本更新。
延伸解读
阈值0.78只是起点，不是标准答案
文章明确将0.78称为教学起点，强调它并非官方标准，也不适用于所有语言和业务。相似度分数只描述向量空间中的方向接近程度，不能解释为正确概率。实际系统中，阈值需用脱敏问题与人工标注数据校准，并区分调参集与留出集，根据误放行和误拒绝的成本来权衡。高阈值减少错误答案但增加人工负担，低阈值则可能让错误答案通过。
相似度高不等于业务答案正确
余弦相似度只反映语义方向接近，无法保证答案在业务上正确。文章举例“退款后怎么换货”可能同时接近两条FAQ，最高分未必对应正确路径。即使正确条目排第一，答案文本也可能因政策过期而错误。因此不能将相似度当作正确概率展示，生产系统还需检查前两名分差、条目有效期和答案来源，并允许人工纠错。
评估需分层，拒答也是能力
文章建议将评估分为三层：正确条目是否进入候选、排序是否靠前、最终答案是否仍有效。第一层失败要改分块和召回，第二层可试重排，第三层需改知识维护流程。测试集应包含无答案问题，如“跨境订单能否在门店退货”，若硬答换货流程则属误导。拒答不是失败，而是证据不足时保留可信度的能力，人工处理结果可反哺FAQ更新。
工程化要点：预存向量与数据脱敏
示例为演示将FAQ与查询一起提交，但生产系统应预先计算并保存FAQ向量，仅对新查询调用接口。FAQ文本、答案、版本和向量应一起存储，更新答案时重建向量。向量会将查询文本发送到服务端，订单号、手机号等敏感信息发送前应识别替换，并检查内部政策能否上传。知识库删除旧规则后必须同步更新向量索引，否则会返回过期答案。
Q&A
Java 17 怎么调用 Embeddings API 做 FAQ 语义检索？
用 Java 17 和 JDK 自带 HttpClient 向 /v1/embeddings 发送 POST 请求，模型用 text-embedding-3-small，把 FAQ 问题和用户查询一起作为 input 提交，拿到向量后用余弦相似度比较，选最高分且超过 0.78 阈值的条目返回，否则拒答。
余弦相似度 0.78 能理解为 78% 正确概率吗？
不能。余弦相似度只描述两个向量在当前空间中的方向接近程度，不是正确概率。0.78 只是教学起点，必须用标注数据校准，且不能把相似度写成“78% 确信”。
FAQ 检索的拒答阈值应该怎么定？
先收集脱敏问题并人工标注哪些可由 FAQ 回答、哪些必须拒答，分成调参集和独立留出集，在调参集上试多个阈值，在留出集上统计误放行和误拒绝，再根据两类错误的业务成本决定阈值。
生产环境用 Embeddings 做 FAQ 检索要注意哪些工程问题？
应预存 FAQ 向量，只对新查询调用接口；存储 FAQ 文本、答案、版本和向量，更新答案时重建向量；记录查询与人工纠错；注意脱敏，避免发送订单号、手机号等；知识库变更后要同步更新向量索引，防止返回过期答案。
FAQ 检索系统应该怎么评估效果？
至少分三层评估：正确条目是否进入候选、排序是否把它放在前面、最终答案是否仍有效。同时要列出“命中正确 FAQ 的比例”和“无法回答时正确拒答的比例”，测试集应包含没有答案的问题，不能只看平均相似度。
相似度很高但业务答案错误，可能是什么原因？
可能是 FAQ 文本过短、语义重叠、答案过期，或向量无法代替业务规则。例如“退款后怎么换货”可能同时接近两条 FAQ，最高分未必是正确业务路径；退款金额、资格和时效必须以系统记录为准。
调用 Embeddings API 时遇到 401 或 429 错误怎么办？
401 是凭据问题，检查 OPENAI_API_KEY 环境变量和项目权限；429 是限流或额度问题，控制并发并按服务端建议退避。
向量检索适合直接做自动决策吗？
不适合。它适合小规模 FAQ 召回和 RAG 的第一步，不适合直接做具有法律或财务后果的自动决策。拒答不是失败，而是证据不足时保留可信度的能力，必要时可补充意图分类、有效期检查和人工审核。
