做过智能客服的同学还有做过企业知识库助手的同学大概率都碰到过这么一个场景。就是用户兴致勃勃地问了一个问题然后系统去检索了一圈结果啥也没搜到。那这个时候该怎么办呢如果说放任模型在那里自由发挥的话它很有可能就在那里一本正经地胡说八道。这个就是大家经常说的幻觉问题。而且呢对于那种依赖真实知识的场景比如说企业制度啊、产品参数啊、法律条款啊之类的一句编造出来的错误答案它带来的代价可能比直接说我不知道要大得多了。所以今天就来聊一下当检索不到的时候到底应该怎么去做这个兜底。✦ ✦ ✦一、先别急着放弃检索层其实还能再抢救一下很多时候所谓的检索不到它其实并不是真的没有答案而是你这个问题没有问对。可以试试去改写一下 query。用户的输入往往都是比较口语化的也比较模糊。比如说用户问这个咋报销啊但是知识库里面写的是差旅费报销流程。这种情况下你直接去检索大概率是扑空的。所以呢可以让模型先去做一次 query 的改写或者说把问题拆分一下然后再去检索一次。具体来说的话有这么几个方向可以做一个是补全同义词和行业术语。另一个是把长句子拆成几个子问题然后分别去检索。还有一个是去掉那些无关的限定词把检索范围给放宽一些。然后是混合检索这个事情不要只靠向量。纯向量检索对于那种语义相近但是用词差异比较大的内容确实是比较友好的。但是对于那种精确的专有名词啊、编号啊之类的比如说ISO 9001、第 3.2 条这种它反而不太敏感。所以搭配一个关键词检索也就是 BM25去做混合召回的话往往能够补上向量检索的这个短板。还有一个点就是在降低阈值之前先多召回几个候选。与其死守着一个相似度阈值来判定有没有不如先多召回一些 Top-K 的候选结果然后再让模型自己去判断这些内容跟问题到底相不相关、够不够用来回答。有时候没检索到高分结果和没有相关内容这完全是两码事。✦ ✦ ✦二、生成层的底线宁可说不知道也不要瞎编这一条是整个兜底策略里面最重要的一条原则了。在 prompt 里面你要明确地告诉模型如果说提供的资料里面没有相关的信息那就如实告知用户说没有找到相关的内容不要去编造答案。那到底要不要用模型自身的知识来做兜底呢这个要分场景来看。如果说是一些通用的常识类问题不依赖私有数据的那种那可以用模型自身的知识来回答。但是要标注一下说以下为通用知识并非企业知识库的内容。但如果是那种强依赖内部数据的场景比如说公司制度、产品参数、法务条款这些那就坚决不能瞎猜了必须明确告知说没有找到相关的资料。这个边界一定要在系统设计的阶段就想清楚不能到了生成的时候才临时去判断。✦ ✦ ✦三、交互层把没找到变成一次还不错的体验用户听到没找到这三个字的时候体验通常都是比较差的。但是如果设计得好的话这反而可以变成一次挽回的机会。比如说可以引导用户换个问法。跟用户说没有找到完全匹配的内容您可以换一下关键词或者说补充更多的细节来试试。或者呢给出一些相关但不是完全匹配的内容。跟用户说虽然没有精确匹配到但是以下这些资料可能对您有帮助然后把决定权交给用户。还有一个方式就是转人工或者说创建工单。这个是客服类场景里面最常见的兜底方式了当检索不到的时候主动提示用户说是否需要人工介入。✦ ✦ ✦四、系统层把每一次没找到变成知识库的养料兜底这个事情不应该只是临时的补救更应该去反哺到资产建设上面来。具体来说的话可以定期去分析那些检索失败的 query 日志把那些高频但是没有资料覆盖的问题给找出来。然后针对这些高频未命中的人工去补充知识库的条目。对于那些常见但是知识库暂时还没有的问题可以先建立一个兜底的 FAQ 库。这样一来的话检索不到的比例就会随着系统运行时间的推移变得越来越低了。✦ ✦ ✦五、一个典型的兜底逻辑链把上面几层串起来的话大概就是这么一个流程用户提问 → 检索向量 关键词混合 → 相似度是否达标 ├─ 是 → 生成答案带引用来源 └─ 否 → 尝试 query 改写重新检索一次 仍未达标 → 明确告知未找到相关资料 → 提供相关性较低的候选内容可选 → 引导换个问法 / 转人工可选✦ ✦ ✦写在最后RAG 系统的核心竞争力嘛往往不在于能不能答对这个问题上而是在于当你答不上来的时候应该怎么办。一个好的兜底设计应该做到这么三件事。第一是尽力去找。多轮改写、混合检索、放宽范围不要轻易就放弃了。第二是诚实地说。找不到就是找不到绝对不去编造。第三是持续去学习。把每一次的失败都变成知识库迭代的输入。宁可承认说我不知道也不要让系统去编出一个错误的答案。这句话啊值得刻在每一个 RAG 系统的 prompt 里面。01什么是AI大模型应用开发工程师如果说AI大模型是蕴藏着巨大能量的“后台超级能力”那么AI大模型应用开发工程师就是将这种能量转化为实用工具的执行者。AI大模型应用开发工程师是基于AI大模型设计开发落地业务的应用工程师。这个职业的核心价值在于打破技术与用户之间的壁垒把普通人难以理解的算法逻辑、模型参数转化为人人都能轻松操作的产品形态。无论是日常写作时用到的AI文案生成器、修图软件里的智能美化功能还是办公场景中的自动记账工具、会议记录用的语音转文字APP这些看似简单的应用背后都是应用开发工程师在默默搭建技术与需求之间的桥梁。他们不追求创造全新的大模型而是专注于让已有的大模型“听懂”业务需求“学会”解决具体问题最终形成可落地、可使用的产品。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】02AI大模型应用开发工程师的核心职责需求分析与拆解是工作的起点也是确保开发不偏离方向的关键。应用开发工程师需要直接对接业务方深入理解其核心诉求——不仅要明确“要做什么”更要厘清“为什么要做”以及“做到什么程度算合格”。在此基础上他们会将模糊的业务需求拆解为具体的技术任务明确每个环节的执行标准并评估技术实现的可行性同时定义清晰的核心指标为后续开发、测试提供依据。这一步就像建筑前的图纸设计若出现偏差后续所有工作都可能白费。技术选型与适配是衔接需求与开发的核心环节。工程师需要根据业务场景的特点选择合适的基础大模型、开发框架和工具——不同的业务对模型的响应速度、精度、成本要求不同选型的合理性直接影响最终产品的表现。同时他们还要对行业相关数据进行预处理通过提示词工程优化模型输出或在必要时进行轻量化微调让基础模型更好地适配具体业务。此外设计合理的上下文管理规则确保模型理解连贯需求建立敏感信息过滤机制保障数据安全也是这一环节的重要内容。应用开发与对接则是将方案转化为产品的实操阶段。工程师会利用选定的开发框架构建应用的核心功能同时联动各类外部系统——比如将AI模型与企业现有的客户管理系统、数据存储系统打通确保数据流转顺畅。在这一过程中他们还需要配合设计团队打磨前端交互界面让技术功能以简洁易懂的方式呈现给用户实现从技术方案到产品形态的转化。测试与优化是保障产品质量的关键步骤。工程师会开展全面的功能测试找出并修复开发过程中出现的漏洞同时针对模型的响应速度、稳定性等性能指标进行优化。安全合规性也是测试的重点需要确保应用符合数据保护、隐私安全等相关规定。此外他们还会收集用户反馈通过调整模型参数、优化提示词等方式持续提升产品体验让应用更贴合用户实际使用需求。部署运维与迭代则贯穿产品的整个生命周期。工程师会通过云服务器或私有服务器将应用部署上线并实时监控运行状态及时处理突发故障确保应用稳定运行。随着业务需求的变化他们还需要对应用功能进行迭代更新同时编写完善的开发文档和使用手册为后续的维护和交接提供支持。03薪资情况与职业价值市场对这一职业的高度认可直接体现在薪资待遇上。据猎聘最新在招岗位数据显示AI大模型应用开发工程师的月薪最高可达60k。在AI技术加速落地的当下这种“技术业务”的复合型能力尤为稀缺让该职业成为当下极具吸引力的就业选择。AI大模型应用开发工程师是AI技术落地的关键桥梁。他们用专业能力将抽象的技术转化为具体的产品让大模型的价值真正渗透到各行各业。随着AI场景化应用的不断深化这一职业的重要性将更加凸显也必将吸引更多人才投身其中推动AI技术更好地服务于社会发展。CSDN粉丝独家福利给大家整理了一份AI大模型全套学习资料这份完整版的 AI 大模型学习资料已经上传CSDN朋友们如果需要可以扫描下方二维码点击下方CSDN官方认证链接免费领取【保证100%免费】