垂直专家联邦：面向存储与算力困境的另类破局路径——一份技术思路探讨摘要当前以单一通用大模型（LLM）为核心的技术路径，在算力效率和存储经济性上正面临结构性瓶颈。我提出一种名为 “垂直专家联邦” 的差异化架构思路。该思路的核心是：不再追求构建参数更大、更全能的“通才”模型，而是转向培育一系列深度聚焦、高度优化的“专才”模型，并让用户通过主动提供轻量化的“基础画像”来获得精准服务。 我相信，这条聚焦专业化、个性化的路径有望在显著提升专业场景用户体验的同时，从本质上缓解AI对存储与算力的巨大压力，并为华为发挥其端-边-云协同的生态优势，开辟一条独特的AI发展道路。补充说明： 根据我的观察，当前市场上真正深入特定专业领域、具备深度功能和良好交互体验的专用AI模型非常稀少，且功能大多停留在通用模型的浅层封装。这恰恰表明，从“通用智能”到“专业智能”的转化路径上，存在着尚未被充分开发的显著市场真空与体验鸿沟。本构想正是试图系统性地填补这一空白。第一章：问题诊断——当技术路径陷入“暴力破解”的惯性当前AI发展的主流路径，本质上是一场围绕数据规模和算力总量的“军备竞赛”。各大厂商的核心思路惊人一致：收集更多数据、投入更大算力、训练更庞大的模型，试图通过“暴力破解”的方式逼近通用人工智能。这一路径存在双重困境：技术困境：专业场景下的“伪智能”——模型无法形成持续的专业记忆，每次交互都是冷启动。惊人的资源浪费——处理垂直任务时，90%以上的算力消耗在与该领域无关的参数上。低效的数据利用——为获得1%的专业知识，必须存储和处理100%的混杂数据。经济困境：训练成本已进入“亿美元俱乐部”，但专业领域的实用价值提升却极为有限。更为关键的是，这条路径将用户置于完全被动的位置——用户只是数据提取的对象，是模型训练的资源，却无法主动参与AI的塑造过程。问题的核心或许在于：我们是否高估了“让机器变得更像人”的必要性，而低估了“让机器更好地服务人”的可行性？我的基本观察是：现有的技术范式并未失效，但应用思路可能需要调整。 无需颠覆底层技术，只需改变协作方式——从“模型被动猜测用户需求”转向“用户主动参与模型塑造”，或许就能用现有算力实现效率的倍增。第二章：我的构想——一条从“专业场景”切入的务实路径基于对现有AI效率瓶颈的观察，我的构想遵循一个务实的逻辑：与其投入海量资源追求通用的“全能”，不如将力量集中于一个个具体的“专精”领域。这本质上是一次思路转换——将构建智能的核心，从后端对混杂大数据的被动挖掘，转向前端对用户高质量意图的主动承接。我的具体思路分为两步：第一步，是打造真正好用的专业工具。在编程、法律、烹饪等知识结构明确的领域，构建一个个高度聚焦、深度优化的垂直模型。它们不必“万事皆通”，但必须在自己的领域内做到响应快速、答案可靠、理解到位。例如，一个“代码助手”的核心使命，就是准确理解开发者的意图并生成可用的代码，而不是与之讨论哲学。第二步，是建立一种基于“能力画像”的简洁共识。当用户开始使用某个专业工具时，系统将通过最简化的方式（如选择标签或一句话描述），引导用户建立一份 “基本能力画像”。这份画像的目的，是快速确立一个专业的对话基线，它例如包括以下基本信息：主要专业领域（例如：云计算架构、民事诉讼、面点烘焙）关键技能或知识范畴（例如：熟悉Kubernetes与Go、精通合同法、擅长苏式糕点）大致的经验层级（例如：专家、熟练、入门）例如，一位工程师使用“代码专家”时，可快速确认：“我的领域是后端开发，精通Java与微服务架构，有超过8年经验。” 此后，系统所有回应都将默认基于“与一位资深Java架构师对话”的共识展开，直接切入技术核心，无需任何基础知识的对齐过程。这一构想将直接带来颠覆性的用户体验：当用户使用这套系统时，将彻底告别与通用AI反复“冷启动”的漫长磨合。系统凭借精准的“能力画像”与对应的专业模型，能从第一句话开始就用专家的语言回应用户。用户无需再花费时间“训练”AI，也无需从冗长的答案中筛选有用信息——问题越专业，回答越精准。这一路径的优势在于务实与可持续：对用户而言，他们因为工具本身好用而使用，并在使用中获得精准服务，自然愿意提供更清晰的意图描述。对系统而言，每一次成功交互都获得了一份 “意图-结果” 的高质量配对数据，这远胜于从海量日志中反向推测。由此，一个良性的飞轮开始转动：工具越准，用户越愿意用；用户越愿意清晰表达，工具就进化得越准。更重要的是，这条路径天然具备强大的成长性。当一个专业模型（如“代码宗师”）凭借极致的体验建立起口碑后，将产生裂变效应：用户会自发地提出更细分、更前沿的需求，从而催生出无数个高度精细化的“微型专家”。这些“微型专家”并非孤立存在，它们能通过预先定义的协议进行协作式调用，共同解决复杂的交叉问题。用户无需知道背后是哪个模型在工作，他们只需提出问题，系统便会自动寻找、组合最合适的“专家”来提供服务。最终，这将不再是一个个独立的工具，而是一个在华为生态内自然生长、自我演化的 “智能有机体” 。用户会发现，无论问题多么细分或跨领域，都能在这个系统内找到解决方案——从修改一行代码，到设计一顿营养餐，再到规划一次跨境法律咨询。当“有任何专业事情，都习惯用华为的AI系统”成为稳固的用户心智时，华为便构建起一个从硬件、软件到服务，再到知识网络的、完整且生生不息的生态链。对于正寻求突破AI算力与存储效率瓶颈的华为而言，这条从“专业”到“智能”、从“用户主动投喂”到“数据飞轮”，并最终导向“生态链”的路径，无疑提供了一个坚实且充满想象的差异化方向。第三章：构想背后的价值洞察3.1 对效率困境的潜在回应虽然本构想并非直接针对硬件存储介质，但它从数据组织和计算模式上，为缓解当前AI的存储与算力压力提供了一种思路：存储层面：垂直专家模型无需存储海量混杂的通用语料，只需专注于本领域高纯度、高价值的知识晶体，可能大幅提升存储的信息密度。算力层面：处理任务时，系统仅调用相关领域的专家模型，避免了在通用模型万亿级参数中“大海捞针”的无效计算，让每一焦耳的电量都产生更直接的价值。3.2 与华为生态的战略协同点此构想若能起步，可以与华为的独特优势深度咬合：昇腾芯片：专家模型规模更小、任务更确定，易于在昇腾AI处理器上实现极致的性能优化和能效比。鸿蒙生态：可以化为一个个即点即用的原子化服务，深度融入华为终端，打造“专业问题，华为秒答”的体验壁垒。华为云与行业市场：每一个垂直专家，都是打开一个高价值行业市场的“楔子”，能带动从咨询、部署到服务的全链条。3.3 一个额外的可能性：“拆分-画像-再融合”的螺旋本构想还有一个更深层的技术想象：当这些垂直专家模型通过“用户画像”的反馈变得极其精准后，我们是否可以将其视为优质的“能力模块”，反哺或重构出一个新一代的通用大模型？ 这或许能为大模型的演进，开辟一条“从专业中来，到通用中去”的新路径。结语我需要坦诚说明，前述关于产业影响与生态演进的探讨，仅是基于技术逻辑的推演与想象。这些设想能否实现，完全取决于一个更基本问题的答案。本构想的核心意图非常朴素：尝试将综合型大模型按领域“拆分”，为独立的专业模型引入用户主动构建的“基础画像”，以此探索能否打造出让用户感到“既懂自己，又足够专业”的AI工具。 在此基础之上，我们还可以探索一个更深层的可能性：将这些通过实践验证、已经具备高度专业性和用户理解力的独立工具，再次进行整合，或是将其核心能力模块反哺至原有的大模型中，从而构建一个既拥有通用知识广度、又具备深度专业精度的新一代融合模型。如果这个“拆分-画像-再融合”的螺旋式路径能被验证有效，那么它不仅能为用户提供立竿见影的精准体验，更可能为大模型自身的演进开辟一条“从专业中来，到通用中去”的新路径——让模型的通用能力，建立在无数个经过实战检验的专业根基之上。因此，这份文档更接近于一份着眼于路径差异的“技术设想”。它无意提供终极答案，而是希望在当前以规模为核心的主流竞争路径之外，勾勒出一个可能存在的、以专业与协作为重心的新思路。需要特别说明的是，文中提及的效率提升等量化分析，主要基于技术逻辑的推演，旨在指出了一个可能的方向与趋势。 此路是否可行，唯有实践能够给出答案。本文档由个人独立思考形成，旨在进行技术思路探讨。

凌晨一点，突发剧烈头痛，视力也开始模糊。在这种紧急情况下，使用通用AI助手寻求建议，往往只能得到“请及时就医”这样正确但无用的回答。用户真正需要的，是具备初步症状识别、风险评估和就医指引能力的专业助手。这正是当前通用大模型在医疗场景中的典型短板：● 缺乏专业医学知识体系，无法进行症状关联分析● 回答过于保守，难以提供具针对性的分级建议● 无法识别症状组合背后的潜在疾病类型差异现在，通过LLaMA-Factory Online平台，我们只需要2小时，就能基于CareGPT和Qwen3-8B模型，系统性地构建一个真正“懂症状、能判断”的智能医疗助手。实际效果对比如下：用户提问：“我突然剧烈头痛，视力模糊，可能是什么原因？通用模型回答虽然结构完整，但存在明显不足：建议过于保守，仅笼统地建议“观察症状”和“及时就医”，缺乏具体的风险评估和紧急情况指引，对急性症状的响应不够充分。微调后的医疗助手回答展现出明显的改进，回答涵盖了更全面的病因分析，从眼部问题到颅内状况，从血压因素到偏头痛，提供了更具参考价值的医学信息。虽然仍有优化空间，但已经展现出从“通用回复”到“专业解答”的明显进步。   这种具备症状初步分析、风险评估和明确就医指引的专业回应，正是通过CareGPT医疗语料与Qwen3-8B的高效微调实现的。在接下来的内容中，我将完整演示如何通过LLaMA Factory Online平台，在2小时内完成从数据准备、模型微调到效果验证的全流程。配置概览说明配置参数配置项是否预置说明模型Qwen3-8B是Qwen3-8B是一款轻量化的开源大语言模型，具备较强的通用语言理解与生成能力，支持多场景适配，且在医疗等垂直领域可通过领域适应训练进一步优化专业性，适配中小规模算力需求，兼顾性能与部署灵活性。数据集ChatMed_Consult_Dataset和HuatuoGPT2-SFT-GPT4-140K否ChatMed_Consult_Datase由Wei Zhu主导构建，是中文医疗问诊数据集，补全中文医疗LLM训练数据，供模型微调；HuatuoGPT2-SFT-GPT4-140K由FreedomIntelligence团队打造，是大规模中文医疗指令微调数据集，借GPT-4生成优质响应，提升医疗LLM指令能力，支撑监督微调。GPUH800*4（推荐）-模型规模较大，建议配置足够显存。微调方法lora-显著降低计算与存储成本，兼具高性能与部署灵活性。资源消耗预计使用推荐资源（H800*4）进行微调时微调过程总时长约2h16min。具体操作步骤步骤一：数据准备1.  下载数据集。数据集下载完成后，需上传至文件管理。● 下载ChatMed_Consult_Dataset数据集。● 下载HuatuoGPT2-SFT-GPT4-140K数据集。  2.  数据格式转换。LLaMA Factory作为主流的大语言模型微调框架，对医疗问诊类数据有明确的格式要求（需包含instruction、input、output核心字段，支持多轮对话的history字段可选）。针对ChatMed_Consult_Dataset数据集原有的 “query-response” 二元结构，需通过字段映射与格式重构，将其转换为LLaMA Factory兼容的数据格式。数据格式转换的具体步骤如下：a.  进入LLaMA-Factory Online平台，单击“控制台”，进入控制台后单击左侧导航栏的“实例空间”，然后在页面单击“开始微调”。  b.  在弹出的页面选择“CPU”，核数选择“2核”，然后单击“启动”。  c.  实例启动后，单击[VSCode处理专属数据]页签，进入VSCode编辑页面。您也可以根据需要打开JupyterLab处理数据，本示例指导您通过VSCode处理数据。d.  在VSCode页面左侧user-data/datasets目录下（如图①）新建一个.py后缀的文件（如图②），然后复制以下命令至文件中（如图③）。import json import pandas as pd import jsonlines from typing import List, Dict   def chatmed_to_llamafactory( input_path: str, output_path: str, instruction: str = "你是专业的医疗咨询助手，请根据用户的医疗问诊需求，提供准确、易懂的疾病解答、治疗建议与日常注意事项，回答需符合医学常识，同时提示用户最终需咨询专业医生确认诊断。" ) -> None:   raw_data: List[Dict] = [] with jsonlines.open(input_path, "r") as f: for line in f: raw_data.append(line) llamafactory_data: List[Dict] = [] for idx, item in enumerate(raw_data): try: if "query" not in item or "response" not in item: print(f"跳过第{idx+1}条数据：缺失query或response字段") continue converted_item = { "instruction": instruction, "input": item["query"].strip(), "output": item["response"].strip(), "history": [] } llamafactory_data.append(converted_item) except Exception as e: print(f"处理第{idx+1}条数据时出错：{str(e)}，已跳过") continue with open(output_path, "w", encoding="utf-8") as f: json.dump(llamafactory_data, f, ensure_ascii=False, indent=2) print(f"转换完成！原始数据共{len(raw_data)}条，有效转换{len(llamafactory_data)}条，输出路径：{output_path}")   if __name__ == "__main__": INPUT_FILE = "./ChatMed_Consult-v0.3.json" OUTPUT_FILE = "./datasets/multi-med.json" chatmed_to_llamafactory( input_path=INPUT_FILE, output_path=OUTPUT_FILE, )    e.  VSCode页面，新建一个终端，依次执行以下命令，进行数据格式转换（如图①和②）。conda activate /opt/conda/envs/lf python testshuju.py  💡提示testshuju.py为本示例新建的文件，请根据您的实际情况进行替换。回显信息如图③所示，说明数据格式转换成功，且转换后的数据存放在/datasets/multi-med.json中，即原数据集文件ChatMed_Consult_Dataset经格式转换后生成新的数据集文件multi-med。  3.  数据集检测。a.  返回LLaMA-Factory Online控制台，单击左侧导航栏的“文件管理”。b.  单击目标数据集右侧“操作”列的"数据集检测"，检测数据集。如下图所示，若“数据集格式检测”结果显示“符合”，则表示数据集符合格式要求。  步骤二：模型微调1.  进入LLaMA-Factory Online平台，单击“控制台”，进入控制台后单击左侧导航栏的“模型微调”进入页面。2.  选择模型和数据集，进行参数配置。○ 本实践使用平台内置的Qwen3-8B作为基础模型（如图①），数据集为ChatMed_Consult_Dataset（multi-med）和HuatuoGPT2-SFT-GPT4-140K（如图②）。○ 训练配置：选择“专家微调”（如图③）；“训练轮数”配置为“2”，“单CPU批处理大小”配置为“24”（如图④）。○ 分布式配置：打开“DeepSpeed”开关（如图⑤）。○ 资源配置：推荐卡数为4卡（如图⑥）。○ 选择价格模式：本实践选择“极速尊享”（如图⑦）。○ 开始训练：单击“开始训练”，开始模型训练。   💡提示配置模型与数据集后，系统将根据所需资源及其相关参数，动态预估任务运行时长及微调费用，您可在页面底部查看预估结果。 3.  通过任务中心查看任务状态。 在左侧边栏选择“任务中心”，在“模型微调”页面即可看到刚刚提交的任务。  单击任务框，可查看任务的详细信息、超参数、训练追踪和日志。  4.  任务完成后，模型自动保存在"文件管理->模型->output"文件夹中。可在"任务中心->基本信息->模型成果"处查看保存路径。     步骤三：模型评估1.  单击页面左侧导航栏的“模型评估”，进行评估训练配置。2.  微调模型选择上一步骤微调后的模型(如图①)，评估数据集为ChatMed_Consult_Dataset（multi-med）和HuatuoGPT2-SFT-GPT4-140K（如图②）。然后配置如下参数（如图③）：○ 单GPU批处理大小：设置为32。○ 截断长度：设置为2048。○ 最大生成长度：设置为1024。其他参数设置为默认即可。   💡提示配置模型与数据集后，系统将根据所需资源及其相关参数，动态预估任务运行时长及微调费用，您可在页面底部查看预估结果。 3.  可以在“任务中心->模型评估”下看到评估任务的运行状态。  4.  单击图标，进入任务基本信息查看页面。用户可查看评估任务的基本信息、日志以及评估结果。 步骤四：模型对话1.  单击页面左侧导航栏“模型对话”，进入模型对话页面。2.  在微调模型处选择目标模型名称（如图①），单击右上角“开始对话”（如图②），在弹出的对话框单击“立即对话”。  3.  在右侧配置栏的“System Prompt”处输入提示词(如图①)，在输入框中输入问题（如图②），单击发送；在对话框中查看对话详情（如图③）。   本次基于Qwen3-8B模型，采用LoRA方法在专业医疗数据集上的微调实践表明，该技术方案在保持模型通用能力的同时，显著提升了医疗问答的专业性和实用性。从技术演进角度看，微调后的模型与医疗系统深度融合将释放更大价值。这种"领域微调+系统集成"的技术路径，为AI在医疗等专业场景的落地提供了经过验证的解决方案。作为长期专注于大模型产业落地的技术架构师，我认为LLaMA-Factory Online平台为领域适配提供了高效的工程化路径，这种轻量化微调方案兼具效率与实用性，值得在更多专业场景中推广验证。PS.如何学习AI大模型？作为一名深耕大模型微调领域多年的技术架构师，我深知“纸上得来终觉浅”。在见证了上百个微调项目的成功与失败后，我深刻认识到，拥有一个清晰的学习路径和经过验证的实战资源是多么关键。为此，我特意整理了全套《大模型微调实战进阶宝典》，这份资料凝聚了我多年的实战经验，其中包含：《大模型微调实战避坑指南》：精选20+真实项目经验，解析训练发散、灾难性遗忘等高频难题《十大前沿行业微调白皮书》：汇集金融、医疗、汽车、法律、保险等众多领域大模型先锋案例《开箱即用微调数据集精选》：涵盖指令微调、对话、专业领域问答与代码生成等多个实战场景愿你能用它，快速撬动大模型在你业务中的巨大价值！

详细内容请看Word文档，里面有更详细的说明

首次完成AI作诗“花枝小索上明时，莫学麻姑小老翁”

嫄予事少年，貌古须加举。叶索欲时珠，东行戎服景。有点意思~

自然语言处理（Natural Language Processing，简称NLP）是一款基于人工智能技术，针对各类企业及开发者提供的用于文本分析及挖掘的云服务，旨在帮助用户高效的处理文本。分类文档链接备注最新动态cid:link_5　特性清单cid:link_2　API参考cid:link_3　FAQcid:link_4　华为云在线课程自然语言处理理论、应用与实验（免费）cid:link_0自然语言处理（NLP）是人工智能领域的一个重要方向，是一门融语言学、计算机科学、数学为一体的科学。本课程就NLP基本理论及应用做了介绍，包括NLP的语言模型，文本向量化，常用的NLP算法，NLP的关键技术及应用系统。AI技术应用场景--自然语言处理（付费）cid:link_1自然语言处理是人工智能的一个重要的分支，随着人工智能的快速发展，自然语言处理的应用愈加广泛。本课程作为自然语言处理的入门课程，有助于帮助大家掌握自然语言处理的基础技术理论和相关实践。华为云开发者网自然语言处理 NLP开放能力cid:link_6　

（1）流媒体应用有：媒体采集系统、媒体制作系统、点播系统、视频流推送系统.几类应用比较适合容器化部署：一是功能单一的应用，即微服务；二是无状态的应用，容器的一个最大的优点就是可以快速创建（秒级），对于无状态的应用，可以通过快速横向扩容来提升并发处理能力；三是变更频繁的应用，容器是基于镜像创建的，对于变更频繁的应用，只要能保证镜像在测试环境测试没有问题，那么在生产环境上线由于环境差异导致出问题的概率就会少的多；四是对于需要在一个站点快速部署的应用组，对于需要在一个新站点快速部署的应用组，使用容器技术能够结合容器平台自身的特性，快速创建一个新的站点。综上，媒体采集系统、媒体制作系统、点播系统、视频流推送系统都适合容器化。（2）容器化改造思路1. 由于视频视频流量不可预知性，需要具备极速弹性伸缩能力，可以利用CCE容器引擎，来实现弹性伸缩应用2.负载均衡应用改造点：选择合适的负载均衡器中小型的Web应用可以使用ngnix或HAProxy，大型网站或重要的服务可以使用LVS，目前视频流媒体选LVS作为负载均衡器！3.应用改造点：应用存在长时间执行请求   增加消息队列，通过消息队列将长任务与用户请求解耦4.应用改造点：服务有状态，进行无状态化改造，将会话数据加密后放到cookies中返回客户端，通过远程的NoSQL如Redis、Memcached存储会话信息。5.应用改造点：应用实例依赖于本地的存储来持久化数据，可使用共享文件系统如NFS，视频文件采用OBS存储。采用华为云CCE集群服务优势：支持裸金属容器服务，流媒体服务性能提升200%以上。视频流媒体对网络性能以及服务器运算能力要求苛刻。CCE支持裸金属容器服务，视频应用可基于裸金属服务部署，容器直接运行在物理机上，无任何虚拟化性能缺失，可获得和物理机同等的超优性能，视频业务性能提升。CCE支持有状态容器应用（即应用运行过程中需保存数据或状态），并利用华为云的EVS/SFS等存储能力利用高可用存储卷，解决了视频应用的容器化部署难题。可图1 裸金属容器服务视频应用放在pod里视频文件放在OBS里其他系统为有状态pod 视频流推送系统为无状态，放在无状态pod流媒体加CDN加速服务ClusterIP：集群内访问表示工作负载暴露给同一集群内其他工作负载访问的方式，可以通过“集群内部域名”访问Nodeport：在每个节点的IP上开放一个静态端口，通过静态端口对外暴露服务。节点访问 ( NodePort )会路由到ClusterIP服务，这个ClusterIP服务会自动创建。通过请求<NodeIP>:<NodePort>，可以从集群的外部访问一个NodePort服务Loadbalance：可以通过弹性负载均衡从公网访问到工作负载，与弹性IP方式相比提供了高可靠的保障，一般用于系统中需要暴露到公网的服务。高可用规划  架构图：见4.视频点播、直播分别是两个不同的域名，绑定同一个ip，华为云什么服务可以实现该功能，并简要说明步骤。

业务场景: 爬虫截取微博网上留言信息，调用华为云的情感分析，百度云情感分析（通用接口），百度云情感分析（定制化模型，自定义学习资料）。根据以下几个点进行对比。未处理的原版数据通用模型-       原版分类置信度定制模型 -  原版分类置信度     （800条学习资料样本，     85.96%准确率的学习资料）定制模型 -  原版分类置信度     （1800条学习资料样本，     65.93%准确率的学习资料）原版评论分类置信度     （华为云 仅2000条左右数据）     通用模型-       原版评论负面倾向概率定制模型  - 原版评论负面倾向概率     （800条学习资料样本，     85.96%准确率的学习资料）定制模型  - 原版评论负面倾向概率     （1800条学习资料样本，     65.93%准确率的学习资料）通用模型-       原版评论正面倾向概率使用定制模型  -      原版评论正面倾向概率     （800条学习资料样本，     85.96%准确率的学习资料）使用定制模型  -      原版评论正面倾向概率     （1800条学习资料样本，     65.93%准确率的学习资料）通用模型-  原     版评论分析正负结果值定制模型 -       原版评论分析正负结果值      （800条学习资料样本，     85.96%准确率的学习资料）定制模型 -       原版评论分析正负结果值      （1800条学习资料样本，     65.93%准确率的学习资料）原版评论正负结果值     （华为云 仅2000条左右数据）处理掉@和#后的评论数据：通用模型-       原版分类置信度定制模型 -  原版分类置信度     （800条学习资料样本，     85.96%准确率的学习资料）定制模型 -  原版分类置信度     （1800条学习资料样本，     65.93%准确率的学习资料）原版评论分类置信度     （华为云 仅2000条左右数据）     通用模型-       原版评论负面倾向概率定制模型  - 原版评论负面倾向概率     （800条学习资料样本，     85.96%准确率的学习资料）定制模型  - 原版评论负面倾向概率     （1800条学习资料样本，     65.93%准确率的学习资料）通用模型-       原版评论正面倾向概率使用定制模型  -      原版评论正面倾向概率     （800条学习资料样本，     85.96%准确率的学习资料）使用定制模型  -      原版评论正面倾向概率     （1800条学习资料样本，     65.93%准确率的学习资料）通用模型-  原     版评论分析正负结果值定制模型 -       原版评论分析正负结果值      （800条学习资料样本，     85.96%准确率的学习资料）定制模型 -       原版评论分析正负结果值      （1800条学习资料样本，     65.93%准确率的学习资料）原版评论正负结果值     （华为云 仅2000条左右数据）解决的问题: 对比了两家的情感分析之后，经过综合分析，百度云情感分析（通用模型）的准确率是最高的。目前综合来看，百度云的情感分析通用模式是自然语言分析的最好选择。定制化的百度模型实际测试不如通用模型准确（可能为学习模型数据不够准确）。挑战: 首次使用华为云情感分析，对于接口调用方面自己阅读文档不够详细，走了较多的弯路，不过经过仔细研究自行解决。由于存在QPS限制，调用的时候需要限制调用频率。由于网络原因可能存在频繁调用的情况。数据较多的情况下处理数据的时长比较久（针对试用而言）。根据不同的定制化模型。可能存在无法分析的特殊字符数据。使用服务: 自然语言处理 - 情感分析如何解决: 在不超过qps限制的情况下，试用分页形式，分段请求，在数据库中设置 判断值判断数据是否进行分析，如果重复调用会直接过滤掉已经进行情感分析的数据。对于线程进行休眠操作，防止调用请求过于频繁接口调用失败。使用日志记录失败请求信息，失败请求原因，失败请求数据。多次调用数据确保大部分数据可以产生结果，个别数据请求失败以及没有数据的忽略。使用场景: 比对市面上几家华为云的情感分析使用，根据分析结果数据进行比对。对比百度云通用模型和定制化模型的使用。对比不同的环境下分析的数据，数据差异值。方案截图:（处理掉特殊字符前的截图）（处理掉特殊字符后的截图）使用规模: 共1000条数据左右（原2000条，截取了1000条）。使用收益：  1. 对比了百度情感分析和华为云的情感分析，对比结果比较显著，在情感分析的领域发现是百度云的使用情况较好。  原因：        1. 百度云提供更多的免费试用次数，对比华为云只有5000次的试用，有50万次的免费调用次数        2. 百度提供定制化模型免费的尝试，可以使用定制化模型和通用模型对比        3. 百度云的接口提供更多的返回信息，供调用者分析参考（免费的情况下） 2. 华为云和百度云的文档上手难度都很小，通过文档都能很快速的了解接口的调用。 3. 两者的使用体验都较好，但是百度的接口在超过qps限制的情况下存在存在接口崩溃的情况，对比下华为云的接口更加稳定  4. 在两者的实际使用下会使用成本更为低的百度云接口结语第一次投稿，平时也很少在网上发表文章。个人也仅仅是最简单的接口调用轻度使用，也没用很深入的去进行挖掘，如果有好的意见或者建议欢迎留言作者：阿东