/tag/算法

我有1个美区的48个月 有1个英区的48个月。实测美区用量比英区至少高30%，看了很多帖子说英区少的 也有说差不多的。 我很好奇用量的算法，本质上是走反代获取的比如gpt 5.5，那我们平时web端对话也会消耗额度对吧？ 那现在大家对账不一致 有没有可能是大家在网页用量上不一样？ 我不了解这个用量的算法 所以问一下大家。如果是我上述的算法的话，那pro拼车，他们转web权限，岂不是也会影响到反代出来的“codex”的用量？ 另一个角度，如果网页版和反代出来的是分开计算的，完全不受影响的，那各个地区的team差异化也太大了 （pro plus用量是否也跟地区有关） 5 个帖子 - 4 位参与者 阅读完整话题

我们是一家专注于视频内容生态的互联网平台，服务数千万用户，每天处理海量视频数据。通过智能推荐算法，为用户带来沉浸式观看体验，同时助力内容创作者成长。 欢迎对推荐系统、多模态学习充满热情的你加入，一起打造行业领先的视频算法！岗位职责 负责视频推荐系统全链路算法研发与优化，包括召回、粗排、精排、重排等模块，持续提升用户完播率、互动率、留存时长等核心指标； 挖掘用户行为特征与视频多模态内容（视觉、音频、文本），构建精准的用户画像和视频表征模型，实现个性化智能推荐； 探索并落地前沿技术，如 Transformer 、图神经网络、多模态大模型、AIGC 在视频推荐中的应用，推动算法创新； 设计并执行 AB 实验，分析线上数据，诊断问题并快速迭代优化模型效果与系统性能； 与产品、后端、数据团队紧密协作，推动算法从研究到高效线上落地的全流程。 任职要求 计算机、人工智能、软件工程、数学等相关专业，本科及以上学历（硕士/博士优先）； 2 年以上推荐系统或多媒体算法开发经验，有短视频/长视频平台实际项目经验者优先； 扎实的机器学习/深度学习基础，熟练掌握 Python ，熟悉 PyTorch 或 TensorFlow 至少一种框架； 熟悉大规模数据处理工具（如 Spark 、Flink ）和分布式系统，有推荐系统工程落地经验加分； 对视频内容理解（ CV 、音频处理、NLP ）有一定了解，熟悉 FFmpeg 、OpenCV 等工具者优先； 具备良好的数据分析和 AB 实验设计能力，强烈的责任心与团队协作精神，能适应快节奏的工作环境。 请携带简历咨询，谢谢； TG：@dajidali2026 E: [email protected]

1、算法专家（AI大模型/供应链方向） 2、供应链算法工程师 3、AI产品经理（用工平台/新零售） 4、用工中心/新零售销售副总监 5、战略招商部招商经理（高化名品） 以上岗位base深圳，本科3年以上岗位相关经验，专家岗博士5年起 ———————————— 天虹数科：国有控股上市、深耕零售 40 余年、规模百亿级、华南领先、全业态数字化融合、自研灵智数科输出零售 tech、AI 大模型赋能的智慧零售龙头。 2 个帖子 - 2 位参与者 阅读完整话题

岗位：C++开发工程师（需要去中证资本驻场）1.5-2.2w 岗位内容： 1、负责算法交易平台的功能设计、软件开发与维护； 2、负责维护订单管理系统； 3、负责平台服务的性能优化和故障排查，确保平台和策略的运行稳定性； 4、根据项目要求编写清晰、规范的软件开发文档，包括设计文档、测试文档等。 要求：熟悉C++17特性，对C++内存模型有一定了解 5、3年及以上工作经历，具备金融机构、金融科技企业、C/C++项目开发经验者优先。 6、具有较强的表达、沟通和协作能力；良好的合规意识、业务学习能力；具有较强钻研能力，善于发现问题并能给出具体的解决方案； 7、精通C/C++等编程语言，熟练掌握多线程与并发编程技术，熟悉Linux或Windows开发环境。 8、精通常见的进程间通信机制、网络编程接口，熟悉TCP/IP、UDP协议及通信过程； 9、对高可用、同城双活、主备切换等系统有一定了解； [!note] 岗位在上海，一周内可入职。内推渠道已开启！有合适的朋友欢迎投递简历。 联系方式 邮件主题请注明： 应聘C++开发工程师 + 姓名 + 学历 + 毕业院校 联系人：朱老师 简历投递邮箱： [email protected] 1 个帖子 - 1 位参与者 阅读完整话题

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 学习算法的过程中总是不能清晰地理解运行的过程，于是我做了这个可视化算法执行过程的工具 PyWeave 是一个开源桌面应用，用来帮助学习和理解 Python 算法代码的执行过程 它内置 Python 编辑器，可以运行用户输入的 Python 代码，并逐行捕获执行状态。应用会把局部变量、数组内容、指针变量和变量变化展示成可视化图，让用户能看到算法每一步到底发生了什么 各位佬们来看看怎么样 https://github.com/XYZ1024-alt/PyWeave 1 个帖子 - 1 位参与者 阅读完整话题

使用max20x 订阅,让它帮我review一个AES加密算法的魔改.读完代码就切换 甚至我 手动停止,切换成Fable5以后只要一读到AES的内容就会自动切换成Opus 4.8 1 个帖子 - 1 位参与者 阅读完整话题

web3前五公司 岗位职责： 1、主导Agent创新产品的探索与孵化 主动跟踪AI Agent领域的前沿进展——包括但不限于MCP/A2A互操作协议、Deep Research Agent、Agentic Coding范式（如Anthropic Claude Code的设计哲学）、Skills可组合架构（如OpenClaw/OpenHands的Skills模式）、多Agent协作系统、推理模型驱动的Agent等最新技术范式——结合虚拟货币领域的业务场景，自主发起创新产品的构思、可行性验证与原型搭建。我们期望你是一个主动定义问题的人，而非等待需求输入。 2、负责Agent系统的算法设计与规模化落地 设计并实现面向虚拟货币链上资产分析、交易决策辅助、深度研究与信息聚合等场景的Agent算法方案，涵盖以下核心模块： 任务规划与深度推理（Planning & Extended Thinking）：参考Anthropic Agentic Coding中"先深度思考再行动"的设计哲学，结合Deep Research Agent的自适应搜索规划范式，实现Agent对复杂金融任务的自主拆解、充分推理与多步执行； 技能抽象与可组合架构（Skills Composition）：借鉴OpenClaw的Skills模式，将链上数据查询、K线技术分析、合约风险审计、舆情监控、交易策略执行等能力封装为标准化、可复用的Skill模块，支持Agent根据任务动态选择与编排Skills，并持续沉淀新的Skill以实现能力进化； 工具调用编排（Tool-use Orchestration）：基于MCP协议等标准，实现Agent与链上数据源、行情接口、DeFi协议、分析工具的标准化对接； 多Agent协作（Multi-Agent Collaboration）：借鉴A2A协议思想，构建多Agent协同工作流，支持研究Agent、交易Agent、风控Agent等角色的动态编排与通信； 迭代自我验证与纠错（Iterative Self-Refinement）：深度借鉴Anthropic Claude Code的"执行→验证→修正"闭环机制，构建Agent在金融决策场景中的自主验证与迭代优化能力，确保输出的可靠性与准确性； 环境自主探索与上下文构建：参考Agentic Coding中Agent自主探索代码仓库的范式，实现Agent对链上生态、市场环境的主动感知与全局理解，减少对人工信息喂入的依赖； 长期记忆与知识积累：支持Agent对长周期市场信息的持续跟踪、经验沉淀与知识管理。 推动从概念验证（PoC）到生产级系统的完整闭环。 3、构建Agent评估与持续优化体系 引入并定制Agent Harness类评测框架（参考SWE-bench、AgentBench、TAU-bench等业界实践），建立面向虚拟货币Agent产品的标准化评测体系，设计涵盖以下维度的评测指标与Benchmark： 端到端任务完成率 工具调用准确率与Skill组合合理性 多步推理成功率与规划质量 自我纠错与容错回退能力 安全边界遵守率 通过数据驱动的方式持续迭代算法策略，确保Agent在真实业务场景中的可靠性与用户体验。 4、驱动跨职能协作与资源整合 作为算法侧的核心驱动者，主动拉通数据、工程、前后端、测试等资源，推动项目高效协作。与产品、业务团队深度配合，将业务洞察转化为技术方案，根据市场反馈快速调整迭代，提升产品竞争力。 5、技术前瞻与知识沉淀 持续关注OpenAI、Anthropic、Google DeepMind、开源社区（OpenClaw/OpenHands等）在Agent架构、推理模型、互操作协议、Skills可组合范式、Agentic Coding等方向的最新研究与工程实践，主动输出技术调研报告、竞品分析与可行性方案，为团队技术路线决策提供依据。 任职要求： 1、 硕士及以上学历，计算机科学、人工智能、金融工程、区块链等相关专业； 2、 良好的英文沟通能力，能快速阅读、理解并提炼英文前沿技术文献、开源项目文档与协议规范； 3、 熟悉主流Agent框架与生态（如LangChain/LangGraph、CrewAI、AutoGen、OpenAI Agents SDK、OpenClaw/OpenHands、Dify等），了解MCP/A2A等新兴互操作协议与Skills可组合架构，有基于上述框架成功落地Agent应用的经验； 4、 精通Python编程，熟练掌握至少一种深度学习框架（如PyTorch、TensorFlow）或机器学习库（如Scikit-learn），具备Prompt Engineering、RAG、Fine-tuning、多轮对话管理等LLM应用层核心技能，能独立完成从算法设计到工程部署的全流程； 5、 具备扎实的代码工程能力与系统设计能力，能编写高效、可维护、可扩展的代码，熟悉Git等版本控制工具与协作开发流程； 6、 在国内外知名学术会议或期刊上发表过相关领域论文者优先，或在Kaggle等竞赛平台取得优异成绩者优先； 7、 具备良好的团队协作精神与沟通能力，能与不同背景的人员高效合作，善于将模糊的业务需求抽象为清晰的技术问题并推动解决。 加分项 1、 熟悉Web3、区块链、DeFi、虚拟货币等领域的核心概念与业务逻辑，有至少3年股票、期货、虚拟货币等相关行业工作经历，或有实际人工交易/量化交易经验； 2、 有从0到1独立孵化AI Agent产品的经历，熟悉Anthropic Agentic Coding或类似"Agent自主完成端到端任务"的产品研发思路，具备强烈的产品感知力和业务敏感度； 3、 有Agent能力模块化、Skill封装与编排的工程实践经验，理解可组合Agent架构的设计理念； 4、 有构建Agent评测体系（Agent Harness/Benchmark）的经验，了解如何科学衡量Agent的能力边界与改进方向； 5、 对AI在金融科技领域的应用趋势有深入思考，能前瞻性地提出创新方向并主动验证可行性； 6、 具备Builder心态——不满足于完成分配的任务，而是持续主动寻找高价值问题、定义解决方案并推动落地。 8 个帖子 - 2 位参与者 阅读完整话题

IT之家 6 月 8 日消息，小米集团手机部副总裁、可穿戴部总经理张雷今日上午宣布， 小米手环 9 新版本先锋计划正式开启 。 本次更新带来多项实用升级：功耗策略全面优化，设备更省电、续航更持久；睡眠监测算法升级，并支持获取小米手机状态，睡眠数据更准确；消息隐私体验进一步增强，垂腕佩戴时可关闭消息详情展示，让通知更安心。同时修复了多项已知问题，系统运行更稳定。 IT之家注意到，目前，小米手环 9 最新内测固件 3.1.26 版本已开启推送，具体更新内容如下： 优化功耗策略，设备更省电，续航更持久。 睡眠监测算法升级，支持获取小米手机状态，提升数据准确性。 同步手机 OS 3 新版勿扰模式，提升通知管理体验。 增强消息隐私保护，避免敏感信息泄露。 支持更多新车型车钥匙功能，拓展使用场景。 表盘支持预置表盘删除，管理更自由。 公交卡支持范围扩展，出行更方便。 优化解锁手机流程，增强设备连接安全性。 修复已知问题，增强系统稳定性，改善用户体验。 相关阅读： 《 小米手环 9 新版本先锋计划开启报名：功耗优化、睡眠监测算法升级，500 名额 》

IT之家 6 月 8 日消息，小米集团手机部副总裁、可穿戴部总经理张雷今日宣布，小米手环 9 新版本先锋计划正式开启。 本次更新带来多项实用升级： 功耗策略全面优化，设备更省电、续航更持久；睡眠监测算法升级，并支持获取小米手机状态，睡眠数据更准确；消息隐私体验进一步增强，垂腕佩戴时可关闭消息详情展示，让通知更安心。同时修复了多项已知问题，系统运行更稳定。 IT之家注意到，本次特邀 招募 500 名 小米手环 9 用户： 报名时间：2026 年 6 月 8 日（名额满即停） 内测周期：2026 年 6 月 8 日 — 6 月 14 日 报名路径：小米社区 App → 内测中心 → 搜索“小米手环 9 新版本内测” 温馨提示：本次活动仅限“小米手环 9 ”用户。

IT之家 6 月 8 日消息，提起野生动物走私，我们或许会想到犀牛角、被当作宠物贩卖的红毛猩猩幼崽。但海洋生物走私这类鲜为人知的犯罪活动，同样会严重破坏海洋生态系统。令人担忧的是，鱼翅等常见走私海洋野生物品极易藏匿在行李或包裹中跨境运输，往往难以被查获。为解决这一难题，科研人员借助人工智能研发出一套算法，可识别鱼翅、海马、海参等常见走私海洋生物样本，识别准确率达 92%。 麦考瑞大学的瓦妮莎 · 皮罗塔博士是这篇发表于《海洋可持续发展前沿》期刊论文的第一作者，她表示：“野生动物交易残忍且违背道德。很多人可能还是第一次听说海洋野生动物非法走私。走私活动的目标不只是犀牛角、象牙这类大众熟知的物种。我们希望借世界海洋日，让这一问题受到广泛关注。” 海洋中的危机 据估算，全球海洋野生动物非法交易的年交易额高达数十亿美元，濒危物种因此面临巨大威胁。人们为食用、制药、制作饰品或当作宠物而贩运海洋生物，本就岌岌可危的生物种群生存状况进一步恶化。此外，活体走私的海洋生物一旦逃逸，还会在其他生态系统中成为外来入侵物种。然而，现场查处走私行为向来知易行难，这不仅导致走私活动难以遏制，也让其对生态环境造成的影响无法准确估量。 据IT之家了解，研究团队改造了机场现有的 X 射线计算机断层扫描设备。这类设备原本用于排查爆炸物及生物安全隐患，能对单一物品进行多次 X 光扫描，生成内部物品的三维影像。科研人员利用神经网络训练算法，使其能够在影像中识别常见走私物种，希望打造一套可自动标记可疑行李、交由人工核查的智能系统。 本次研究将识别对象锁定为鱼翅、海马和海参。鱼翅是热门食材，干海马则多用于传统药材交易。海参走私的相关记录相对较少，但已知其长期遭到非法过度捕捞。研究人员认为，海参走私的实际规模远比目前有据可查的情况更大。 研究人员共完成 298 组扫描样本，其中包括 20 份海参样本、30 份海马样本以及 18 份鱼翅样本，多数样本均来自以往查获的走私货品。研究人员为每份样本调整摆放位置、搭配不同场景，各拍摄五组影像，同时还制作了包含多种样本的混合扫描图。此外，他们还模拟走私分子的藏匿手段开展扫描：用锡纸、衣物包裹样本，或将其藏在儿童玩具内。研究人员还采用威胁图像投射技术，将上述扫描影像叠加到无违禁品的行李 CT 影像中，以此还原走私物藏匿于行李的真实场景。 科研人员用这批影像完成算法训练后，再使用一批从未接触过的影像对算法进行测试。 数据结果 该算法整体识别准确率为 92%：其中鱼翅识别准确率 95%，海马 96%，海参 86% 。算法误报率为 13%，分项数据为：鱼翅 2%、海参 1%、海马 9%。凭借超高的识别精度，这套智能检测算法有望成为打击走私的有力工具，截获大量躲过现有检查手段的走私货物，进而斩断走私链条，让海洋野生动物走私者受到法律制裁。 不过，这套针对特定物种的智能检测系统并非万全之策。海洋走私物种种类繁多，且设备误报情况仍需人工复核。同时，三维 CT 扫描仪造价高昂，并非所有机场都配备，不少机场仍在使用二维扫描设备。因此智能检测系统只会作为现有检查手段的补充，而非替代品。 皮罗塔表示：“我们只能依据过往查获的案例，模拟现实中的走私场景。人工智能并非检测工作的万能良药，也无法取代人工排查与缉私犬的作用。”

最近在使用codex进行优化算法的开发，经常需要跑几十分钟到一个小时的脚本。默认状态下codex经常会在前台跑这个脚本，然后隔几十秒就思考输出一下，十分浪费token。 我现在的做法是强制让codex把脚本放到screen里运行并避免持续监测，但这样做就需要我手动观察进程是否退出，并显式要求codex分析结果，时间上难以拿捏。 所以想请教一下codex有没有hook之类的东西，可以在进程退出后自动发出请求？ 1 个帖子 - 1 位参与者 阅读完整话题

佬友们，我现在是大一，然后我对自己认识很深刻，算法卷不过别人，考公考研不适合我，所以我就准备卷实习找工作 现在我想请教各位佬友，大概什么水平才能达到实习要求？ 我先说我自己的情况 有基础的c/c++/c#语法、算法知识 会用git、github、docker 了解项目开发流程(前端、后端、数据流、协议处理等等) 会操控ai(我自认为用起来还算不错)，制作、使用mcp、skill 然后我的工作流大致如下： 先说明自己的需求(大白话发给ai) 然后让ai对我的需求进行整理归纳并且反问我，形成详细的可执行方案 然后搭建一个让ai能够真实测试的平台(CLI或者MCP) 最后就是TDD，按照方案开发 我的大致情况就是这样，希望能得到各位佬友点评 然后我还想知道如果这个水平不够的话，我还需要学些什么，接触什么？ 34 个帖子 - 20 位参与者 阅读完整话题

想开源tk的x-g x-b 签名算法，不知道能不能发，怕被举报 22 个帖子 - 12 位参与者 阅读完整话题

IT之家 6 月 5 日消息，腾讯混元今日宣布提出 Stem 稀疏注意力算法，已被机器学习顶会 ICML-26 收录。 官方表示，Stem 稀疏注意力算法从“因果信息流”重新审视块级稀疏，用 Token 位置衰减（TPD）和输出感知度量（OAM）两大创新， 仅用 25% 算力就逼近稠密注意力的精度 。配套的 HPC 算子库则将这份理论加速比真正转化为端到端的实测性能。 ▲ Stem 在 Hy3 preview（W8A8-FP8）上更贴近生产环境的真实落地数据 根据 Stem 算法 × HPC 算子的全栈加速方案，算法层面，Stem 通过 Token 位置衰减（TPD）和输出感知度量（OAM）实现 25% 预算下的近无损精度 ；算子层面，HPC 开源的 Stem+BSA 算子将稀疏收益转化为真实硬件加速， 128K 上下文下首字延迟降低 3.6 倍 。 ▲ 模型精度 IT之家附相关链接如下： Stem 论文链接 ： https://arxiv.org/abs/2603.06274Stem 开源地址 ： https://github.com/Tencent/AngelSlimHPC 算子开源地址 ： https://github.com/Tencent/hpc-ops

1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。

1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。

1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。

1. 背景 各位老师好，我们在做一个视频周期动作计数问题。具体场景是：根据游泳视频，统计每个泳者在每一段里的划水次数。 我们有大量“手部出水”检测框、身体框、泳者方向、泳道、泳者身份等原始数据，并且有次数、每次划手开始结束时间的 Ground Truth ，我们的目标是： 从大量有噪声的检测框里，筛出真正对应划水动作的证据，并稳定得到正确的划水次数。 2. 挑战目标和奖金 我们提供原始数据。如果您能提供可复现的方法，在 leave-one-video-out 评估中达到明显提升，我们愿意提供奖金。 当前最好的 offline Baseline 大约是： MAE：3.31 误差不超过 ±1 次的比例：37.6% 误差不超过 ±2 次的比例：58.4% 最大单行误差：15 目标 A：奖金 1500 元 MAE < 1.5 希望误差不超过 ±1 次的比例超过 60% 最大误差小于 5 （非必须） 目标 B：奖金 3000 元 MAE < 1.0 误差不超过 ±1 次的比例超过 80% 最大误差小于 3 （非必须） 3. 数据说明 原始数据： 每个手部检测框的时间戳 手部框位置和大小 身体框位置和大小 手框与身体框的重叠比例 手部中心点是否在身体框内 手部相对身体前后方向的位置 泳者方向 泳道、split/趟、泳者身份 当前系统的 L1 / L2 证据 Ground Truth： 人工标注的每一次真实划水开始和结束时间 每趟每人的划水总数 目前数据集中有 5 个视频、15 次运行、101 行有效评估数据。原始手部检测框约 13.8 万条，其中约 5.8 万条落在真实划水时间窗口里，约 8.0 万条在窗口外。数据、测试代码和说明文件： https://github.com/cbccbcc/external_clean_challenge_20260605 4. 我们目前的算法尝试：L1 / L2 L1 可以理解为对检测框的初步判断： 找到手部出水检测框； 判断手框是否和该泳者身体框有关； 过滤明显像脚或小腿的误检； L2 可以理解为在 L1 基础上，引入了序列维度，作为划手的依据： L1 （经过验证的手在水上）可以看作 1 ，没有则为 0 ，那么一次划手应该是若干 0+若干 1+若干 0 的组合 L2 相较于 L1 数量会更少一些，但是准确率更高一些 我们并不需要局限于这种思路，可以直接从 L1/L2 甚至原始检测框中恢复/预测划手次数。 5. 我们所做的尝试 纯 L1/L2 的估计误差大约在 6-7 ，远无法达到要求。L1 的时间证据比较干净：correctness 约 84.1%，但 true-stroke coverage 只有约 62.3%。核心问题是干净证据召回不够，高召回证据又太脏。 我们尝试了多种方法的节奏恢复算法/差值算法，包括 RANSAC/PROSAC/HMM 等等，并且根据不同特征进行插值，但是结果不尽如人意。 我们尝试了根据现有 L1/L2 的时间差，选取作为节奏的时间差，发现如果能够选取对的时间差，基于 oracle 可以达到 0.8 左右的 MAE ，但是问题在于我们无法从众多时间差中选择这个最佳时间差。 6. 评估规则 使用 leave-one-video-out： 每次用四个视频开发或训练； 剩下一个视频作为测试； 五个视频轮流作为测试集； 汇总五折结果。 要求同一套算法和参数选择流程必须能泛化到所有视频，不能针对单个视频人工调参。 7. 禁止使用的信息 人工标注可以用于训练、分析和调试，但最终算法不能把以下信息作为输入： 当前行真实划水次数； 当前行每一次真实划水的开始/结束时间； 针对某个视频手工指定的规则； 任何生产环境中不会提前知道的信息。 换句话说，temporal ground truth 可以帮助你设计方法，但不能直接喂给最终预测算法。 8. 关于时间对齐 我们发现算法证据整体加上一个小时间偏移后（+0.15s ），会和人工标注窗口更对齐。这个发现说明时间校准可能很重要。 但是最终奖励指标仍然以划水次数为主。我们不会单独因为时间对齐好就认定成功，但我们强烈建议关注时间对齐，因为稳定的时间证据通常更容易得到稳定的计数。 9. 关于交付 您只需要提供算法，初步远程确认没问题后可以咸鱼下单，支付后将算法细节发给我们进行验证，验证达到要求后确认收货。

这一波大量 GPT 用户被封禁（国内外都有），有用家庭 IP 被封的，有使用几个月被封的，有刚充值就被封的。 我昨天上午充值的，今天中午被封了。 这波太疯狂了~~！ 等一个后续

公司：电子行业，制造业，规模还比较大，一年收入百亿+， 薪资：我觉得还行，具体看部门岗位和职级，我是内推我真不知道具体薪资， 强度：双休，日常看情况加班 0~2h ，不同部门岗位不一样， 要求: 本科+，应届和社招都行，人务实一些，要能做事的， 南京,算法 C,matlab, 音频算法，端侧语音算法，信号处理， 东莞, 软件+算法 C#,java 会软件开发+算法 北京/上海, 算法 数据分析, 机器学习, cv, nlp, LLM, agent 能力面广一点，有工业背景最好 青岛,软件开发 c,c++,c#,java,python 要电路方面的知识 注： 我是内推，岗位太多，具体细节我也没办法弄得特别清楚，有兴趣的可以发简历。 还有一些非 IT 的岗位，供应链/生产/工艺/硬件研发/项目经理/部门负责人 之类的，有兴趣也可以联系。 为降低后期沟通成本， 简历请写得清晰朴素一些， 邮件内请写清楚现在的状态，期望 base 地，主要技能，大致期望薪资， 简历上有明显槽点的请附上解释说明（例如短期频繁跳槽，长期 gap ，换岗换行业）， 联系方式， 我的 v2id at 163 邮箱 如果合适我会尽快回复&反馈