暂无个人介绍
能力说明:
了解变量作用域、Java类的结构,能够创建带main方法可执行的java应用,从命令行运行java程序;能够使用Java基本数据类型、运算符和控制结构、数组、循环结构书写和运行简单的Java程序。
阿里云技能认证
详细说明本工作针对图像到图像的转换问题,利用图像的尺度空间(scale space),设计了一个基于图像尺度空间分解的通用神经网络,刷新了图像分解问题在标准数据集上的测试性能,并可见用于深度重建和像素标记等常见视觉问题。
在推荐系统的发展历程中,面临两个核心问题:用户的长尾覆盖度以及新商品的冷启动,在这两个维度下的模型扩展能力的瓶颈一直以来对广大推荐算法工程师都是不小的挑战。本文基于Graph Embedding的理论知识提出了创新框架,旨在提升商品推荐的多样性和发现性。
本文主要介绍了Wide&Deep、PNN、DeepFM三个模型以及1688CBU事业部的顾海倩同学提出的Wide&Resnet模型结构,并尝试在1688猜你喜欢的真实数据场景中进行应用。文内有一些实验结果,也提出了一些遇到的问题,希望能与大家一起分享讨论。
短视频一般从“点击率”与“观看时长”两方面优化来提升用户消费时长。接下来,阿里工程师从这两方面重点论述短视频模型点击时长多目标优化。
信息抽取主要解决从海量文本中快速、准确地抽取出需求信息。关系抽取是信息抽取的关键技术之一,主要任务是从文本中识别出实体,并抽取实体间语义关系。把句法信息加入到实体的表示模型里是本文的创新之处和研究重点,下面,我们一起深入了解。
在高风险分类(例如:高死亡率疾病监测、自动驾驶等场景)中控制假阳性率是非常重要的,由算法得出的结果将对个人产生巨大的影响。遗漏一名潜在病人的风险,远远高于误诊一名正常人。因此,我们希望在保证分类器假阳性率(即错误地将负样本分类为正样本的概率) 低于某个阈值 τ 的前提下,最小化其误分正样本的概率。
阿里小蜜是2015年阿里发布的一款智能客服机器人。2017年双11期间,阿里小蜜的服务量达到643万,其中智能解决率达到95%,占整体服务量的95%。经过近几年的发展,能否更进一步解决智能客服机器人的压力成为当前我们思考的问题。今天,小蜜机器人实验室的市丸带领大家一起思考。
电商平台中,商品标题是用户认知商品的第一渠道。为了更好地描述商品属性,吸引买家注意,商家往往会在标题中堆砌大量冗余词,导致标题过长无法完整展示,给APP端用户带来不好的体验。如何在不影响商品成交转化率的前提下,将长标题变成短标题?本文将带你找到答案。
在实际应用中,我们发现城市大脑交通视频数据样本不足的问题,因此提出了一种图像生成算法。受条件对抗生成网络和风格迁移学习的启发,采用内容提取网络和风格提取网络分别从内容图片和风格图片中提取特征,将两者融合后,通过图片生成网络获得融合相应内容和风格的图片。
经真实的交通场景评测,该算法在重要指标上已经超过了此前的最好方法。
本篇论文收录于ACM MM 2017(多媒体领域世界顶级会议),提出了全新的基于 CNN 的行人重识别方法,接下来,我们一起进行深入思考。
近年来,深度卷积神经网络(CNN)方法在单幅图像超分辨率(SISR)领域取得了非常大的进展。
我们已经进入到了一个大数据时代,不同模态的数据例如文本、图像等正在以爆炸性的速度增长。这些异质的模态数据也给用户的搜索带来了挑战。
本期将和大家分享一个大并发下php使用tcp长连接访问后端的优化方法。
mysql-proxy是mysql官方提供的mysql中间件服务,上游可接入若干个mysql-client,后端可连接若干个mysql-server,它使用mysql协议,任何连接mysql的上游无需任何更改即可迁移至mysql-proxy上。
到底什么是“四层/七层”交换技术
负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】。
“DNS轮询”究竟是不是过时的技术,是不是可以被其他方案替代,接入层架构技术演进,是本文将要细致讨论的内容。
能否根据异构服务器的处理能力来动态、自适应进行负载均衡及过载保护,是本文要讨论的问题。
有个朋友问我分区表在58的应用,我回答不出来,在我印象中,百度、58都没有听说有分区表相关的应用,业内进行一些技术交流的时候也更多的是自己分库分表,而不是使用分区表。于是去网上查了一下,并询问了58到家的DBA专家,将自己收到的信息沉淀下来,share给大伙。
webim通过http长轮询可以保证消息的绝对实时性。这种实时性的保证不是通过增加轮询频率来保证的,而是通过夯住http消息连接来保证的,在大部分时间没有实时消息的情况下,这个http消息连接对于webserver的请求压力是90秒1次,能够大大节省了web服务器资源。
如果站点架构满足以下几点,那么本文的优化方案会非常适合:
群消息这么复杂,怎么能做到不丢不重?
消息时序是分布式系统架构设计中非常难的问题,ta为什么难,有什么常见优化实践,是本文要讨论的问题。
让同一个群gid的所有消息落在同一台服务器上处理。 有朋友就要问了,如何保证一个群gid的消息落到同一个服务器处理呢,“id串行化”具体是怎么实现的呢,这个问题在年初的一篇文章中描述过,这里再给有疑问的同学解答一下。