在东谈主工智能领域，大型言语模子（LLM）正渐渐成为构建智能系统的中枢。本文通过两个推行案例，详备叙述了怎样从零启动，利用受限的FAQ文档和LLM才智，搭建一个智能问答机器东谈主，供全球学习。

LLM，是通往通用东谈主工智能之路的基础，但凡果真具有智能的系统也好、器具也罢，其里面一定是集成了好用的LLM（个东谈主不雅点）。

关联词，大言语模子的幻觉（高低文回答格格不入等）、不撤职指示、锻练和微调需蹧跶大量算力、微调需要专科算法东谈主士、落地ROI等问题，使得大言语模子的落大地临着各式种种的挑战和问题需要处置。

FunctionCall、RAG、few-shot、SFT、AI Agent平台等这些时候框架和产物的出现，使得庸俗东谈主平直使用LLM变得容易了起来~简短利用LLM通识才智搭一个“玩物”（比如英语白话陪练、软文写稿大众等）很容易，但要果真想用好LLM，且用在实质的业务场景中，并非易事。

那么本文，本东谈主就先以简略的case，演示一下：基于竣事的FAQ文档和LLM，来怎样从0-1搭建一个智能问答机器东谈主，以及过程中我碰到的问题及如哪里置的。

注：本文FAQ文档，以网页URL花样提供~后续未必代，将再共享FAQ是以文档文献花样推行的后果~感酷好的友友，敬请期待！

本文阅读温馨提醒❤：

内容有些长，约7000字，需要一些耐性，主要触及如下内容：

（1）推行case1：基于FAQ文档，利用LLM才智进行回复，条目超出文档领域，回复“不知谈”即可；——case1模拟的业务场景：专科性极强、对回答准确率条目极高的业务场景，比如金融、医疗等行业；

（2）推行case2：优先基于FAQ文档进行智能问答，若用户意图与FAQ计划，则利用LLM&RAG才智进行回复；若与FAQ无关，则利用LLM通识才智&联网才智，为用户推选回答。

（3）客服系统及智能客服的系统架构，以及我对于“基于LLM的「智能客服机器东谈主」”的一些念念考~

——case2模拟的是【任务型】机器东谈主为主，同期具备谈天才智的机器东谈主。

合计有用的宝子，建议储藏码住本文！防护事后找不到~

01 实验一：仅基于竣事FAQ文档回答问题，超出领域条目LLM回复“不知谈”

1.1 使用的器具、FAQ文档证据

使用器具：

扣子（华文版），器具地址：https://www.coze.cn/home

FAQ文档：

使用的是这个URL内容：

https://mp.weixin.qq.com/s/B0FskW3iPypdE9oj3Sfjcg（这是一个对于谷歌首创东谈主之一：谢布林近期的访谈，访谈对于他重回一线写代码，以及他对AI行业的成见、对AI的推行利用等内容，还有主合手东谈主与其谈及了谷歌Gemini与openAI的差距等话题）；

2.2 实验过程与实验收尾记载：

1）上手搭建-v0.0.1版：仅能基于竣事的FAQ文档，回答问题

模拟业务场景：只可基于竣事的FAQ回答问题，当用户发问超出提纲范围，条目LLM回复“不知谈”。

p.s.本东谈主之是以这么设定，是因为这种设定契合于医疗、医药、金融等行业（与东谈主生命财产关联性较强的行业/业务），即这些专科性相比强的业务场景，频繁条目LLM不知谈不要瞎扯、瞎掰，如果建议错了反倒影响用户体验~

step1：对Agent进行竖立

A、竖立LLM提醒词：v0.0.1版

# 变装你是一个专科高效的智能答疑助手，能够准确、快速地依据给定的 FAQ（常见问题解答）回答各式问题，FAQ 花样包括 url 网页一语气以及外部学问库 API。竣事的FAQ 文档就用这个：https://mp.weixin.qq.com/s/B0FskW3iPypdE9oj3Sfjcg## 技巧###技巧1：精确搜索 FAQ一朝吸收到用户的问题，随即在已有的 FAQ 中进行全面密致的搜索；如果找到计划问题及谜底，严格按照以下样式回复：=====**问题**：<用户提倡的问题>；**谜底**：<FAQ 中的对应谜底>如果莫得找到计划问题和谜底，就说“不知谈”即可。##适度- 必须严格按照司法样式输出内容，统统弗成偏离给定的框架条目。

B、竖立Agent其它项：大模子、推选问题、大模子所要调用的插件

a）LLM使用了默许的【豆包·function callMox 32k 精确模式】，插件配了“一语气读取”插件、“图片意会”、“kimi”~

b）“推选问题”竖立

Step2：对配好的Agent进行调试：

在Agent认真发布前，咱们需要对其进行调试（测试），测好了没大问题了，再发布。

在测试过程中，我对Bot进行了正负向测试，同期测试其我方坐褥的问题可否能回答上；

①正向测试：在提纲中的问题进行测试（比如：“让谢布林感到「WOW」的 AI 应用场景是什么？”、“1998 年，谢布林和谁成立了谷歌？”、“先容谢布林”、“谢布林有莫得用AI来作念数独游戏？”

等），测试机器东谈主能否回答上来，回答是否正确、是否按样式条目等；

②负向（界限情况）测试：不在提纲中的问题，进行测试（比如：“请先容一下奥特曼”、“奥特曼慑服光吗？”等），看其是否按条目回答“不知谈”，照旧瞎扯。

③系统自动生成的计划问题，测试。

调试过程中碰到的问题：

测试大模子时都日常，都能回答上。发布后，相似问题却回答作假。——这莽撞率是大模子的幻觉问题，不会是平台的BUG（个东谈主认为）（原因背面评释）；它推选的问题，它我方却回答不上。自动推选处界说的提醒词依然证据强调：推选其有才智回答的问题。幻觉问题的体现：给大模子配了插件，调试时调用了该插件，调试日常调通了。发布后，却不调用插件回答问题。调试过程中，调试阶段A一会自主调用插件（一语气读取），一会又不调用该插件（提醒词都是一样的）。发布后，对于统一问题，回答彰着矛盾。如下所示：

问题分析与处置

问题1：测试时，都日常都能回答上。发布后，相似问题，却回答作假。

原因分析：——这莽撞率是大模子的幻觉问题，不会是平台的BUG（个东谈主认为），因为平台BUG这种非算法类的，工程类的问题独一处置了就不会存在。极有可能是大模子幻觉问题，那暂时无解。

问题2：它推选的问题，它我方却回答不上。自动推选处界说的提醒词依然证据强调，推选其有才智回答的问题。

揣度原因1：它推选的问题可能是基于它基础的【通识才智】+【联网才智】，并莫得竣事于给它竖立的系统提醒词和身份。——但这个揣度又不是很合理，日常产物计齐整定是系统东谈主设是第一个层级的适度（如果我计划，默许情况，我就会这么计划，等于“and”关系）；或者系统东谈主设和自动推选的问题，默许“and”关系，此外还支持“or”。

揣度原因2：大模子幻觉。如果又是幻觉问题，那照旧不屈允置。

问题3和问题4原因分析：可能是系统提醒词写的不完善，比如统一个功能的插件配了好几个，又莫得明确和LLM证据什么时候用哪个，那么大模子就不错在面对发问时，自主采选。那当然就可能出现问题3和4。比如这个badcase：

问题3和问题4处置主义：

1）统一功能作用的插件，要么配1个；要么配多个的时候，为幸免引起歧义，在系统提醒词中，加以竣事：证据好什么情况下用这个插件，什么情况下用另外的插件。

这里，我删除了【kimi插件】（后续实验有需要用到kimi联网检索时候，我再加上），收尾如下：

但我又碰到了新的问题：

比如：

①我问它“1998年，谢布林和谁全部成立了谷歌？”（这个问题它之前能回答，当今又弗成回答了…）

②比如它莫得输出引申过程。

问题原因揣度是：URL中FAQ中如实莫得这个问题，而是通盘文档有这部天职容。战术：计划优化提醒词，回答范围不竣事于FAQ，而是通盘URL文献。

好吧。。。即使我优化了提醒词到查找通盘URL而非部分FAQ，对于问题1，它仍然是回答不知谈。我需要知谈它是何如引申的。

对于问题2（不输出引申过程的问题），后续加多提醒词条目即可。——不外这个也要防备，面向末端客户时，有莫得必要输出中间过程，或者是采选性地输出（产物童鞋需要防备）；

问题5：发布后，对于统一问题，回答彰着矛盾。原因分析：大模子幻觉问题。——后续计划加入few-shot，或在对话窗口中进行微调，然后利用大模子的Mememory才智进行优化。

2）v0.0.2：在v0.0.1版基础上，进行优化

v0.0.1版存在上头摆设的诸多问题，因此计划优先优化提醒词，处置一部分容易处置的问题

v0.0.2版竖立如下：

v0.0.2在v0.0.1版基础上，主要优化点在于：

1、加多“输出引申和念念考过程”；2、优化检索“FAQ”为“检索全文”；3、去掉容易引起大模子歧义的同等作用的多个插件，仅保留一个。

v0.0.2测试收尾：

v0.0.2调试收尾证据：

Bot按指示条目调用【一语气索取】插件了；√

也按样式条目输出了回答、输出了引申和念念考过程。√

暂时得志了我的业务条目~ 👏🏻

（但仍然存在一些幻觉问题，但由于本东谈主暂无时代元气心灵和才智去微调，是以该case暂且到这里。底下进行Bot的发布。

3）基于v0.0.2版竖立，发布Bot机器东谈主（基于外接FAQ的智能问答）

扣子平台的发布功能，提供了多种采选：你不错确立Bot的权限为公开、为私有。支持发布至豆包智能体广场（商店），支持发布到飞书应用中，支持发布至抖音中。还支持发布至三方平台生态中，微信、掘金等；发布花样支持URL（带界面），支持发布API花样；

这里，我采选了发布至字节Bot商店，但由于插件权限确立，即使是公开Bot，也只可我我方使用。

谢布林访谈-Bot在线体验一语气：https://www.coze.cn/store/bot/7415175444246495243?panel=1&bid=6dqk42qr89g0a（你们不错试试能否掀开，或者能掀开能弗成用）

同期这个Bot机器东谈主为实验性质的、“demo”性质的，距离果真的买卖化落地还有一定距离。

比如现时的这个Bot仍然存不才述幻觉问题：

比如问它：“让谢布林感到「WOW」的 AI 应用场景是什么？”它回答的照旧不竣工。可在对话过程中，调教它，获得想要获得的谜底~

4）后续的优化标的

线上的【谢布林访谈-FAQ】BOT仍然不是竣工的，还有诸多缺点，比如我在（3）末节提倡的幻觉问题。

后续处置决议不错是：few-shot（指示微调）->SFT（基于少许业务数据，对模子进行微调）；换LLM（字据业内东谈主士造就，参数目级越大的LLM，其指示撤职才智越强），从头引申上述过程（Bot竖立、Bot调试、Bot发布）；

02 实验二：优先基于竣事的文档回答问题，超出文档领域利用LLM通识才智+联网才智，给出推选回答

该case模拟的实质业务场景是：【优先基于领域学问】进行回复的任务型机器东谈主，同期具备谈天才智的机器东谈主。

2.1 v0.0.1 Bot提醒词等竖立

2.2 v0.0.1调试和预览

问题1：按照上述提醒词，用户的悉数发问，比如“你好”、“请先容你我方”、“请给我讲个故事”等，他都将这些问题视为【灵验输入】去检索URL文档~ 比如下图所示那般：

——该版块的问题是：

1、如果用户悉数问题，BoT均按照上头模版机械化地回答给用户，会有些蠢、也很机械，用户可能会被逼疯。。。其实对于一些“你好”、“你是谁”等问题，平直回答即可（不必说一大堆有的没的）；——问题严重进度P1

2、如果针对 “你好”、“你是谁”等与FAQ无关的意图，也要动作query去检索FAQ文档的话，系统的服从会大打扣头，彰着浪掷算计资源。——问题严重进度P0。

——是以，一般的作念法是：优先对【用户意图】进行标志和分类。谈天类的意图，调用【谈天】模块引申回复；当适应【FAQ问答】意图，则调用【FAQ文档问答】才智引申回复。

底下对v0.0.1版块进行改进，加多“意图分类”逻辑。

2.3 v0.0.1改进：加多“用户意图分类”判断逻辑，并调试、发布

战术证据：

1）当用户意图与FAQ文档计划，则参照FAQ进行回答；

2）如果用户意图与之不计划，需调用通识才智+联网检索才智，为用户推选回答。

温馨提醒：实质最佳的作念法应该是单特有一个LLM，完成【意图识别和分类】任务。另一个LLM只负责【FAQ文档问答】。然则本东谈主为推行服从，这里用一个LLM同期完成这两个任务（偷个懒😛）。

按上头战术对v0.0.1版提醒词进行修改和优化。

同期本东谈主测试了一些问题（与文档计划、与文档不计划的），个东谈主合计效果还不错，如下：

通过调试，认为达到了业务使用条目，发布即可~

03 全文总结与回来

本文以两个小case，利用Coze器具，简略推行了一下【基于LLM的智能问答助手】的0-1构建要领，以及构建过程中碰到的问题，以及处置念念路和处置前后对比~

1、其中case1，模拟的是专科性极强或回答准确率条目极高的业务场景，比如金融、医疗行业，条目大模子不知谈不要瞎扯，say no即可~

2、case2，允许大模子优先按照领域学问回答，当领域学问无法得志用户问题时，可允许大模子利用其通识才智和调用其它器具回复用户发问。——这不错映射到早期：【基于学问进行回复】同期具备谈天才智的机器东谈主，不至于显得“东谈主工智障”。

04 写在背面：我对于「智能客服机器东谈主」的一些推行造就和念念考共享~A、对于大模子“幻觉”问题的几点处置造就共享~

1）优先优化系统提醒词、修改大模子温度值参数为0，然后不错顺应地使用few-shot的要领，对大模子进行效果优化；但few-shot的弱点也很彰着，占用的tokens太多（因为每次输入、输出，都会把系统提醒词+用户发问动作输入token）；

——p.s.tokens越多，越用钱；如果不是外采的，部署的开源的话，tokens越多算计量也会相应变多，费算力，费存储。

2）换一个LLM。字据造就，参数目越大的模子对指示撤职效果越好~（参考小米落地推行），但也要辩证参考~

3）在调试过程中，如果不笃定大模子给出的内容，是否是正确的，可计划在提醒词中加多“援用源”

4）以上都不行，就微调吧。

即使你优化系统提醒词，到依然很好、计划的很全面了的地步了，但你仍然弗成百分百的侧目大模子的幻觉问题，这个差错仍然存在。——这时就要看业务可给与多大的差错。如果想要连接缩小差错，培植端到端回复准确率的话，那就【微调】吧！

B、对于企业是否基于LLM，从0-1搭建【智能客服】机器东谈主：

我认为，对于那些依然搭建了【智能客服】的企业来说，再基于LLM 搭建一个智能客服机器东谈主，会濒临底下几种采选：

-决议a：原有智能客服系统+LLM鼎新，利用LLM进行重构和鼎新；

-决议b：完全遗弃原有决议，从0-1基于LLM重搞；

-决议c：连接用蓝本的客服系统，不引入LLM；

我认为，大多企业会采选决议 a，即徐徐引入LLM,徐徐重构改进；可能也会有部分企业现阶段采选决议c：暂时不引入LLM，原因是：有些企业昂扬尝试革命、有些企业则相比垂青ROI，还有些企业相比垂青业务运行的褂讪性（比如在原有褂讪运行的业务系统中，引入LLM，带来了不可控的风险，那干脆不引入，等LLM再发展发展后再说，比如幻觉问题都有了尺度的熟练的决议）；还有些公司会采选决议b。

——那具体何如选，照旧各个企业的雇主们说了算的。

对于从来莫得建立过智能客服机器东谈主的企业，或者是新业务的新客服业务，不错计划基于LLM来接济。独一询查好提醒词、配备皆全相应的产物/运营、懂微调的算法、和工程化开发的前后端东谈主员就够了~

C、对于「大模子落地到硬件末端」的计划与必要准备事项~

在LLM最终落地时，还计划大模子的落地场景，是云霄，照旧其它边际端（比如智高东谈主机、智高东谈主表，或是平板、学习机等），因为这些硬件末端，其内存和算力都有限。——那针敌手机等硬件末端，LLM落地时还需要作念的职责是：蒸馏。

——蒸馏的真谛是说，保合手原有模子全体性能效果的前提下，尽量的压缩模子体积（当今一个参数目略微大点的大模子，动不动就大几个GB，10GB的也不在少数，这么的大而无当算力小的、内存小的开导根底带不动~）

D、对于0-1搭建/重构智能客服机器东谈主的必要职责：

笃定业务场景->笃定机器东谈主类型（任务照旧谈天，照旧聚会）->意图料理、机器东谈主基础门径搭建（学问库料理与竖立、技巧树等）->机器东谈主职责过程计划、用户数据监控逻辑计划->测试与上线->字据反映进行迭代~

客服系统全体架构（含智能客服系统架构），图片绘画by本东谈主（谨记是画了蛮久…）

好，那在原「客服系统」基础上拿LLM鼎新，LLM不错作念些什么呢？（无论是产物照旧时候，都是LLM求职口试高频问题哦）

本文的两个推行case，实质针对「智能客服系统」提供了一些谜底，即：

①利用LLM去作念意图的识别和分类；

②利用LLM，去作念文档的检索；

更多的场景？（学问库的接济？相似问的生成？自动化评估？….）想要了解更多的一又友，迎接评述区留言，与其它小伙伴探讨~

本文由 @南边碟谈 原创发布于东谈主东谈主都是产物司理。未经许可，糟蹋转载

题图来自Unsplash，基于CC0契约

该文不雅点仅代表作家本东谈主，东谈主东谈主都是产物司理平台仅提供信息存储空间工作。