即刻App年轻人的同好社区
下载
App内打开
Elliot罗
1k关注441被关注3夸夸
一杯酒，一个朋友！
公众号✍️：离歌笑
知识星球🆓：我欠世界一个产品
置顶
Elliot罗
27天前
产品经理已死？

常有人拿生孩子十个月，养孩子十八年，类比运营比产品重要？

请问产品基础特性做出来了，后面不迭代升级？（可以做加减法，也可以换方案）

时代变了，新技术出现了，所有产品是不是要重新做一遍？（比如手动挡到自动挡到辅助驾驶到无人驾驶）

谁来主动推动上面这些事儿，就是产品经理，虽然只是个title罢了，更重要的是他愿意让正确的事相继发生…

如同电影🎬里斯本丸沉没的导演自费历时七年拍出来一样…
11
Elliot罗
10:50
问题在于ai模型彼此之间能力也有差异🤔

杨昌: 春节期间这波AI热潮，注定会从餐桌前的谈资，延续到办公桌上的行动计划。 可以预见，开工之后，会有越来越多的企业，抱着"有枣没枣打一杆"的心态，开始规划AI项目。 就像当年的互联网转型一样，AI似乎也开始成为了企业升级的必答题。 一、两块硬骨头 不过，对于众多蠢蠢欲动的AI团队来说，要想在年终考核时达成KPI，有两块硬骨头必须啃下来: 1、选择合适的技术路线。 此时的AI发展态势，恰如彼时的田径史: 四分钟跑完一英里，曾被认为是人类的生理极限。直到罗杰·班尼斯特以3分59.4秒打破这个纪录。一旦心理障碍被打破，随之而来的就是一连串的突破。这个纪录仅仅维持了46天，就被约翰·兰迪刷新至3分57.9秒。 今天的AI领域，正经历着类似的历史时刻。DeepSeek的突破，就像是AI界的“班尼斯特时刻”，打破了发展的心理藩篱。加上开源浪潮的推动，AI技术迭代正在加速。 在这样的关键节点上，选择技术路线不仅要考虑当下的技术成熟度，更要预判未来的发展方向。押对了，就能在技术浪潮中占得先机；押错了，可能需要付出数倍的代价重新开始。 2、其次是从成本中心转变为利润中心。 不然，等到下一轮"降本增效"来临时，AI团队往往是第一批被"优化"的对象。 前两年，很多AI团队之所以难以成为利润中心，症结往往不在AI商业化本身，而在于对技术与业务融合的理解过于肤浅。不少团队陷入了技术中心主义的误区，以为掌握了算法就等于掌握了价值创造的钥匙。 这种情况下，AI团队往往成为企业内的技术孤岛，整天研究最新的算法和模型，却很少了解业务痛点。双方就像说着不同语言的两个群体，AI团队滔滔不绝地讲着技术术语，而业务人员只关心问题能否解决、成本和风险。 这种割裂，最终会陷入恶性循环。AI团队为证明价值不断追求技术指标提升，却始终无法解决实际业务问题。业务部门见不到效果，就更不愿投入资源支持，进一步加剧了双方的隔阂…… 二、两类参考答案 针对技术路线的问题，我春节期间看到最好的参考答案是perplexity。 1、 我原本以为，perplexity 很快会被联网版的deepseek r1 取代。 因为deepseek 足够强的推理加上实时的联网，就把提示词的门槛给打了下来。 每个人只要像聊天一样输入自己的问题，就能收获其他AI改半天提示词也达不到的效果。 于是我就想，免费的deepseek 就能搜成这样了，又要付费的perplexity干嘛呢？ 2、 但实际情况却是，perplexity 不仅很快就引入了deepseek r1，而且成为了所有引入deepseek 的产品中速度最快和效果最惊艳的。 所以，在 deepseek 没有限制联网之前，我就重新换回perplexity了。 确实没想到，perplexity 的产品力恐怖如斯。无论模型层有多大进步，都能快速转化成自己的能力，让搜索效果更好，让用户体验更佳。 回到技术路线问题上，个人认为perplexity这种「不会被模型进步干掉，反而是模型越强我越强」架构，反倒更值得追求。 3、 在企业领域，在“模型越强我越强”方面做得最好的，当属美国AI ToB当红炸子鸡Palantir 家的Ontology 。 什么是Ontology？ 2021年的Demo Day上，Palantir曾宣称，他们能在几个小时内，自动整合完公司各部门数据，形成整个公司的“数字分身”（digital twin）。而这，就是Ontology。 时间来到2023 年，Palantir与时俱进推出的AIP，更是直接将先进的AI模型（如ChatGPT）与Ontology框架结合，进一步简化操作，增强客户基于全面、实时洞察做决策的能力。 当年第四季度，Palantir 就在报告里说，美国商业收入同比增长70%，这主要得益于AIP的成功推出和市场需求…… 4、 虽然，目前还没有消息说Palantir 要AIP里引入deepseek，但我敢确信，只要跟Ontology框架结合，就一定会有超预期的效果。 理由无他，只是因为Ontology 跟deepseek 等头部AI 太配了。 如果说互联网产品的工作机制是"预设路径下的功能调用”，那么生成式AI产品则是“上下文感知下的动态生成”。 AI负责感知和生成，Ontology则主攻“上下文”。 这个“上下文”有多重要呢？就像在现实生活中，我们绝不允许医生在不看任何病历资料的情况下就匆忙开药，就算是华佗在世也不行。 想要AI 生成准确的结果，就要提供详尽如“检查报告、过往病史和家族病史”的上下文。否则，再强的AI 在手，也只能空叹“庸医误人”。 5、 所以，Ontology 是如何解决「大模型们缺乏有效上下文」问题的呢？ 太技术的内容，先不做展开。我就拿自己比较熟悉的影视行业，举个例子吧： 【before】 在没有 Ontology 之前，创作素材和各方意见散落各处，形成 “信息孤岛”，导致沟通成本极高。 据一位非常资深的行业专家估计，行业里70%以上时间，都耗费在信息沟通上。 很多时候，由于缺失太多必要的背景信息，最强的AI 也无法提供足够有针对性的帮助。 【after】 而引入Ontology后，可整合项目各种数据，动态链接关联，形成 “智能故事大纲”。 这时，AI就像是一位对项目了如指掌的老编剧，无需反复解释背景，一句话便可切中要害。 因为，在它面前，角色性格、人物关系、剧情走向等关键信息都烂熟于心，给“一个眼神”就能指哪儿打哪儿。 更重要的是,这份"智能故事大纲"就像一张实时共享的创作地图。 过去，大家找剧本最新版本可能要翻邮件，理解人物关系可能要翻会议记录，琢磨角色性格可能要翻讨论记录，很容易陷入信息的迷宫里兜圈子。 现如今，有了这张统一的地图，所有参与方都能一目了然地看到项目全貌，把更多原先用在找资料、对进度上的时间，投入到打磨内容上。 6、 可见，Ontology的价值，不止是“模型越强我越强”的保障，更是连接AI与业务的桥梁。 有了这座桥，AI才能真正读懂企业的业务场景，访问到关键信息，进而提供真正有价值的输出。 当然，要搭建这个桥梁，不仅是技术工程，更是组织工程。比如，AI团队必须从独立的技术孤岛，进化成连接各业务部门的纽带。 只有让AI专家真正理解业务痛点，让业务人员切实参与AI应用设计，才能确保AI项目既有技术可行性，又有业务价值。 ——— 最后，期待多多交流，一起啃下这两块硬骨头。

00
Elliot罗
2天前
帮大家总结观影顺序

哪吒＞封神 2＞唐探 1900＞蛟龙＞射雕
00
Elliot罗
2天前
00
Elliot罗
3天前
网易云音乐的歌单push都有了

老蒋不一定靠谱: 这速度是不是有些变态了

00
Elliot罗
3天前
61
Elliot罗
3天前
Elliot罗
3天前
Elliot罗
3天前
“如果你了解那段历史，你会发现这部电影更优秀。”

—唐探 1900
00
Elliot罗
3天前
00
Elliot罗
3天前