初学者如何学习AI问答应用开发范式

本文是根据本人2年大模型应用开发+5年小模型开发经验，对AI问答应用的开发过程进行总结。

技术范式

现在超过80%的AI问答是 提示词+ 大模型，  然后就是RAG 方案，这两种无疑是主流方案。

1、提示词+大模型

适合于本身业务不超过大模型的知识范围， 也就是说， 不存在太多的私有知识或sop

2、RAG

适合有私有知识 ，或者私有知识特别多 且对 答案的准确率有很高要求的场景

除了这两种呢？

第三种是工作流（function call），这种方案可以定制任意的流程，设计独一无二的业务处理方案，因此，再任何情况下，工作流都是一个必须的方案。

第四种是 Agent：平心而论，现在各种agent框架都不是特别完美，只能在一定程度上作为工作流的一种灵活实现。

最后一种是大模型微调， 具体的说， 大模型微调和另外4种方案都不冲突。大模型微调适用于有一定业务场景数据（几千数据以上）， 希望通过场景数据对 大模型回答文本进行优化的情况， 适用于风格写作， 专业问题分析（如金融，医疗，法律案例分析），当提示词无法满足业务需求，才应当开始考虑微调。

搭建框架推荐：maxkb，Fastgpt，dify，扣子

问答处理范式分析

在大模型出现之前， 我们也能做对话助手，当时主流方案是任务型对话系统， 基于Pipeline的实现。任务型对话系统把对话分成   语义理解NLU和 对话管理DM 两部分，其中NLU包括 意图理解和槽位填充， 槽位就是 要处理的各种属性值， 可以理解成一种表单， 表单会被存到数据库中。 意图理解就是对应当前的某个场景分类， 每一种分类在不同的槽位状态下会触发某种策略， 不同策略对应不同的回复。

NLU: 在比亚迪车里面说帮我播放周杰伦的稻香 ， 那么就可以提取出  场景=播放歌曲， 歌曲名=稻香。触发对应的 播放动作 ，这个触发策略就在DM中配置。

DM中的通用方案是FSM ，FSM是自动状态机，他是一个 状态 跳转图， 像一个网一样， 每个节点代表一个 状态 （当前动作或者策略） ， 从一个节点跳到另一个节点代表场景切换， 因此FSM很好的实现了ai对话的流程设计。

在大模型之后，这种流程就变成了工作流，然而， 工作流和FSM对话流依然不一样， 工作流实际上是设计一次交互的 策略 ，而FSM上可以直观的看到所有策略。因此， 工作流中会有各种 状态切换分支，不同分支切换不同的策略场景。

工作流标准组件：

- RAG 组件

- 分类模块（对应场景分类）

- 信息抽取（对应槽位）

- 判断器（对应 编程的 if）

- http模块 （对应编程的get post请求）

- 变量（可选，对应编程中的变量）

- 代码块（用于后处理 ，有时候需要）

笔者最近用了chatwiki发现并不适合。原因就是缺少组件 。后换成Fastgpt，这些功能都有。

拟人化：

拟人化是一个重要方向，实际上，大模型的本质就是拟人。现在的大模型已经拥有大量人类常识，大量专业知识，深度也非常深入。

但是为什么依然有人认为大模型和人差的比较远？

这是因为大模型没有办法判断自己是否真正理解一件事物，而人可以。大模型有编造答案的机制，对于大模型来说，没有判断是否存在某个知识的机制，只能根据“你知道xxx吗”来回答问题，并且并不能保证大模型的回答就代表大模型真正的状态。大模型并不能真正了解自己。

另外，大模型的主动性比较弱，当前对话模式主要是一问一答， 并没有出现大模型主导话题和持续输出的情况。实际上，人跟人的对话中， 有表达方和倾听方，其中表达方是可以持续不断地去输出， 甚至不需要倾听方提问。 在人机对话中却不能直接做到这一点。

大模型的目标性也不强，这点可以通过提示词来优化。在给大模型一个简单的目标之后，大模型的对话就会具有一定的引导性，类似于人类之间的沟通。

项目流程：

要开发一个基于LLM的AI对话应用，需要以下几个要点：

1、确认业务行业， 确认知识范围，尽量跟业务方多沟通（需要产品经理）

2、补充相关知识， 整理成标准文件，如markdown，xlsx（知识库，SOP搭建）

3、确定业务类型和场景， 缩小服务范围

4、确认词槽（信息属性）

5、确定主要模块或流程

6、确认验收测试标准，评估方案

7、确认开发技术选型，这一步不要在早期做，因为业务和工作流流程和知识都会影响到技术选型

8、开发迭代+测试

9、确定运营标准，设计数据飞轮（这一步不要让研发独自设计）

开发任务流程：

确定基本流程，搭建工作流或agent

调整提示词，直到适配业务。

丰富相关知识（FAQ或知识库），修改相关提示词，让回复更加自然

根据AI设计样例问题， 通过样例问题进行测试

和业务人员以及其他研发人员一起测试调优全流程