V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
locoz
V2EX  ›  程序员

基于昨天那个 MacBook 跟 NAS 对比计算 sha256 速度的主题,聊聊“为什么人类社区要禁止使用 AI 回复”,以及“为什么不同的人使用同样的模型问问题,得到的回答质量差距很大”

  •  
  •   locoz · 336 天前 · 1900 次点击
    这是一个创建于 336 天前的主题,其中的信息可能已经有所发展或是发生改变。
    原主题:为什么我 M2 Max 的 MacBook Pro 比我用 R7 5700U 的 NAS 使用 7z 计算同一批文件 sha256 整整慢 65%? https://www.v2ex.com/t/1000198

    原主题中,认为 @chonger #1 #2 引用 AI 回答的内容没有问题,甚至觉得这样的回答是有价值、能对楼主起到帮助作用的人看起来不在少数,从点赞数量和相关回复就能看出。但是,你们(指认为这样的回答没有问题的人)有没有好好想过,这样的一个“不懂程序”(@chonger 在回复的开头自己说的)且没有在同样环境进行测试的人,只是直接引用 AI 回复并加了个“试了下可以正常调用多线程”,没有对 AI 回复进行任何实质性的补充或纠正,这样拿出来的回答对原主题楼主(后文简称“他”)而言到底能起到什么帮助?

    要搞清楚一个事情,他的核心问题是“为什么相比之下 MacBook 比 NAS 慢”,而不是“怎么提高计算速度”。后者是个随便就能得到解决方案、他自己动动手搜一下或者问 AI 就能解决的问题,前者才是有门槛、有深度的问题。

    从他的描述中可以得知,他在两个设备上都是用的同样的工具做的处理,并且自己也有意识地检查了 CPU 占用率的情况,如果是 NAS 上的工具版本是默认多线程计算才导致速度更快的,那他早就自己发现了,很可能根本不会问出这个问题。

    这个问题的关键之处在于,同样是单核计算的情况下,在他的认知中是“各方面都比 Mac 性能差”的 NAS ,在这个任务中的速度却比 Mac 更快,这对于会审题且了解相关知识的人类而言,很容易就能联想到例如大小核调度问题、软件在不同 CPU 架构的优化程度差异、CPU 指令集的优化差异等可能性,但当下的 AI 并不行。

    而当下的 AI 不行的本质原因,是因为当下这些 AI 说到底只是在根据前文推导后文而已。他正文部分的描述中提到了单线程运行的问题,这就直接影响了模型的输出结果。再加上模型对于两个设备的 CPU 核心、架构、指令集等这种较为专业的信息的“认知”并没有那么“深刻”,没有“联想”出相关信息,最终就导致了给出的回答主要为 [如何使用多线程提速] ,但核心的“为什么 MacBook 比 NAS 慢”基本就可以说是一笔带过、文不对题。

    当然,也并不是说缺乏相关知识的人就不可能让当下的 AI 稳定输出超出个人能力范围的回答了,像通过让 AI 反问补充细节描述后再提问就是一个很好的处理方式,在那些让 AI 写成套的代码、书籍等需要内容系统化、自动详细和纠正错误的项目中,这种处理方式很常见(只不过提问的和补充细节的都换成了 AI 而已),也都能在一定程度上得到很好的效果。但这种处理方式毕竟需要通过多轮的反问来补充细节,补充细节的过程实际上也就是提问者在了解相关知识的过程,如果经历完了这个过程,且问题还没有超出当下 AI 的能力极限,那自然也没必要在人类社区内提问,自己根据关键点引导 AI 回答就行了。

    ---

    所以说白了,由于描述会影响模型的输出结果,输入低质量的描述自然会导致模型压根就不会往更优的方向进行回答,得到的回答质量也自然就远低于具备相关知识的人类的水平。而自身就缺乏相关知识的提问者又无法直接提出一个更准确、引导性更强、能让模型输出更高质量回答的描述,再叠加上一个“不懂程序”的人直接复制粘贴去让 AI 回答,这要是还能得出什么优质内容,那 AI 早就普及了。

    为什么复制粘贴 AI 的回复内容会令人厌恶,核心原因之一就是并不是所有人都 会/有能力 去好好优化描述,让 AI 给出一个高质量、准确、描述详细的回答后再转发给提问者,会/有能力 在 AI 回复的基础上进行更有深度的补充或纠错的就更少了。

    如果一个能给出高质量回答的人,仅仅是借助 AI 细化回答,让提问者能更好地理解,同时给自己省去一些打字的时间,那当然很好。但事实上从被封号的情况就能看出:
    绝大多数被封号的人都是在复制粘贴原始描述,或仅对原始描述进行了个简单概括就去问 AI ,且在这部分人中又有大多数人是直接复制粘贴的回答,没有进行实质性的自己的补充或纠正,普遍存在回答质量并不算高,甚至部分还存在错误的情况。如果再叠加上原主题 @chonger 这样自己就缺乏相关知识的 debuff ,最终得到的回答质量可想而知。

    这种贴 AI 回复内容的行为之所以会被人类社区禁止,说白了就是是个人都能去复制粘贴让 AI 回答,且绝大多数情况下最终回复的质量完全取决于原提问者的能力,但还是前面说过的,原提问者如果自身有能力,也没必要在社区里提问了。如果不禁止这种行为,那么社区内必然会出现大量低质量内容,直接导致对社区氛围、整体内容质量、活跃用户类型和数量等各方面都造成负面影响,这在社区运营者的角度上显然是不希望发生的。

    虽然我在用户的角度也会觉得,在规则上完全禁止、看到了就直接封号这样的处理并不是很好,但换位思考一下,V2EX 毕竟是一个个人网站,也不是重投入、纯商业化运营的类型,运营、管理人员就那么几个,还都只是日常兼顾着处理社区事务,哪来的那么多时间天天处理烂事?相互理解一下,没那么难。原主题中很多没有运营过社区,或者说没有直接面向 C 端用户服务过的人,我只能说是对精细化管理的成本没有一点概念,过于乐观,甚至其中有些人可以说是为了喷而喷...被封号一点都不带冤枉的。
    6 条回复    2023-12-16 13:58:34 +08:00
    yyzh
        1
    yyzh  
       336 天前 via Android
    没啥好说的.用户协议里已经写明了.
    /about
    yyzh
        2
    yyzh  
       336 天前 via Android
    看起来不会转换为链接
    www.v2ex.com/about
    ysc3839
        3
    ysc3839  
       336 天前 via Android
    说个题外话,为什么计算 hash 时一般不多线程计算:
    一是绝大多数 hash 算法都是“循环式”的,取一定长度的数据计算出一个 hash 值,然后在这个 hash 值的基础上再取一定长度的数据继续计算。因为后一步操作依赖前一步的结果,所以难以多线程并行计算。
    二是主流性能的 CPU 计算绝大多数 hash 的速度都很快,远比硬盘读取速度快,多线程同时计算多个文件的 hash 并不能解决硬盘瓶颈,还会导致硬盘从顺序读取变成随机读取,进一步降低性能。
    ntedshen
        4
    ntedshen  
       336 天前   ❤️ 1
    。。。当一个坛子的管理是这样的
    每天都会有一大堆的问题,你要盯着处理一天就别想干别的了,可能一天不干别的都来不及处理。。。
    下班开机,浏览器打开,看到有人圈,看一眼,确实不正常,那直接干掉就是
    讨论的余地?宽容的必要?每个人次次都审这么一遍,一百个管理都不够。。。
    嫌恐怖的自己开个坛子试试就是,要么成摆子要么成祖安。。。
    然后祖安的会一直祖安到祖安不动最后还是变成摆子。。。

    话说本地哈希我现在都在用 xxhash 做了。。。
    之前自己写 nas 前端,想了很久感觉还是没有必要使用安全哈希,毕竟只是做个校验。。。
    Leonard
        5
    Leonard  
       336 天前 via iPhone
    @yyzh 给站长不同意见点赞的会被降权,不知道这个是不是属于用户协议里的内容呢。
    另外我也不知道我在这提出这个质疑会不会又有惩罚呢。
    DIMOJANG
        6
    DIMOJANG  
       335 天前
    我也支持禁止在论坛直接引用 AI 生成的回复,不过在我看来和 AI 的回复质量没什么关系。

    其中一个是因为,现在想要获取 AI 的回复实在是太简单了(特别是对于 V2 的大部分用户来说,和搜索引擎已经没有区别了吧);再一个就是,都来论坛发帖了,肯定是希望大家一起来交流问题,而不是看到 AI 的“指导性意见”。

    PS:现在 AI 生成东西的速度这么快,如果真的放任 AI 的话那论坛迟早会出现 AI 生成的内容大于用户生成内容的局面……是好是坏我还不好评价,但是心里还是不希望发展成那样的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2575 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 20ms · UTC 01:37 · PVG 09:37 · LAX 17:37 · JFK 20:37
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.