随着大语言模型的生成效果越发逼真，各行各业迫切需要一款可靠的 AI 生成文本检测器。然而，不同行业对检测语料的要求不同，例如在学术界，普遍需要对大段完整的学术文本进行检测；在社交平台上，需要对相对简短而较为支离破碎的假消息进行检测。然而，既有检测器往往无法兼顾各式需求。例如，主流的一些 AI 文本检测器对较短的语料预测能力普遍较差。 对于不同长度语料的不同检测效果，作者观察到较短的 AI 生成文本可能存在着一部分归属上的「不确定性」；或者更直白地说，由于一些 AI 生成短句同时也常常被人类使用，因而很难界定 AI 生成的短文本是否来自于人或 AI。
什么是Perfetto?Perfetto是Android 10中引入的全新平台级跟踪工具。这是适用于Android、Linux和Chrome的更加通用和复杂的开源跟踪项目。与Systrace不同，它提供数据源超集，可让您以protobuf编码的二进制流形式记录任意长度的跟踪记录。您可以在Perfetto界面中打开这些跟踪记录。Perfetto是一款比较强大的安卓性能分析工具(它还可以用于分析其他系统)，其功能涵盖了对CPU的追踪、电池耗电追踪、系统调用的追踪，内存分配与释放的追踪。除了性能数据记录还，它还有自带的分析工具，分析工具包括：通过自定义追踪功能来拼接命令行，用SQL方式筛选数据，将数据转换成其他格式方便自定义数据处理，Web形式的火焰图（Web可离线），以及Web上的ADB功能（有bug）。
老牌的 CICD 工具 Jenkins 应该是大部分都接触过的，而在云原生时代，诞生了两大 CI/CD 框架，也就是 Argo Workflow 和 Tekton，本文主要介绍一下 Argo Workflow。
2022年，Qunar 技术中心完成了轰轰烈烈的服务瘦身项目，在各个技术团队的努力下，最终完成了将上千个应用和千万行代码瘦身50%的目标。 在如此艰巨的任务达成目标之后，对于技术团队来讲，接下来的重点就变成了如何维持住这来之不易的成果，如何避免反弹。作为一家处于激烈竞争的互联网公司，Qunar 致力于不断为用户提供低价的产品，同时维持优秀的服务水平和用户体验，业务的演进和系统的迭代在持续不断的进行。随着业务的演进和系统的迭代，原本瘦下来的系统上会有新的代码填充进来，也会有新的应用加入或者拆分出来，这些动作都是会重新增加系统的臃肿程度，如果没有治理手段，会导致我们好不容易取得的瘦身成果慢慢流失。就像一个成功瘦身的人，如果瘦下来之后没有制定和执行合理健康的饮食计划和运动计划，迟早又会回到身体臃肿的状态。 基于此，在瘦身项目推进的同时，Qunar 技术中心启动了系统防腐化治理的项目，目的是在瘦身项目达成目标之后，建立和运用治理手段，防止或者减缓系统不受控制的膨胀，将系统的维护成本维持在较低的水平。这项工作由作者牵头，Qunar 技术中心业务架构 SIG 承接。
实时音视频通信 RTC 在成为人们生活和工作中不可或缺的基础设施后，其中所涉及的各类技术也在不断演进以应对处理复杂多场景问题，比如音频场景中，如何在多设备、多人、多噪音场景下，为用户提供听得清、听得真的体验。作为 RTC 方案中不可或缺的技术，语音增强技术正从传统的基于统计学习的方案向基于深度学习的方案融合演进，利用 AI 技术，可以在语音降噪、回声消除、干扰人声消除等方面实现更好的语音增强效果，为用户提供更舒适的通话体验。 作为语音信号处理研究领域的旗舰国际会议，ICASSP (International Conference on Acoustics, Speech and Signal Processing) 一直代表着声学领域技术最前沿的研究方向。ICASSP 2023 收录了多篇和音频信号语音增强算法相关的文章，其中，火山引擎 RTC 音频团队共有 4 篇研究论文被大会接收，论文方向包括特定说话人语音增强、回声消除、多通道语音增强、音质修复主题。本文将介绍这 4 篇论文解决的核心场景问题和技术方案，分享火山引擎 RTC 音频团队在语音降噪、回声消除、干扰人声消除领域的思考与实
携程火车票营销页使用 css 制作动画很多年了，这大大提高了动画给予页面丰富的视觉体验。不过，在开发的过程中，也遇到了一些性能相关问题和用户反馈，比如头部动画卡顿、页面打开时间较长、页面打开后部分数据加载时间较长等问题。为解决这些问题，我们借助性能检测工具定位问题，并查阅源码、文档等资源解决问题，形成了这篇文章。
在日常开发中会经常遇到一些需要异步定时执行的业务诉求，典型的使用场景如：超时未支付订单关单、每隔 2h 更新好友排行榜、3.22 日 17 点《xx》剧上线等。目前业务侧多基于以下思路来快速搭建一个调度系统，mysql 或者 redis 队列存储待执行任务，通过 crontab 定时触发应用完成“捞取、计算、执行等操作”。不难看出存在几类亟待解决问题： 1）缺少统一的调度平台导致各业务重复开发； 2）简易版调度实现在任务吞吐、调度时效上缺少保障； 3）业务和调度数据强耦合存储给线上稳定性引入大 key、慢 sql 风险。 目前存在多类开源解决方案如 XXL-Job 、 Elastic-Job、quartz 调度等，但这些都属于进程级调度平台，很难满足更细粒度的业务调用。基于上述的业务诉求和司内现状，我们准备搭建一套通用的分布式任务调度平台（以下统称为 tjobs 平台）以满足业务高可靠、低延迟的海量任务调度诉求。
作为互联网公司的研发工程师，微服务的架构思想对于各位读者朋友来说，已经不是陌生东西。我们当中的大多数人，或多或少经历过从单体应用到微服务化的系统拆分和演进过程。我们按照庞大系统的业务功能和特征，将其从一个单体的大应用，逐渐地拆分成很多的子系统的协同配合完成业务功能，甚至拆分后的某些子系统服务，还可能再拆分出来更多的更细颗粒度的子系统服务。拆分后的服务之间，采用PRC调用方式的通信，也就越来越多。随之而来的，跨系统服务之间的数据一致性的问题就会越来越突出了。比如电商系统中营销活动系统的积分和优惠券的发放和扣减，比如电商系统的核心下单核心链路上，首页瀑布流，商详页，下单页等等商品价格全链路一致性等等，支撑这些业务功能的实现，往往可能需要依赖来自N个不同的业务系统服务提供的数据读写服务能力来完成。
