在产品经理视角实现AI应用落地，如何做好AI技术选型，非常很重要，产品实现最终还是需从用户实际场景出发去平衡成本、效率和体验。最牛的技术不一定能兼容所有场景，按OpenAI对AGI的五层分类 Chatbot、Reasoner、Agent、Innovator、Organization。当前像Cursor、Manus这类Agent企业是先进生产力代表了，但也不适合用Agent去解决所有问题。产品设计界一句老话 “如无必要，勿增实体”，在AI应用领域同样适用。
在落地AI应用过程中，常使用到Prompt、RAG、Workflow、Agent 、模型微调五类关键技术，这五类技术分别适用于不同的场景，在选型过程中可以根据技术特性去执行落地。
先说结论：
只要“写得像样就行”（广告文案、新闻摘要）→ 先用 Prompt。加上输出格式校验，够用且快。
“必须说对事实”且依赖内部资料（产品政策、合规口径）→ 用 RAG，让答案有引用可追溯。
“一步做不完，需要审校/回退/多人协作”（合同审核、报表发布）→ 上 Workflow，把节点明文化。
“要自己会想、会找、会串API”（拉数→分析→生成方案→建工单）→ 试受限型 Agent，明确边界与停止条件。
“高频固定任务要又稳又省”（品牌风格文案、结构化抽取）→ 在已有闭环基础上做 SFT 微调。
作用：定义模型角色、任务目标、输入输出格式与约束，是最轻量的“产品功能”实现方式。
Prompt像一张写作提纲
适合：不需要特定知识、逻辑链条较短的创造性或归纳性任务。
价值： 零训练成本、即时生效、灵活性极高。
缺点：容易产生幻觉（胡编乱造），且无法处理多步骤复杂问题。
例子：活动文案、邮件改写、接口调用草案（自然语言→JSON）。
1、如何用好它
一份好的提示词框架可以包含以下六要素
1）角色 (Role)
2）任务 (Task)
3）背景/上下文 (Context)
4）要求/约束 (Constraints)
5）范例 (Example) (可选但强烈推荐)
6）目标/风格 (Goal/Style)
一个糟糕的提示词：“写一篇关于健康的文章。”
运用模板后的优秀提示词：
【角色】 你是一位经验丰富的健康营养师。
【任务】 撰写一篇科普短文，
【背景】 向30-40岁的办公室白领介绍如何通过调整饮食来缓解久坐带来的健康问题。
【要求/约束】 文章需要包含3个具体的饮食建议，每个建议配一个简单的食谱例子。文章风格要轻松易懂，避免使用难懂的医学术语。字数在600字左右，以Markdown格式输出，包含标题和小标题。
【范例】 例如，第一个建议可以是“增加膳食纤维摄入”，食谱例子是“一份燕麦莓果早餐杯”。
【目标】 目的是让读者感到实用和可行，并愿意立即尝试。
提示词撰写进阶
1）分步思维 (Chain-of-Thought)：对于复杂任务，要求AI分步进行。
示例：“请按以下步骤解决这个问题：首先，分析用户需求；其次，列出可能的产品；最后，给出你的推荐并解释理由。”
2）自我验证：要求AI对自己输出的内容进行审查和修正。
示例：“输出完成后，请以批判性的视角检查一遍内容，看是否有事实性错误或逻辑矛盾，并列出可能的改进点。”
3）提供外部信息：如果问题涉及特定文本，直接粘贴进来。
示例：“请基于以下会议记录【粘贴记录内容】，生成一份行动计划清单。”
4）迭代优化：AI的输出不完美时，不要重新提问，而是在原对话基础上给出修改指令。
示例：“很好，但第二个观点可以再深入一些，并提供数据支撑。” 或者 “能不能让语气更正式一点？”
2、参数调整
在使用提示词构建产品时，除了把user prompt写好之外，还可以通过调整模型输入项及参数去达到预期效果。
可重点关注
- system_prompt: 系统提示词，定义模型的行为和角色
- user_prompt: 用户提示词，模型需要回答的问题
- temperature: 控制输出的随机性，值越高越随机
- top_p: 控制采样范围，值越小越聚焦
3.1、文本纠错
以将大模型应用在文本纠错场景为例，让模型找到错别字，但文章一长模型输出时就会随机发散，这时候调整模型的temperature和top_p就会起到很好的效果。
以下图为例
模型1，设置
- temperature = 0.1 （控制输出的随机性，值越高越随机）
- top_p = 0.1 （控制采样范围，值越小越聚焦）
模型2，设置默认值
- temperature = 0.1 （控制输出的随机性，值越高越随机）
- top_p = 0.1 （控制采样范围，值越小越聚焦）
结果对比
模型1 temperature = 0.1 （控制输出的随机性，值越高越随机）
top_p = 0.1 （控制采样范围，值越小越聚焦）
在执行纠错任务时更加聚焦，更稳定且准确。
案例一：左侧为模型1，右侧为模型2
以此前定制的总结行业信息并进行格式调整为例，为了尽量保证文章信息不失真，以及收集到的多篇文章内容一起综合排版，文字内容不能不能由大模型随意发挥，在此前提下可以将大模型的TOP-P和temperature数值调低，减少偏离原文的情况出现。
这里可以扩展到很多场景，如果输入的信息源足够可靠，又依赖大模型去生成的情况下都应调低大模型生成的数值，这样才会更加贴近原文，减少因为模型随机性造成篡改的情况。
案例一：文本摘要生成应用
4、top_p和temperature是如何工作的
大模型在执行生成任务时，top_p 和 temperature 是最重要的两个参数，他决定了大模型的“创造力”和“确定性”。大模型在生成每一个下一个词（token）时，并不是只输出一个答案，而是会计算一个概率分布，即所有可能的词及其对应的出现概率。
例如，在句子 “The cat sat on the ___” 之后，模型可能会给出如下概率：
mat: 0.35
floor: 0.25
couch: 0.15
bed: 0.1
tree: 0.05
banana: 0.04
... (成千上万个其他词)
temperature 和 top_p 的作用，就是在这个概率分布的基础上，决定最终选择哪个词作为输出。
4.1、Top-p (核采样)
简单理解： 他决定入围下一个词的范围，池子有多大由 TOP-P 决定。p 代表概率累计和的一个阈值。
工作原理：模型会从概率最高的词开始，将它们的概率依次累加。当累计概率刚刚超过设定的 top_p 阈值时，就停止。然后，从这些被选中的词中，根据它们的概率权重随机选择一个输出。
举例：
假设 top_p = 0.8，还是上面的例子：
mat (0.35) -> 累计 = 0.35
floor (0.25) -> 累计 = 0.60 (仍然 < 0.8)
couch (0.15) -> 累计 = 0.75 (仍然 < 0.8)
bed (0.1) -> 累计 = 0.85 (已经 > 0.8，停止)
低 top_p (e.g., 0.1 - 0.5): 候选词池非常小，只包含极少数最可能的词。输出非常集中和确定。
高 top_p (e.g., 0.8 - 1.0): 候选词池很大（当设为1.0时，等同于考虑所有词）。输出更多样化。
适用场景：
当你希望排除那些明显不合理（概率极低）的选项，同时又想在合理的范围内保留一定的随机性时，top-p 是一个非常有效的方法。它比单纯的 temperature 更能智能地限制选择范围。
4.2、Temperature (温度)
简单理解：它决定了模型在选择下一个词时，是更倾向于选择高概率的“安全”词，还是冒险选择低概率的“惊喜”词。
工作原理：
低温度 (eg：0.1 - 0.5): 会锐化原始的概率分布。高概率的词变得更高，低概率的词变得更低。模型会变得非常保守和确定，输出内容高度一致、可预测、 factual（基于事实）。
适用场景： 事实问答、代码生成、数据提取、技术文档撰写——任何需要高度准确性和一致性的任务。
高温度 (eg：0.8 - 1.5+): 会平滑原始的概率分布。降低高概率词的优势，提高低概率词的机会。模型会变得更有“创造力”和“随机性”。
适用场景： 创意写作、诗歌生成、故事构思、角色对话、头脑风暴——需要多样性和惊喜的任务。
4.3、最终效果
低 Top_p + 低 Temperature ：极度确定、保守、缺乏变化。
高 Top_p + 低 Temperature ：最终效果：稳定且略有变化的合理输出。
低 Top_p + 高 Temperature ：这是一个非常矛盾且有冲突的设置，通常应避免使用。
高 Top_p + 高 Temperature ：最终效果：天马行空、极具创意且极其不稳定。
在使用Prompt构建产品时，可以根据实际场景选择参数输入，达到预期效果。
作用：通过检索增强将私有知识注入模型，解决大模型“训练数据缺乏、幻觉、垂直领域专业知识缺乏”等问题。
适合：问题必须“答得准、可追溯”。
例子：客服知识问答、内部政策问答、合规检索、研发知识库助手等。
如果基座模型能支持的足够大的token数，或领域沉淀的知识不多的情况下，不需要用到RAG，直接将上下文和用户Query一起送给大模型生成就行。
当你的场景适合RAG，也不要期待它能解决你所有的问题，RAG只是在你与大模型对话时，从海量领域数据里找到一些相关信息补充到上下文中，仅此而已。不能解决的问题还很多，比如异形数据结构化问题，知识切片后上下文断层问题，需多步推理才能解决的复杂问题等。这些都会影响内容生成质量。
RAG核心的功能就是针对用户Query，在送给大模型的前置环节在知识库中检索最相关的信息作为补充上下文，一起送给模型去做回答。在校验RAG系统效果时可以在两个维度上做要求：
召回率：能够找到最相关的信息；
准确率：不相关的信息不要；
RAG技术以及针对实际业务场景的设计，主要就是锚定这两个维度指标的提升去的。但实践中期望两个指标都非常高不太现实，因为RAG是一套非常复杂的系统，每一个环节的问题都会影响最终的结果。很多时候只能取个相对合适相对平衡的值。如果你的业务采用了RAG，这又需要回到产品经理要如何做选择去平衡成本、效率和体验的问题了。
用好RAG还是要回归到流程中的每一个节点针对业务场景不断优化核心流程。以下是最重要的关键节点：
数据解析、文本切片、 文本向量化建立索引、Embedding、检索、Reranking、生成。
1.1、文本解析与信息结构化
原始数据的质量直接决定RAG问答效果的上限。非结构化数据需要转化为富含语义的结构化信息。这个节点非常重要！！！
以下是一些知识解析实践后的方法总结：
- 使用专业解析库能有效保留文本格式、表格和布局信息。
- 对于扫描件或手写体等非标准文本，需结合OCR技术或视觉大模型优化信息提取。
-
表格数据的结构化处理
格式转换：将表格转为Markdown或HTML格式，确保数据结构清晰。
连续性保障：避免切片导致的上下文断裂，对空白单元格填充默认值，拆分合并单元格以保持逻辑完整。
语义强化：将表头与主体内容映射为键值对（KV），提升模型理解能力。
当前仍存在跨页表格合并困难、异形表格表头识别不准等问题，很难做到通用一套方案解决所有问题，需结合人工校验或针对特定规则补充。（此前与腾讯云团队交流，他们也是对特定一类格式的表格，如金融行业中财报结合算法去优化）。
以下是一些在解析环节可尝试的进阶方案：
元数据提取与实体增强
元数据提取：通过模型自动捕获文档的创建时间、作者、章节等信息，作为检索阶段的辅助依据。
实体抽取关联：利用NER技术识别关键实体（如人名、地点），并建立知识图谱关联，丰富语义表示。
这些是RAG系统高效运作的基础，只有精准的结构化数据，才能支撑后续的检索与生成质量。
1.2、文本切片
RAG上传的文本需切割为语义连贯的片段（chunk），平衡检索效率与上下文完整性。选择合适的方法切片是为了将chunk送给大模型生成时的信息时完整不包含噪声的，没有最好的方法，需根据自身业务场景和数据结构去判断用哪种切片方法。
主流方法对比：
除了上述切片方法之外，RAG还会面临表格数据，多模态数据（图、视频、音频等）。如何将这类数据解析，并采用合适的方式将信息切分成不同chunk也非常重要。
1.3、向量索引构建
文本向量化的质量与索引构建决定了检索效果的天花板，其目的是将文本切片转换为数值向量（嵌入），并建立高效的数据结构（索引）以实现快速相似性搜索。
在索引构建环节可以需与检索环节一起来看，是采用语义检索还是混合检索。
此外可以在建立索引时增强可以增加一些文本内容，优化检索效果。
语义增强就是将chunk和该chunk所在的文档内容（这里是整片论文）传给LLM，让LLM结合整个文档对这段chunk作个概述，然后把这个概述的信息append到chunk的内容中，从而增强在后续进行语义检索时的精确性。
1.4、检索
在建立索引时就应该做好数据库及技术选型，混合检索能兼顾语义和关键词精确匹配。
如果当前场景的检索需要兼顾关键词和语义的时候，可以考虑混合搜索（需要结合文档内容、chunking和关键字词构建等环节）；相对于关键字词匹配检索，混合搜索可以降低查询编写的规范性（不一定要有特定的关键词出现）以及提升查询的容错性（可能会有拼写错误或者不恰当的描述）；相对于语义相似检索，混合搜索可以增加一些领域专有信息的更精准匹配，提升检索结果的准确性。
检索查询问法优化
在检索环节除了根据业务场景选取语义检索或混合检索之外，还可以通过业务流程上的优化提高检索召回率和召回准确率。
1、查询扩展，为原始查询添加同义词，近义词，上位词，如建立领域知识词库，在查询时做替换提高检索查询准确率。
2、问题改写，让LLM将简短、模糊或不完整的查询重写为更全面、详细的形式。在多轮会话时这一步更重要，需要根据上下文信息，让模型改写生成新的完整准确的问题。
### Query改写任务prompt **任务目标**： 将用户输入的原始query改写为更完整、清晰的句子，需完成以下操作： 1. **指代消解**：将代词（如"它"、"这个"、"那里"）替换为具体指代对象 2. **成分补全**：补充缺失的主语/谓语/宾语等关键成分 3. **保持原意**：确保改写后的句子与原句语义一致 4。**严格控制改写**：如果用户输入的query中不含有代词，也不缺失 关键成分，禁止随意对成分进行补全 **输入格式**： ``` 原句：[用户输入的原始query] 上下文：[对话历史或前文（可选）] ``` **输出格式**： ``` 改写句：[完成指代消解和成分补全的句子] 拼接tag：[need_context/no_context] ``` **示例说明**： - **示例1**（需指代消解+成分补全） 原句：它需要充电 上下文：用户之前提到"我的手机电量不足" 改写句：手机需要充电 拼接tag：no_context - **示例2**（成分缺失） 原句：正在下载 上下文：用户之前说"我在浏览器里" 改写句：浏览器正在下载文件 拼接tag：need_context - **示例3**（无需修改） 原句：明天下午三点的会议取消了 上下文：无 改写句：明天下午三点的会议取消了 拼接tag：no_context **输出规则**： 1. **拼接tag判断**： - 若改写需依赖上下文信息（如补充主语），标记为`need_context` - 若改写仅通过单句即可完成，标记为`no_context` 2. 确保改写后的句子是**完整的独立句**，无成分缺失或指代不明。
3、子查询生成，对于复杂、多方面的复合查询，将其分解成多个独立的子查询，分别检索后再合并结果。但实践下来开源大模型扩写子查询效果不太好，有该场景诉求，建议使用微调的小模型，扩写的子查询任务会更聚焦。
4、元数据过滤，切片小节处有提到切片环节抽取元数据作为检索依据，在检索前或检索后，利用文档的元数据（如创建日期、作者、类别、来源）对结果进行过滤。它通过排除大量不相关文档，很大程度提升了召回准确率，去除了文档噪声。
1.5、重排
重排是将改写后的问题和每个召回的chunk单独汇总后，Rerank模型重新计算一个分数，再从高到低排序，选出前K（TOP-K）的chunk再送给大模型生成。
一般检索环节数量会大于等于rerank环节chunk数。，这样能用较低的代价提升Top N结果的精度和召回质量。
RAG简单说就是向量检索、重排、生成，但如果想要做好这套系统，需要关注流程每个非常多的细节，根据自身业务特点从数据环节开始设计，逐步提升每个环节的召回率和准确率，这样才能让你的RAG系统不至于成为一个玩具。
2、场景实践探索
在落地RAG应用时，会觉得这个过程像是个黑盒，有一份适合业务场景的评测数据集非常重要，在后续迭代验证时，能够多次使用可以用心准备。RAG系统在数据解析、文本切片、 文本向量化建立索引、Embedding、检索、Reranking、生成环节中每个细节的调整都会影响系统的召回率和准确率，最终影响模型生成答案的质量。
当用户提问，经过RAG系统最终送给大模型时的文本结构可能包括：
system prompt
chat history（如有多轮）
召回重排后的chunk
user query
还有送给大模型的参数
当然如ChatDoc页面端也支持一些参数提供给用户配置。
2.1、RAG应用到意图识别的尝试
上文说到RAG是一套非常复杂的系统，从数据解析、文本切片、 文本向量化建立索引、Embedding、检索、Reranking每个环节都值值得深入研究，其实把RAG拆开来看如检索环节也可以将能力复用到其他场景中比如“意图识别”，根据用户query，匹配预先配置的问题库，比对语义相似度去识别用户意图，再执行后续流程，下图是一个RAG系统结合意图识别的案例流程。
“Agent”有多种定义方式。有人将其视为完全自主系统，能在较长时间内独立运行，使用各种工具完成复杂任务。也有人用来描述更固定的、预定义的工作流。Anthropic将这些变体归类为类Agent系统，但在工作流和智能体间做了重要区分。总的来说：
Workflow 本质上是一套预定义的固定流程，类似于工厂中的流水线。每个步骤都具有明确的输入与输出，节点之间的逻辑严格按预定规则执行——一旦条件满足，便自动进入下一阶段。
Agent 的运行方式不是在预定轨道上推进，而是在开放环境中主动探索“如何实现目标”。一个典型的 Agent 应具备以下三大核心能力：
二者对比如下图：
概念描述还比较抽象，有几张执行流程图就能理解区别了。
2、一个简单的ReAct Agent流程
核心就是“思考(Thought) - 行动(Action) - 观察(Observation)”的循环，用伪代码表示：
一段React agent核心代码可以分为几段
1、定义模型可自主调用的工具（tools）。
2、system prompt中描述清楚任务规则和约束条件。
publicclassReActAgent { privatestaticfinalStringAGENT_ACTION_TEMPLATE="工具名称，必须是[{0}]中的一个";
privatestaticfinal List<Tool> TOOLS = Arrays.asList( Tool.builder() .name("查询补货计划单详情") .desc("根据补货计划单号查询补货计划单详情") .parameters(Collections.singletonList( Tool.Parameter.builder() .name("orderCode") .desc("补货计划单号") .type("string") .required(true) .build() )) .build(), Tool.builder() .name("审批补货计划单") .desc("根据补货计划单号审批补货计划单") .parameters(Collections.singletonList( Tool.Parameter.builder() .name("orderCode") .desc("补货计划单号") .type("string") .required(true) .build() )) .build() );
3、模型在上述定义的规则中循环，知道任务执行完成。
从上述流程可以得出，Agent模式是将业务运作规则、可调用的工具提供给大模型后，模型根据用户的输入判断任务流程，并开始执行任务，直到模型根据规则判断任务已结束，最后输出结果给到用户，在这过程中是模型自主在基于已有的上下文信息，业务流程定义，可选工具，用户问题，自主执行任务，知道问题结束。
当模型面对一些开放性问题，可能需要用到一个或多个工具来解决问题时，有很大的优势。（假定tools和模型能力都很完善的情况下）
比如用户提问：国庆快到了，想去北京玩。
理想状态下，Agent可能会自主去查日历，根据你平时的行为习惯分析，给你规划好路线，MCP拉起高德地图、携程、美团等App完成一系列订票、订酒店、找餐厅、生成出行计划等一系列操作，最终生成一份出行清单，你照着执行即可。
当然Agent也可能突然进入一个无用的循环中，导致任务推进不下去，这又需要定义业务规则去终止或转换流程让任务继续执行下去，当然这属于Agent优化中事项了。
在大模型应用中，Workflow（工作流）是指将复杂任务拆解为一系列可顺序或条件触发的标准化步骤，通过预定义的节点和规则实现自动化执行。与具备自主决策能力的 Agent 模式不同，Workflow 更强调流程的结构化、可控性和可重复性。
工作流是一个预先定义好的流程，根据输入项一个环节到下一个环节逐步执行，到任务最终执行完输出结果。
例如，一个内容生成工作流可能依次包括：主题分析 → 资料检索 → 大纲生成 → 分段撰写 → 校对输出。
每个节点可以是工具调用、条件判断、RAG检索、数据处理或人工审核等。例如：
工具节点：调用搜索引擎、数据库查询、图像生成模型等；
判断节点：根据上下文决定流程分支（如内容质量不合格则触发重写）；
聚合节点：合并多个节点的输出结果。
由于流程固定，每个步骤的输入、输出和状态均可追踪，更符合企业级应用对稳定性、审计和合规性的要求。
4、协同方式
在大模型应用中，Workflow 与 Agent 并非互斥，而是协同互补的关系。二者的结合可充分发挥结构化流程的可靠性与智能决策的灵活性，构建既稳定又自适应的系统。
具体协同方式如下：
例如，在智能写作场景中：
Workflow 固定主干流程：主题分析 → 大纲生成 → 内容撰写 → 质量校验；
在“内容撰写”节点引入 Agent：假设给定Agent三个tools，
检索外部信息作为补充，并清洗资料；
调整写作风格，段落格式适应上下文；
质量核对校验。
那么在内容撰写整个流程中，会先按既定步骤，分析主题，生成大纲，Agent撰写内容并完善，丰富格式，校验质量后输出终稿。
当然最终是否采用此方案还是要回归场景出发，平衡成本、效率和体验。
1、微调是什么
微调是指在预训练大模型基础上，利用特定领域数据进行进一步训练，使其适应特定任务或领域需求。它能让模型能够针对不同领域（如医疗、金融）更精准的执行任务，它能弥补预训练模型在特定任务上的不足，显著提升模型在目标领域的表现。与RAG的区别在于RAG属于外挂信息，提供到上下文中让模型生成回复。微调是通过语料训练调整模型参数，让模型在后续计算输出内容时不断贴合训练的数据。
全量微调（Full Fine-tuning）
特点：更新全部预训练参数
优势：理论性能最优，可深度适配任务
局限：需高算力（A100/H100级GPU）、大存储（数十GB模型副本），存在知识遗忘风险
适用：科研机构/企业级应用，追求极致效果
参数高效微调（PEFT）
特点：冻结主干参数，仅训练新增模块
优势：显存需求降低90%+，存储仅需MB级，支持多任务快速切换
代表技术：
• LoRA：在关键层注入低秩矩阵
• Adapter：插入轻量FFN模块
• Prompt Tuning：训练输入前缀向量
• Prefix Tuning：逐层添加任务前缀
有监督微调（SFT）
数据要求：高质量指令-回答对
目标：建立基础对话能力
核心作用：预训练模型向实用对话模型的关键转化
强化学习微调（RLHF）
流程：SFT→训练奖励模型→PPO优化
目标：优化回答的有用性、安全性
特点：多阶段训练，依赖人类偏好数据
自反馈微调
DPO：直接优化偏好数据，无需独立奖励模型
RRF：多答案生成+模型自选优解
2.3、按数据形式分类
全监督：标注完整数据集（SFT典型）
少样本：基于极少量样本快速适配
在线/离线：离线：固定数据集训练，在线：实时用户反馈迭代
参数效率与计算需求通常呈反比关系：参数越高效的方法，计算需求越低。
性能潜力与训练成本正相关：全量微调和RLHF性能最好，但成本最高。
LoRA在多个维度上取得了很好的平衡，使其成为当前最受欢迎的微调方法。
2.5、选择建议：
资源受限场景：优先LoRA等PEFT方法（训练GPU成本节省90%+）
对话质量要求高：SFT+RLHF/DPO组合方案
数据充足且算力充沛：可尝试全量微调（注意过拟合监控）
快速任务迁移：采用Prompt Tuning或少样本微调
3、微调关键流程
3.1、数据准备
收集与目标任务相关的训练数据，注重数据质量与标注准确性，并进行必要的清洗与预处理。
3.2、选择基础模型
依据任务特点与数据特征，选择合适的预训练模型作为微调基础。
3.3、确定微调策略
根据任务需求与资源条件，选择全微调或部分微调（如仅调整顶层参数），明确微调层级与范围。
3.4、配置超参数
设置关键训练超参数，包括学习率、批量大小、训练轮数等，这些直接影响模型收敛速度与性能。
3.5、初始化模型参数
基于预训练权重初始化模型。全微调通常复用全部原有参数；部分微调则可能随机初始化特定层。
3.6、执行训练
使用选定策略与数据对模型进行微调，通过优化算法迭代更新参数，以最小化损失函数。
3.7、效果评估
效果评测可以通过模型能力、体验、安全三个维度进行评估
- 能力维度：使用定量指标（如准确率）在测试集上衡量核心任务性能，并通过领域知识题库检验专业性和事实准确性，同时利用通用基准测试以避免灾难性遗忘。
- 体验维度：通过人工盲测，让评估者基于有用性、流畅性等主观偏好选择最佳输出，并通过多轮对话测试来验证模型上下文理解和交互的自然度。
安全维度：通过红队测试主动攻击模型以检验其生成有害内容的风险，并使用偏见基准数据集量化分析输出中的公平性问题，确保其符合伦理与合规要求。
模型微调的整个过程应是一个迭代循环，根据评估结果反复调整数据、超参数甚至微调策略，直至模型达到所有预期目标。
综上所述，大模型应用的技术选型本质上是一场围绕用户场景的精准匹配与实践权衡。从轻量敏捷的 Prompt 工程，到可靠溯源的 RAG，再到流程严谨的 Workflow 与自主决策的 Agent，最终至深度定制化的模型微调——每一项技术都有其明确的适用边界与价值定位。
AI应用落地，从不依赖于追求“最先进”的技术，而在于选择“最合适”的方案。产品经理应始终以用户真实需求为锚点，在成本、效率与体验之间寻求最优解，遵循“如无必要，勿增实体”的奥卡姆剃刀原则，用简洁可靠的架构解决复杂问题。随着模型能力与工程方法的不断演进，未来会有更多技术路径的融合与创新。但核心始终是：理解场景、定义问题、选择工具、创造价值。
粤ICP备14082021号
免费POC，
零成本试错
