泰州做网站淘宝app下载量推广
本文是根据本人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设计样例问题， 通过样例问题进行测试
和业务人员以及其他研发人员一起测试调优全流程
