企业官网建设流程全解析

深圳网站关键词排名推广,小程序注册哪类商标,登陆Wordpress手机app,网页布局类型有哪些最近有学员出去面试#xff0c;他们面试的岗位为AI应用工程师、Agent应用工程师或者AI产品经理#xff0c;而最近经常会遇到的一个问题是#xff1a;什么是ReAct#xff0c;他主要是来解决什么问题的#xff1f;怎么说呢#xff0c;这个问题问的太大了#xff0c;他其实…最近有学员出去面试他们面试的岗位为AI应用工程师、Agent应用工程师或者AI产品经理而最近经常会遇到的一个问题是什么是ReAct他主要是来解决什么问题的怎么说呢这个问题问的太大了他其实不太适合作为一般岗位的面试题的。但要注意这不是说ReAct不重要相反ReAct本身很重要只不过要完全理解几乎需要将整个Agent架构梳理清楚所以多数人不大可能回答好这个问题另一方面对于多数人这个词汇是比较**“低频”**的因为多数中小型公司老板在用Agent做融资、讲故事不准备真用Agent解决生产问题所以很多同学并没有相关实践的机会最终的结果就是多数人只在一些文章读到过整体是很模糊的。所以ReAct是什么呢ReAct Reason Act是 2022 年 Google/Princeton 提出的一个范式**Reasoning**让LLM思考为什么和如何执行行动**Acting**让LLM执行具体行动并与环境交互**循环反馈**通过观察结果驱动下一步推理翻译翻译就是先思考、再执行但这个好像并不能回答为什么、是什么、如何做问题所以就得追根溯源了Why ReAct从模型的演进来说我们想解决的是他只能想/说不能做的问题。在这个基础上我们提出了Function Calling/MCP其基本语法就是预设一些工具挂在模型请求上每次由模型根据用户问题与工具参数描述、name等做判断是否调用。比如最经典的问题**成都这两天天气怎么样**想要由模型自动调用就需要这样写# 把“工具”挂在模型上这里是一个 get_weather 函数{type: function,function: { name: get_weather, description: 查询未来几天某个城市的天气预报, parameters: { type: object, properties: { city: { type: string, description: 城市名例如成都 }, days: { type: integer, description: 查询多少天的预报1-7 } } required: [city, days] } }}基本交互模型确定后紧接着问题就出现了真实场景工具太多、用户的问题太模糊、用户的意图过多…反正所有的问题叠加在一起就一句话模型在工具调用一块表现很差。于是这个时候思维链CoT就出现了他需要对用户问题进行分析将复杂的问题分解为一个个小步骤小工具调用再看着这些工具一个个执行成功一个再执行下一个希望由此增加整体AI产品体验最后总结一句ReAct想要解决的核心问题是把 “会思考” 和 “会操作外部世界” 这两件事绑在一起形成一个可观察、可迭代的任务。接下来我们用个简单例子来看看ReAct架构详细实现ReAct架构核心首先ReAct架构是一套循环流程... → 推理(Thought) → 行动(Action) → 观察(Observation) → ...这一范式的核心是在**“思考-行动-观察”的循环中完成任务。也就是说Agent一边思考如何解决问题一边调用工具获取信息然后根据观察**到的结果调整下一步计划直到得出最终答案。下面通过一个实例演示这个过程**2018 年世界杯冠军国家的总统是谁**他可能的完整过程是**Thought**用户的问题是“2018年世界杯冠军国家的总统”。这是一个复合问题需要拆解成两个步骤首先找到2018年世界杯的冠军是哪国然后查明该国的总统是谁**Action**调用搜索引擎工具查询关键词2018 年世界杯 冠军**Observation**返回“2018年世界杯冠军是法国。”**Thought**Agent得知冠军国家是法国。需要知道法国总统是谁**Action**再次调用搜索引擎工具查询关键词“法国总统是谁”**Observation**搜索结果显示“法国现任总统是埃马纽埃尔·马克龙Emmanuel Macron。”**最终回答**综合前面的信息Agent回答用户“2018 年世界杯冠军法国的总统是埃马纽埃尔·马克龙。”在解题过程中Agent经历了两轮**“思考→行动→观察”**的循环逐步把复杂问题拆解并求解。现在业内普遍认为并且有数据证明CoT可以有效降低模型幻觉这也是ReAct的重要意义之一接下来我们来看看简单实现一、状态管理├── 全局状态 (GlobalState)│ ├── task_id: query_│ ├── original_query: 2018世界杯冠军国家的总统是谁│ ├── task_graph: 任务依赖图│ └── verified_facts: {france_won_2018: true}│├── 会话状态 (SessionState)│ ├── current_plan: 当前执行计划│ ├── available_tools: [search, calculator, ...]│ └── context_window: 最近10轮思考-行动历史│└── 执行状态 (ExecutionState) ├── step_id: step_001 ├── current_action: {tool: search, params: {...}} └── partial_results: {}Agent架构实现到最后难点大概都是上下文设计现阶段常用的技巧是用一个“记事本”来记录复杂任务的信息包括用户问了什么已经知道什么尝试过什么方法哪些信息被验证过…要在AI工程中实现上述问题本身就挺难的我们用的这种分层设计允许系统在不同粒度上管理状态避免单一状态对象过于臃肿、也避免了整体项目复杂度。这里具体的实现我们就不展开了大家可以去OpenManus看看我们这里给出伪代码即可状态对象 { 任务ID: 查询_001, 原始问题: 2018世界杯冠军国家的总统是谁, 已验证事实: { 冠军国家: 法国, 法国总统: 马克龙 }, 思考记录: [这是一个复合问题需要两步...], 行动记录: [ {工具: 搜索, 查询: 2018世界杯冠军}, {工具: 搜索, 查询: 法国总统} ], 当前步骤: 3}二、决策引擎基础状态设计也可以叫上下文工程是第一步第二步将AI的思考过程展示出来就像我们解题过程分析当前情况确定还需要什么信息选择获取信息的方法Tools评估结果并决定下一步具体代码也不写了整个流程如图开始 ↓分析当前状态 ├── 已有足够信息 → 生成答案 ├── 需要外部信息 → 选择工具执行 └── 需要更多分析 → 深入思考 ↓执行决策 ↓更新状态 ↓检查是否完成 ├── 是 → 结束 └── 否 → 回到分析当前状态三、工具调用如上所述除了自身能力AI解决问题的办法只有Tools调用包括这里用到的搜索引擎工具以及我们最常见的知识库查询工具只要模型需要对外交互那么都是工具调用而ReAct模式中工具调用的部分流程很固定1. 匹配需求 → 确定需要什么工具2. 选择工具 → 哪个工具最适合3. 准备参数 → 工具需要什么输入4. 执行调用 → 运行工具获取结果5. 验证结果 → 检查结果是否可靠四、案例流程代码化这里问题依旧是2018世界杯冠军国家的总统是谁这里第一步就是状态初始化{ 任务: 2018世界杯冠军国家的总统是谁, 已知: {}, 需要: [2018冠军国家, 该国总统]}然后是首次决策AI思考: 这是一个复合问题先要找到冠军国家AI行动: 使用搜索工具查询2018世界杯冠军结果: 2018年世界杯冠军是法国队更新状态: 添加冠军国家法国然后是二次决策AI思考: 知道了冠军是法国现在需要法国总统信息AI行动: 使用搜索工具查询法国现任总统结果: 法国现任总统是埃马纽埃尔·马克龙更新状态: 添加法国总统马克龙最终在这个基础下生成答案AI思考: 已收集全部信息可以回答AI回答: 2018年世界杯冠军是法国法国总统是埃马纽埃尔·马克龙上述流程在倒推时候好像很简单但真的人模型一步步踩在点上其实是有点难的尤其是在复杂业务场景上比如有很多问题要考虑如何判断信息是否足够如何选择搜索关键词如何处理不确定性…上述每一次步骤失误就要完犊子所以生产项目会有很多纠错纠错的结果就是很浪费时间和Token。下面是一些小技巧五、小技巧首先Thought的组织与生成是比较关键的他的输入是状态信息和预设工具输出是下一步行动计划这里提供一套不错的模板基于当前已知信息 {已知信息}我们还需要 {缺失信息} 来回答问题。下一步应该 {行动计划}使用 {工具名称}其次在某些时候工具会很多为防止模型乱调用一般是需要对工具进行建模评分的比如需求查询实时天气候选工具1. 天气API实时、准确→ 得分 902. 网页搜索可能过时→ 得分 603. 历史数据库非实时→ 得分 30当然你说建模没问题具体依旧还是AI判断是否有可能不准这个是有可能的而且暂时没办法避免…然后就是持续的状态管理AI乱不乱状态上下文说了算1. 分层存储短期记忆 长期记忆2. 智能压缩保留关键信息删除冗余3. 版本控制支持回滚到之前状态4. 依赖跟踪记录信息之间的关联最后所有的AI产品都是需要测试数据集的或者说需要一套好坏评估标准比如任务完成率用户问题被正确解决的比例平均响应时间从提问到获得答案的时间对话轮次平均需要多少轮交互用户满意度用户对答案的评价思考质量AI思考的相关性和有效性工具准确率工具返回正确结果的比例循环效率平均每个问题需要的循环次数资源消耗API调用次数、Token使用量…这里就扯远了我们就不展开了…结语没有完美的价格ReAct与生俱来的会具有一些缺陷这里也需要提一嘴一、响应时间过长/耗Token当前大家都知道模型是不可尽信的为了保证输出的稳定性可能在流程上会有2次乃至3次校验这样来回的结果就是Agent的响应时长很忙并且Token消耗也很快。比如最近一个Manus的案例就是用户一次PPT就把一个月的Token用完了并且PPT还没完成于是投诉要求退款。二、过度思考过度思考的原因是模型带来的有可能换个模型就好了但问题还是如第一点所示AI并不知道问题简单与否从保险的情况下他情愿在简单的场景下也多加验证比如问题在简单问题上过度分析原因缺乏问题复杂度判断可能的解决方案又 • 添加问题分类器简单/复杂 • 为简单问题设计快捷通道 • 设置思考预算Token限制三、工具问题虽然现在GPT本身也是支持MCP的但是很多公司在使用的时候其实还是喜欢桥接一层底层自己调用Function Calling原因很简单没有生产级AI应用会毫无保留的使用第三方服务四、状态混乱应该说这不是ReAct的问题只要是复杂的AI项目只要涉及到意图识别那么上下文工程就会很复杂如何做好分层信息设计这就是AI工程的核心了这里不做展开……虽然ReAct有这样那样的问题但并不妨碍他现在成为事实上的标准了。现在回归面试题ReAct是什么呢ReAct是一套Agent的交互模型他的作用是让模型具有链接外部世界的能力并且尽可能降低幻觉的发生需要特别强调的是ReAct的全局日志是可调式、可观测的这也变相提高了我们AI产品的可控性。如何学习AI大模型如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享这份完整版的大模型 AI 学习和面试资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】这是一份大模型从零基础到进阶的学习路线大纲全览小伙伴们记得点个收藏第一阶段从大模型系统设计入手讲解大模型的主要方法第二阶段在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用第三阶段大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统第四阶段大模型知识库应用开发以LangChain框架为例构建物流行业咨询智能问答系统第五阶段大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型第六阶段以SD多模态大模型为主搭建了文生图小程序案例第七阶段以大模型平台应用与开发为主通过星火大模型文心大模型等成熟大模型构建大模型行业应用。100套AI大模型商业化落地方案大模型全套视频教程200本大模型PDF书籍学会后的收获• 基于大模型全栈工程实现前端、后端、产品经理、设计、数据分析等通过这门课可获得不同能力• 能够利用大模型解决相关实际项目需求 大数据时代越来越多的企业和机构需要处理海量数据利用大模型技术可以更好地处理这些数据提高数据分析和决策的准确性。因此掌握大模型应用开发技能可以让程序员更好地应对实际项目需求• 基于大模型和企业数据AI应用开发实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能 学会Fine-tuning垂直训练大模型数据准备、数据蒸馏、大模型部署一站式掌握• 能够完成时下热门大模型垂直领域模型训练能力提高程序员的编码能力 大模型应用开发需要掌握机器学习算法、深度学习框架等技术这些技术的掌握可以提高程序员的编码能力和分析能力让程序员更加熟练地编写高质量的代码。LLM面试题合集大模型产品经理资源合集大模型项目实战合集获取方式有需要的小伙伴可以保存图片到wx扫描二v码免费领取【保证100%免费】