My work

Work & programming related archives.


周末去看了一下视源股份的这个领效智会大模型,初步收集了一下情况,日后若有时间再来具体了解一下。 一、官网:https://www.maxhub.com/max_ai/ 二、赋了什么能? 跟所有人一样,希望可以将智能覆盖到视频会议的会前、会中、会后全流程,没看出来有什么新意。 三、对比分析 技术维度 1.功能 单纯从MaxHub的介绍来看,简单对比一下,咱们缺失了计划了5年、但一直没实施的智能运维关联功能,但是多IoT控制,但这是产品定位不同所致。 从网上可以搜到的领效智会大模型的相关介绍里,看不出来其后端的具体情况,但是我们在ASR之后做了许多的“后处理”工作,包括:会议摘要、会议总结、方言、会议关键字、纠错、标点、语气词过滤等等,并且都是独立于ASR引擎的,无论是用讯飞的引擎、阿里的引擎、思必驰的引擎,还是其他的,都适用。但是在MaxHub的这个领效智会大模型的介绍里看不出来他们的任何情况。 2.指标 说再多的功能,没有实际的体验都白扯。MaxHub宣称可以试用,但是上去看了一下,我不具备资格,XD试用(失败):本次试用活动适用于已购MAXHUB 会议平板用户【搭载Windows 模块的五、六代经典Pro、视讯系列、科技系列、未来款】请确认是否为以上用户 四、结语 由于公开的信息相当有限,并且无法获得内测资格,因此所有信息仅停留在表面。看看后面有没有机会来实际体验一下,重点的重点是:这,到底是一个大模型?还是一个ASR(附加一些其他的零零碎碎的智能功能)?这关乎路线。

简单了解视源股份领效智会大模型


文章来源:证券时报网 原文:https://finance.eastmoney.com/a/202310232878490116.html 10月23日,视源股份(002841)旗下品牌MAXHUB首发领效智会大模型内测版。据了解,该模型将率先搭载在会议平板、智能办公本等多个产品中,提供语音操控、发言实时转录、会议纪要智能提炼、待办自动生成等功能,贯穿会前、会中、会后全流程。首批用户可以前往MAXHUB公众号或官网申请免费试用,试用周期为开通之日起至2023年12月31日。   作为一款专注于会议场景的AI,MAXHUB在会议场景的经验积累,以及母公司视源股份在AI算法研究方面的技术沉淀,均奠定了领效智会大模型发展的基础。   2017年,MAXHUB国内首创会议平板新品类,定义书写、展示、协同三大功能,此后更是不断推陈出新,于今年5月发布三大空间数字化解决方案,将高效覆盖到组织的每一个角落。至今,MAXHUB的产品已覆盖50多万间会议室和超80%中国500强企业。   MAXHUB基于对会议真实痛点与用户真实需求的深度理解,以及在制造、新零售、金融、医疗等千行百业所积累的丰富的实践经验,为领效智会大模型在通用性和定制化的功能设计上,提供了极具价值的参考。MAXHUB领效智会大模型内测版充分融合多年来在会议场景的洞察和分析,打造可落地、懂会议的AI应用。   早在2014年,MAXHUB母公司视源股份便成立了专注于AI算法研究的团队。近十年的积累,也为大模型在算法能力的持续优化上提供技术基石。据悉,MAXHUB领效智会大模型内测版历经多月时间训练,以软硬件结合的方式,将AI赋能于会议全流程,为用户带来会前轻松准备、会中多人高效执行、会后智能回溯等全流程会议体验。   任何协作工具诞生的本质,都是为用户带来更高的工作效率和更好的使用感受。MAXHUB推出会议大模型的初心同样如此,通过将旗下产品与该大模型的深度结合,打造逻辑、生成和记忆等能力,为用户带来更加人性化和智能化的高效会议体验,提高会议决策效率以及组织生产力。目前,MAXHUB领效智会大模型内测版的功能还在持续完善,值得期待的是,MAXHUB未来将会议模式推向AI时代,通过Prompt开拓人机交互、各种协同想象成为现实的新时代。

视源股份:旗下MAXHUB品牌首发会议大模型内测版 探索智慧会议新未来


来源:https://www.toutiao.com/article/7275667716328161846/ 作者:刘锋 2022年11月份以来,以ChatGPT为代表的大模型成为世界数字科技领域的新热点。在ChatGPT上线的2个月内,其月活用户已经突破1亿,在不到一年时间里全球的大模型数量已经超过百个,从全球已经发布的大模型分布来看,中美两国数量合计占全球总数的超 80%,据不完全统计,到2023年7月中国 10 亿参数规模以上的大模型已发布 79 个。 8月31日,国内首批八家大模型通过《生成式人工智能服务管理暂行办法》备案,包括百度、智谱、百川、字节、商汤、中科院(紫东太初)、MiniMax、上海人工智能实验室等8个企业/机构的大模型可正式上线面向公众提供服务。其中当天开放的文心一言等大模型。据百度官方平台数据显示,24小时内文心一言回答网友超3342万个问题。 一般而言,大模型(Large Language Models)指的是包含超大规模参数的神经网络模型。大模型通常能够学习到更细微的模式和规律,具有更强的泛化能力和表达能力。大模型代表了AI和深度学习在自然语言处理领域的最新进展。目前在机器翻译、语言理解、聊天机器人、图像识别,图像视频生成、语音识别、语音合成,推荐系统等等领域都获得了革命性的进步。 微软公司创始人比尔·盖茨公开表示,自1980年首次看到图形用户界面以来,以GPT为代表的大模型模型是他所见过的最具革命性的技术进步。对于大模型未来的产业发展趋势和面临的挑战究竟如何,我们将从三个方面进行探讨。 一.人类种群知识库从外化、索引化到智能化的三部曲 我们在《崛起的超级智能:互联网大脑如何影响科技未来》一书中提出,生物的竞争本质上是种群知识库的的竞争。在过去的几亿年里,恐龙因为灭绝导致种群知识库消失为0,鲨鱼一直保持在海洋中游荡,种群知识库没有发生大的变化,熊猫因为趋于灭绝从而种群知识库不断萎缩。 只有人类在近200万年里,在知识和智慧上不断扩展和加速,在最近数百年里随着蒸汽机、工业革命、核能的出现。人类种群知识库出现了巨大的增长。特别是互联网的诞生后,第一次将人类的种群知识库外化成一个基于网络的庞大知识库,通过万维网的发明进一步促使人类种群知识库急剧扩容。表现在科技领域就是21世纪大量新科技新概念不断涌现。 面对海量的互联网公共知识,如何索引就成了人类必须解决的重要课题,因此到20世纪90年代,搜索引擎出现了蓬勃发展,其中优秀和典型的代表分别是谷歌和百度。它们成长背后的推动力也是人类种群知识库发展的必然要求。 在互联网知识库被索引之后,如何智能化也就成为了一个重要议题。在过去的近30年里,以谷歌、百度为代表的搜索引擎公司加大了将互联网知识库进行智能化的步伐,人工智能的兴起也于此有密切的关系。在国内过去的近10年时间里,百度通过百度大脑、小度、自动驾驶等产品不断推动人工智能的产业化应用。 2022年OpenAI的Chatgpt成功引发了大模型的兴起,标志着互联网这个外化的人类种群知识库完成了从索引化到智能化的转变。但不能忘记的是,OpenAI Chatgpt的成功离不开谷歌提出的Transformer注意力机制模型,也离不开微软通过Bing搜索引擎提供的海量数据和巨大资金支持。在中国,2019年百度推出了文心大模型,并在2023年在国内率先推出了大模型消费级产品-文心一言,并与其搜索引擎做了深度结合,另一家中国搜索引擎公司奇虎360也在2023年推出了大模型产品360智脑,搜狗创始人王小川建立的百川智能成为中国首批通过审核的大模型之一,它们在各项评测中都取得了不俗的成果。 从搜索引擎的发展看,通过激烈的竞争,搜索引擎最终形成了若干个巨头公司为人类提供互联网海量数据的索引服务,同样我们认为作为搜索引擎的升级版,人类社会也不需要很多大模型提供同质的服务。包括搜索引擎、大数据、社交网络等领域拥有优质大数据、人工智能技术积累和广泛应用场景的巨头或创业公司,在大模型的产业竞争中将具有更强的竞争力,并在未来的竞争中脱颖而出一家或若干家为人类提供集中统一的智能服务。 二.行业垂直大模型建设思路:继续提升通用大模型智能水平 应该指出,当前,人类社会对大模型充满了热情,特别在中国,很多人希望大模型能够与金融、法律、工业、农业、电力、建筑等等行业领域结合,从而实现弯道超车,但我们必须考虑大模型的特点,需要在大模型的垂直化和行业化过程中保持谨慎。 大模型的成功并不仅仅是参数量大,而是用大规模预训练+微调的方式,对海量的跨领域知识进行学习时涌现出来新的能力,而且这些新的能力往往与创新有关,如翻译,创作文章,创作图像、编写诗歌,编写程序等,然而这种创新能力在工作时产生的结果并不稳定,会出现“幻觉”和胡编乱造的情况。同时由于神经网络本身的特点,其内部运行机制的可解释性问题也一直没有解决,因此对于需要精密控制或精确结果的产业领域,大模型并不是可靠的工具和技术。 另外一个误区,认为用大模型的训练方法加上行业产业的大数据就可以形成高质量的行业大模型。这个观点并不符合大模型涌现出创新能力的规律,过于单一领域的知识反而会降低大模型的涌现出新能力的水平,导致无法有效应用到行业产业中。因此应继续提高Chatgpt,文心一言、Llama、智谱、百川等等通用大模型的智能水平,通过这些通用大模型平台与其他可靠性高的人工智能技术协同工作,并与各个行业结合,这种路径要比建设专门的行业大模型更为稳健和有效。 三.值得期待的大模型未来 当然,大模型并不是人工智能的全部,也不是数字科技的全部,它只是其中一个当前活跃的重要技术和产品。应避免大数据热时,一切皆大数据;元宇宙热时,一切皆元宇宙;大模型热时,一切皆大模型,大模型需要与其他技术和产品结合才能发挥更大的作用。 大模型的不断发展和与其他技术产品结合的过程将是持续探索和尝试的过程。无论如何,大模型的出现的确是一个革命性的突破,有很多科学家认同Chatgpt等大模型已经可以突破图灵测试,未来在智能和意识的基础原理上也将带来更多突破性的启发。 在产业应用上,大模型与其他不同类型的人工智能技术、网络技术、大数据技术结合,与不同的办公、学习、生产、生活结合会持续产生出具有非凡想象力的应用。例如微软办公Office 接入GPT-4,百度利用文心一言重构包括搜索、文库、如流、智能云等业务产品。未来还会发生怎样的革命性变化,我们还需要耐心等待大模型的持续发育和成长,毕竟它还是一个出生来到全人类面前还不到1年的婴儿,(从以ChatGPT3.5为代表的大模型大规模向人类提供服务算起)。 (作者:刘锋,中国科学院虚拟经济与数据科学研究中心研究组成员,中科数字大脑研究院院长、中国指挥与控制学会城市大脑专委会副主任兼秘书长)

刘锋:大模型的产业未来发展趋势与挑战



最近每次登录上自己的ECS,都屡屡发现这么一个消息,一开始以为是别人搞错了(我这么一个小破服务器不可能会有人来恶意攻击),想想可能过两天就不会有了,没放在心上。 没想到持续了几个星期,一直都这样。 无奈之余,我就下了狠心把这个IP给ban了。 BUT。。。。。。Turned out it’s the IP address from my office……Found that I was banned to access to my ECS from my office. 无奈之作,canceled the iptables rule. So who is trying to crack my ECS? If you really need it, I can hand over my ECS login password to […]

Who’s trying to crack my ECS?


Prevent bad bots from crawling your website Bad bots here, I mean bot like AhrefsBot, which sucked all my VPS resources out, including but not limited to CPU usage up to 30%. So I decided to block it from crawling my website for now. Tried the following two steps, and […]

Prevent bad bots from crawling your website


WebRTC
针对webrtc在弱网的码率自适应机制的学习。列举了几个影响因素。有时间的话,再来继续深入研究。 编码发送层优先级 发送端利用带宽估计算法估算上行带宽,然后根据策略进行码率分配(rtcsdk上层会指定每一层的码率),到了webrtc后,webrtc会在此带宽配置下,按顺序优先分配码率,先小流,再中流,最后大流,当大流(或中流)分配到的码率小于大流(或中流)的最小码率时就会停发大流(或中流)。比如: 估算出来的带宽是1 mbps,小流分配了256kbps,中流分配了512kbps,这个时候留给大流的只有256kbps,但是如果大流指定了最小带宽大小256kbps,则大流就会被停发。 DegradationPreference策略 a)DISABLED:禁用,不进行任何调整;b)MAINTAIN_FRAMERATE:保持帧率,降低分辨率(主流默认用这个策略);c)MAINTAIN_RESOLUTION:保持分辨率,降低帧率(双流默认用这个策略);d)BALANCED:平衡,降级时先尝试降低帧率,如果当前分辨率不适合再降低帧率,则降低分辨率,然后再尝试降低帧率,依次交替进行;升级时也是先尝试升高帧率,如果当前分辨率不适合升高帧率,则升高分辨率,依次交替进行。 编码耗时统计 方法如下:编码使用率=视频编码时间/采集间隔时间(对分子分母进行样本收集并做平滑处理)视频编码时间 = 本帧编码结束时间 – 本帧编码开始时间采集间隔时间 = 本帧编码开始时间 – 上帧编码开始时间 系统每5秒执行一次CheckForOveruse任务, 当编码使用率连续2次超过阈值上限,则判定为OverUse触发降级AdaptDown;反之当编码使用率低于阈值下限,则判定为UnderUse触发升级AdaptUp。为避免震荡,判定为UnderUse时会有迟滞处理。 不同运行环境的编码使用率上下限阈值默认设置如下(%):硬编:200/150软编:85/42mac软编:单核20/10,双核40/20,其他核心数85/42。(目前没用到) QP统计 与CPU使用度检测类似,初始化过程发生在编码器重新创建的时候(流初始化,或者编码格式变化)。QualityScaler通过统计、计算编码后的每幅图像的量化参数(QP,Quantization Parameter,相当于图像的复杂度),当一系列图像的平均QP超过阈值时会调整分辨率(H264的合法范围是24~37),超过37要降分辨率,低于24要提高分辨率。QP检测的主体代码在quality_scaler.cc的QualityScaler类中,后者作为observer注册到VideoStreamEncoder中,VideoStreamEncoder内完成了相关流程的控制。 每帧编码图像的QP值会被加入样本集中,然后周期性调用CheckQpTask(默认每2秒,但前一次执行结果会影响下一次执行的周期)。 qp的变化通过回调进行反馈。在函数ReportQPHigh中会修改fast_rampup_ = false; 目的是分辨率一旦降低后,CheckQP调用的周期将变长,再提高分辨率的话,需要等很长时间。 经在不同终端上的测试,不同运行平台的QP值上下限阈值,当前版本的默认QP值设置如下:硬终端:22 ~ 45(插件中自己定义)Windows:24 ~ 37(已经改成24 ~ 42)Android:24 ~ 37(已经改成24 ~ 45)ios/mac:28 ~ 39(已经改成28 ~ 45)特殊环境下如果QP阈值默认设置不合适,可以通过WebRTC-Video-QualityScaling这个FieldTrial来设置修改,但一般情况下不建议修改。 降分辨率策略 交替乘 2/3 and 3/4以缩小分辨率到最接近目标分辨率,然后这个最接近的分辨率。Alternately scale down […]

webrtc弱网自适应(自动升降速)要点



Source: https://www.theverge.com/2018/5/7/17327596/microsoft-meeting-room-demo-build-2018 Microsoft just demonstrated a meeting room of the future at the company’s Build developer conference. Meeting rooms, conference calls, and meetings in general are usually the stuff of nightmares, but Microsoft is working on prototype hardware that will make meetings a lot easier. Microsoft’s meeting room demonstration is […]

Microsoft’s meeting room of the future is wild


Forwarded from: https://howdoesinternetwork.com/2016/quantum-key-distribution ——————————- QKD – Quantum key distribution is the magic part of quantum cryptography. Every other part of this new cryptography mechanism remains the same as in standard cryptography techniques currently used. By using quantum particles which behave under rules of quantum mechanics, keys can be generated and distributed to […]

QKD – How Quantum Cryptography Key Distribution Works


I found this post in LinkedIn, and I do like the opinions Lennox expressed, so I put it here to share it with more peoples. Source: http://www.bbc.com/capital/story/20170430-why-you-shouldnt-be-yourself-at-work ————————————————————- The most common career advice can be completely misleading. Lennox Morrison explains why. By Lennox Morrison 1 May 2017 ‘Be yourself’ is […]

Why you shouldn’t ‘be yourself’ at work





Sympton: ——————————————- TE40 caller : 202.102.40.211, E.164: 02510000 TE40 caller : 192.168.0.109,  E.164: 02510000 H600 callee : 192.168.0.105,  E.164: 654320 VP9650: 202.102.40.219 Pcap file was captured on H600 side. All exchanged signaling commands between H600 and VP9650: ->SCI <-SCR,facility ->setup <-ARQ ->ACF <-alerting,connect ->facility ->TCS …Twenty seconds later… –>ReleaseComplete, DRQ […]

An issue when collaborating with HUAWEI VP9650 with H.460




Both ZTE T800 and HUAWEI TEx0 claim to have T.140 supported, but when I digging into these entities by running some tests between T800, TE40 and TE60, my current status is I’m not persuaded. Maybe only because I don’t know how to configure them to make T.140 enabled. Here is some T.140 related information, and my steps to analysis to the protocols of HUAWEI TEx0 and ZTE T800. A screen shot of HUAWEI TEx0’s administration manual about T.140. Source: http://support.huawei.com/ehedex/pages/DOC1000063904NZD1231E/01/DOC1000063904NZD1231E/01/resources/webhlp/te_webhlp_00005.html#te_webhlp_00005__tb5 1. T.140 related standard documents 1)T-REC-H.323-200002-S!AnnG!PDF-E.pdf 2)T-REC-H.224-200501-I!!PDF-E.pdf 3)T-REC-T.140-199802-I!!PDF-E.pdf 5)T-REC-T.140-200002-I!Add1!PDF-E.pdf 6)RFC4103 – RTP Payload for Text Conversation.pdf 2. Major descriptions of implementing T.140 T.140 related descriptions in T-REC-H.323-200002-S!AnnG!PDF-E. 1) H.245 TCS for T.140 In the capabilities exchange, when using a reliable channel, specify: DataApplicationCapability.application = t140 DataProtocolCapability = tcp In the capabilities exchange, when using an unreliable channel, specify: DataApplicationCapability.application = t140 DataProtocolCapability = udp 2) H.245 Open Logical Channel In the Open Logical Channel procedure, specify: OpenLogicalChannel.forwardLogicalChannelParameters = dataType DataType = data And select a reliable or unreliable channel for the transfer of T.140 data by specifying the DataApplicationCapability and the DataProtocolCapability as above. According to the description in T-REC-H.224-200501-I!!PDF-E, there should be only one H.221 channel, we can still send multiple protocols, like FECC, T.120 and T.140, in one single channel, this type of channel has a name: H.221 MLP data channel. 3) Packetization of T.140 data Reliable TCP mode: skipped because don’t find any newlly established TCP connections. UnReliable mode: I do find an H.224 capability in both of these entities, since there is no OLC requests other than Audio, Video, and H.224 data. Let’s suppose they are re-using the H.221 MLP data channel for both FECC and T.140 transmission. 4) H.224 protocol octet structure 5) H.224 -Standard Client ID Table 3. H.224 data packets sending between TE60 and T800 I managed to extract the H.224 data packets from the PCAP file. And they are like these: 7e 7e 7e 00 86 c0 00 00 00 00 00 03 40 00 81 a8 e8 0f b2 07 db 07 9f 9f 9f bf ff Explain the packet by the standard document’s description: […]

Does ZTE T800 and HUAWEI TEx0 support T.140?


5
Got mails continuously from everywhere throwing question to me about AAC audio in H.323. So I arranged this post to example my previous posts: http://rg4.net/archives/1480.html, http://rg4.net/archives/1126.html, http://rg4.net/archives/1112.html The pcap file for this example can be downloaded here: HUAWEI_TE600-vs-ZTE_T800.pcapnp Here it is. 1. Basic knowledge: AAC LD descriptions in 14496-3 It operates at up […]

An example of AAC capability in H.245