1. 大模型的本质：有损压缩和无损压缩 2. 垂直大模型 Vs. 通用大模型 3. Rag(知识库) Vs. WorkFlow（工作流） 4. 准确率&幻觉&测试集的建立 5. 超过一周不能落地的场景要慎重 6. 从工程化的角度，考虑与IM对接最后一公里 7. 尽量先从个人和部门场景出发，后做跨部门的业务流程
在传统大模型训练中，重点通常是掌握语言的概率分布，让输出听起来“像那么回事”，类似一个擅长表达的文科生。这种模式擅长文字组织，却在逻辑推理和正确性判断上存在明显短板。
DeepSeek 则选择了一条不同的路径：它通过大量数学题和逻辑题的强化学习，强化对正确答案的判断能力，逐渐从“文科生”变成了更像“理科生”的角色。面对问题时，它不再仅仅追求语言流畅，而是关注推理过程和结果的准确性。这种对自身输出的严格验证，是它在复杂任务中表现突出的关键。
本质上，这种转变也印证了 AI 大模型的底层逻辑——信息的压缩。传统语言大模型更多是一种有损压缩，像总结周报、聊天翻译，重在表达流畅但细节难以复原。而 DeepSeek 的强化学习则更接近无损压缩，像物理公式、数学定理，力求用最少的信息，精准还原复杂规律。
对AI大模型本质的正确理解，可以帮助我们在落地过程中避开许多常见的误区。一个最典型的错误，就是把大模型当作一个超强版的搜索引擎或者数据库，希望它能够完整记忆并精准还原所有细节信息。然而，大模型的本质并不是存储和检索，而是通过概率分布进行信息压缩和重建。它擅长根据已有的语言或知识模式，推测出“最可能合理”的答案，但并不保证每次生成的内容都与事实一一对应。
如果对这一点认识不足，往往会陷入两个常见陷阱：
一是试图让大模型“死记硬背”大量静态信息，比如客户名单、产品库存、历史政策细则，结果发现模型在细节还原上不断出错；
二是希望通过简单的提示工程（Prompt）让模型稳定输出固定答案，但却忽略了模型内部存在的生成随机性和上下文漂移。
真正有效的方法，是把大模型理解为一种动态推理引擎，而不是信息存储器。需要精准、实时的信息时，应通过知识库检索（RAG）、数据库API调用、或者外部系统集成来提供支撑，由大模型负责语言理解、推理补全和交互表达。
简而言之：记忆靠系统，推理靠大模型。只有明确划分角色，才能让大模型在真正擅长的领域发挥最大价值，避免陷入错误的使用模式和不必要的工程浪费。
自 OpenAI 发布 GPT 以来，大模型的发展逐渐分化为两条路径：一是以 Meta、Google 等为代表，持续推进通用大模型的演进；另一则是像 Bloomberg 这样，面向特定行业推出金融等领域的垂直大模型。
很多企业意识到，在通用领域与科技巨头正面竞争胜算渺茫，便寄希望于凭借自身在垂直行业的知识壁垒、专有数据和实践经验，打造出属于自己的行业大模型。因此，从 2023 年起，出现了大量行业巨头试图构建垂类大模型的浪潮。
以“信息差”为例：谁是潜在客户、联系方式是什么、近期需求变化如何，这类信息每天、每月、每年都在更新，规模几乎是无穷的。大模型无法依靠记忆所有这些碎片信息来实现质的飞跃；它真正需要掌握的，是在特定场景下应该如何决策和行动——而这些场景，又随着政策导向和环境变化不断刷新。比如，中小企业融资政策的变化，就能迅速推翻原有的业务逻辑。
即便是人类员工，当行业政策或公司战略发生变化时，也需要反复培训、重新适应。大模型真正需要具备的，不是囤积过往的信息碎片，而是根据外部环境变化，灵活拆解新的业务流程与标准操作（SOP）。这一能力，本质上依然属于通用推理和抽象理解的范畴，通用大模型完全可以胜任。
总结来说：信息是无限且不断变化的，而知识是有限且可提炼的。在垂直行业押注于“信息差壁垒”，并试图用微调打败通用模型，注定是一条艰难且代价高昂的道路。
在大模型的 RAG（检索增强生成）应用中，准确率的评估一直是一个复杂且难以标准化的问题。虽然从理论上来看，RAG 的表现可以拆分为检索和生成两个部分，各自衡量，但在实际工程落地中，很少能有一套简单通用的方法准确描述“好”与“不好”。
检索模块通常关注命中率（Hit Rate）、平均倒数排名（MRR）、平均准确率（MAP）等基础指标，用来评估是否能从庞杂的信息中正确召回有用的内容。有些团队还会进一步测试检索系统在混杂噪声数据时的鲁棒性，即检索出的文档中掺杂无关内容时，系统能否依然提取有效信息。但这些检索层面的指标本质上只是基础，能召回不代表能用好。
生成模块的评估则更为微妙。除了最基本的答案准确性，还需要关注生成内容是否忠实于检索到的文档，避免出现“胡编乱造”（幻觉）。在某些特定领域，如金融，还要进一步校验数值的准确性，比如生成的金额、比例、日期是否精确对应原文。这种评估往往涉及复杂的细粒度比对，有时还需要人工逐条核查。
场景扩展到金融、医疗、企业级文档处理，甚至多模态（图像、表格混合）场景时，传统的检索与生成指标体系往往力不从心，需要引入更多专门化的评估维度，比如数值一致性、表格信息还原等，这也让整个评估工程的复杂度进一步上升。虽然这些领域的技术发展速度很快，新的方法和工具也在不断涌现，但整体上依然面临数据孤岛、知识封闭、标准不统一的问题，真正高质量的评估体系仍然稀缺。
目前来看，要推动这些垂直行业的RAG系统进一步成熟，仍然依赖于更大规模的开源数据、开源评测基准和行业知识的共享。如果未来垂直行业的专业知识能够大规模开源，很多原本封闭在企业内部、依赖私有数据构建的小型RAG系统，可能就会逐渐失去存在的必要。因为通用大模型加上开放知识，已经能覆盖大部分场景需求。
到那时，企业内部构建RAG的价值，可能更多转向对实时性数据、个性化业务流程和私有决策逻辑的补充，而不再是单纯为了补足知识盲区，而这些更多的是WorkFlow（工作流）的场景。换句话说，如果未来行业知识足够开放，共识标准足够健全，RAG的重心就会从“填补认知鸿沟”，转向“快速适应变化”和“结合企业独特性”上。
目前，虽然RAG领域的技术进步非常迅速，但在落地速度、实施成本和实际效果上，整体仍不及基于WorkFlow的应用场景。
为了减少大模型幻觉对应用落地的影响，在规划 AI 场景之前，首先应建立一套标准化的测试数据集。以智能会议室预订为例，这类场景通常涉及时间、地点、人物三个关键维度。如果每个维度的识别准确率只有 70%，那么综合在一起后，整体成功率可能还不到 35%，这样的水平显然无法支撑大规模应用推广。哪怕场景中有一些看似炫酷的功能，比如“一键预订海景会议室”，也很难掩盖基础体验的缺陷。
类似这样的场景构思非常容易，实现一个初版也可能只需一天时间。但如果基座大模型本身能力不足，即使流程能够跑通，实际体验也会因准确率低下而显得可有可无。实际应用中，通常需要将综合准确率提升到至少 95%，才能达到可用的标准。
那么，这个 95% 的指标如何理解？可以类比于让一个刚入职的实习生来完成相同任务——他们的准确率大致在 95% 左右，偶尔完成不好需要你来干预。而对于 AI 来说，即便还不能做到百分百准确，但在执行效率上具有压倒性优势：比如人类手动完成一次个性化的会议室预订可能需要 1 分钟，而 AI 仅需5 秒。即使在第一次出错的情况下，通过人工介入或 AI 重新执行一次，整体时间成本依然远低于人工操作。
因此，在评估一个 AI 应用是否值得投入和推广时，准确率和效率两者必须结合考量。不是追求绝对零错误，而是要在“高准确率 + 极高效率”的综合平衡中，真正带来体验和成本的双赢。
通用大模型的能力提升速度越来越快，尤其是 2024 年 6 月 Claude 3.5 发布后，更是为业界带来了连连不断的惊喜。同时，围绕大模型的 API、RPA、MCP 等生态也日益成熟，为各种 AI 落地场景打下了坚实的基础。
值得注意的是，在 AI 时代，优秀的开源项目比以往更容易获得爆发性的关注。例如，模拟 Manus 概念的开源项目 OpenManus，仅用几天时间就获得了超过 2 万个 GitHub Star。这样的速度在传统软件时代几乎难以想象。更重要的是，AI 生成代码的普及极大加速了开源项目的迭代与演进，使得组件更新的周期大幅缩短，项目获得行业共识的时间也越来越快。
Citrix 的 HTML 云桌面方案，通常指的是通过Citrix Workspace或Citrix Virtual Apps and Desktops提供的一种无需客户端安装，直接通过浏览器访问虚拟桌面的技术。这个方案背后的关键组件是Citrix Workspace Web Access（也叫 HTML5 Receiver）。
简单来说，它的特点是：
纯浏览器访问：用户无需下载和安装 Citrix Receiver 客户端，只需要一个支持 HTML5 的浏览器（如 Chrome、Edge、Safari）就能远程登录虚拟桌面或应用。
跨平台兼容：可以在 Windows、Mac、Linux，甚至是 iPad、Android 平板等各种设备上使用，只要有浏览器就行。
安全性好：数据不会直接下载到本地终端，所有操作在服务器端完成，配合 Citrix 本身的安全加密传输（ICA 协议），非常适合对数据安全要求高的金融、医疗等场景。
体验略有差距：虽然浏览器访问带来了极大的便利，但与本地安装客户端相比，某些高性能应用（比如高清视频播放、3D建模、重负载办公软件）的流畅度可能会稍逊一筹。
适合轻量办公场景：比如日常的文档处理、表格编辑、CRM系统操作、内部管理后台等，体验非常接近本地使用。
Citrix 的 HTML 云桌面方案本质上是把虚拟化桌面/应用交付变得更轻量、更易访问，但在高性能场景下仍推荐传统客户端方式来保证体验。其中最核心、也是最具挑战性的技术难点，是如何将用户操作的延迟压缩到 100ms 以下，甚至更低，接近人类感知的下限。只有做到这一点，才能让基于浏览器的云桌面体验接近甚至媲美本地桌面。
我们曾评估过一些开源项目，例如 Puter，它在界面上虽然炫酷，但在实际执行效率、响应速度和系统改造灵活性方面，仍存在较大不足。经过 1-2 周的集中测试与讨论后，我们得出的结论是：以当时的技术条件，想要基于现有开源基座打磨出一个满足金融级应用要求的系统，工程量巨大且周期不可控，因此项目需要暂时搁置，等待更成熟的商业软件或下一代更高效的开源方案出现。
在 AI 时代，应用形态正在发生根本性的变化。与过去不同，如今的应用应该“躲在聊天之后”。为每个智能化系统单独开发一个网页，已不再那么必要——网页主要是给人看的，而 AI 并不需要复杂的界面。对 AI 来说，只要有 MCP 协议、Agent-to-Agent 协议和完善的审计日志，就足够完成交互与协作。前端页面更多的意义，是让人类用户感到安心与舒适，而不是服务于 AI 本身。
在系统架构整合上，正在出现两种截然不同的模式："In-APP Chat" 和 "In-Chat APP"。一个以系统和流程为中心，聊天只是其中的一环；另一个则以人为中心，让所有功能围绕对话展开。这不仅是技术选型的区别，更是应用哲学的转变。
2025年4月，微信正式上线了“腾讯元宝”AI好友功能。用户可通过搜索或扫码将其添加为联系人，直接在微信中实现文字、语音交互及文件解析。该功能基于腾讯混元与 DeepSeek 双模引擎，深度融入微信生态，支持对公众号文章、图片、网页（100M以内内容）的秒级解读，并引入了“对方正在输入”等拟人化交互体验。元宝的核心突破在于打破了应用切换的壁垒：用户无需跳转到其他平台，即可在聊天界面快速解析复杂内容，如学术论文、商业报告，并通过自然语言追问实现延伸式对话。
这一创新背后，是腾讯加速推进 AI Agent 战略的关键动作。通过将大模型能力嵌入国民级社交场景，微信正在从单一的社交工具，进化为智能服务中枢。日均 13 亿用户的高频触达，使元宝成为普及 AI 助手的重要入口：无论是处理工作（网页总结、文档解析）、支持学习（论文分析、知识问答）、还是辅助生活（旅游攻略、智能推荐），甚至提供轻量化的情感陪伴，AI 都能随时响应。
元宝的上线标志着两个重要趋势：一是AI技术普惠化，极大降低了智能服务的使用门槛，连老年用户也能零学习成本体验 AI；二是微信生态重构，推动微信从信息传递平台，向“服务+决策中枢”升级，为未来智能客服、个性化推荐乃至全栈式 AI Agent 商业化应用打下基础。元宝的出现意味着 AI 正在从单纯的工具角色，向“数字人格化伙伴”演进，预示着人机交互范式的深刻变革。
因此，AIGC 应用落地，最适合从赋能个人和部门的小场景开始。选择那些可以由个人或部门负责人自主决策的场景，即便 AI 初期准确率并不完美，只要能节省时间、提升效率，就容易在实际使用中获得支持和认可。
此前曾提出过一种企业应用架构思路："敏（SaaS）+ 变（开源低代码）+ 稳（ERP与核心系统）"。如今，AI 技术的进步，已经让大模型可以在很大程度上替代传统低代码开发层，满足各部门灵活多变的业务需求，提升敏捷响应能力。
AIGC的落地，本质上是一场技术演进与企业工程化能力同步成长的博弈。它不仅需要对大模型本身的理解，更需要对业务场景、组织流程和系统工程的深刻把握。从个人到部门，从小场景验证到系统性渗透，每一步都要求我们在“理想与现实”之间找到平衡。
在这场变革中，速度很重要，但方向更重要。企业既要警惕技术泡沫下的盲目投入，也要敢于在小步快跑中不断试错迭代；既要看到AI在单点任务上的惊人效率提升，也要认识到在跨部门协作、复杂决策中，AI依然无法替代人类共识与组织磨合。
未来的竞争，不仅是比拼谁拥有更强的模型，更是比拼谁能更早建立起一套可度量、可迭代、可扩展的AIGC应用体系。把复杂的问题拆小，从局部突破，把握住每一次微小但真实的落地机会，才是穿越技术周期、真正让AI为企业创造长期价值的关键。
AIGC落地实践不是一场短跑，而是一场需要耐心、判断力与工程能力的长期马拉松。
