To Rust开发工程师和UI，有一份来自白海科技的offer，请查收

于 2022-04-14 10:31:01 发布
阅读量472 收藏
点赞数
文章标签： 人工智能 大数据 机器学习 rust 求职招聘
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Baihai_IDP/article/details/124165844
版权
白海科技是一家专注于云原生AI基础软件平台的服务商，提供AI开发生产平台IDP。现招聘Rust开发工程师和UI设计师。Rust开发工程师需熟悉Rust，有分布式系统开发经验；UI设计师需有5年以上设计经验，擅长SaaS平台产品设计。公司提供市场竞争力薪资及多重福利。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

一、我们是谁

白海科技是一家云原生AI基础软件平台服务商，核心提供新一代AI开发生产平台IDP (Intelligent Development Platform) 。
白海科技主要服务数据科学家、算法工程师和大数据工程师，为其提供包含易用自研IDE、高性能计算引擎等与一体的AI基础软件，以降低算法开发和利用AI进行数据分析的门槛、提高开发效率、降低AI开发生产成本、提高资源利用率。

白海科技同时致力于帮助企业搭建算法团队和业务分析团队间的桥梁，促进跨团队高效协作，加速企业AI创新

二、 我们的热招岗位

我们正在招募【Rust开发工程师-全职】和【UI-兼职】。

简历投递：hr@baihai.ai ， 应聘UI职位请附作品集哦！

(一） Rust开发工程师（全职）

【职位职责】

1. 参与产品需求讨论、制定技术方案并落地实施，确保项目的进度和质量。

2. 负责产品后端模块和API接口开发。

3. 负责分布式计算系统设计与开发。 4. 负责后端开发文档编写。

【职位要求】

1. 熟悉Rust开发，有Rust开发经验。

2. 编程基础扎实，具备良好的代码编写习惯和结构组织能力。

3. 有较强的学习能力和抽象能力，有强烈的求知欲、好奇心和进取心 ，能及时关注和学习业界最新技术。

4. 熟悉网络编程， 设计和开发分布式系统的经验和能力。

5. 思维敏捷，有较强的钻研学习能力和自我驱动力，较好的沟通和团队合作能力。

6. 有良好的沟通能力和业务理解能力。

7. 对开源分布式调度、计算框架，如 K8s、TensorFlow、PyTorch 等有了解，或者有兴趣深入研究为加分项。

(二）UI（兼职）

【职位职责】

1. 与产品经理、工程师和利益相关者密切合作，为提议的 Web 应用定义产品要求和规范。

2. 为我们的客户优化我们平台的体验，不懈地简化复杂的流程并将其提炼成直观而优雅的 UI。

3. 将功能目标转化为详细的规范。

4. 将您的发现、分析和原型传达给我们的工程师和业务开发团队。

【职位要求】

1. 5年以上设计经验，网页应用程序设计经验，对SaaS平台产品有深入了解。

2. 行业标准设计软件（即 Sketch、Figma、Adobe CS、Invision 或其他 UX 相关工具）的工作知识。

3. 精通主流设计规范，了解最新的用户体验趋势、技术。

4. 对细节的敏锐和特别关注，具有自主工作和团队成员的能力。

5. 出色的口头和书面沟通技巧，能够在不同的受众和组织的不同层次上清晰而有说服力地表达你的设计方法。

三、您将获得

具有市场有竞争力的薪资

创业公司的高成长性

五险一金，补充医疗，餐补等福利统统安排

与各种行业领先大佬面对面，还可以围观大咖们辩论互怼

各种不定期的有趣团建和活动

Baihai IDP
关注
博客
模型蒸馏：“学神”老师教出“学霸”学生
05-21 417
在本文，我们探讨了模型蒸馏（Model Distillation）这一概念，这是一种让结构更简单、规模更小的学生模型复现或逼近结构更复杂的教师模型的性能的技术。我将使用 TensorFlow 和 MNIST 数据集训练教师模型，然后应用模型蒸馏技术训练一个较小的学生模型，使其在保持教师模型性能的同时降低资源需求。模型蒸馏通过让较小的、较简单的模型（学生模型）学习模仿较大的、较复杂的模型（教师模型）的软标签（而非原始标签），使学生模型能以更精简的架构继承教师模型的知识，用更少参数实现相近性能。
博客
写给开发者的“Vibe coding”提示词编写指南
05-19 338
同理，若赋予"安全专家"人设，其生成的代码会重点强化内容输入区的验证、规范认证流程，并预先规避潜在的漏洞风险。当前版本的时间复杂度为 O(n²)，无法满足数据集规模要求，请基于我们其他的数据处理函数使用的归并排序模式，重新生成 O(n log n) 时间复杂度的解决方案”在生成代码的过程中，提示词的设计是否精确，直接决定了模型输出的质量。本文深入探讨了提示词优化的 12 条策略，给出了清晰的操作指南和示范案例，读者可以了解到如何通过精准编写提示词引导模型生成性能优越、符合实际需求的代码。
博客
MCP 协议为何不如你想象的安全？从技术专家视角解读
05-14 1042
对我目前所使用的智能助手和拥有的数据而言，MCP 的核心价值在于：具备流畅的上下文供给能力（无需手动复制粘贴，可根据需求搜索并获取私有上下文）和智能体自主性（能够实现更多端到端的功能，不仅能撰写 LinkedIn 帖子，更能直接发布）。以及 LLM 本身的技术局限，导致在比较复杂的工具组合下性能可能下降而非提升。我认为，这些问题很多都可以通过巧妙的工具设计来解决（例如回传一个带验证功能的确认链接（必须通过用户主动点击才能完成验证的强交互机制）），而非修改 MCP 协议或 LLM 与工具的交互方式。
博客
驳“RAG 已死”论：上下文窗口扩展≠RAG 终结
05-12 842
1）企业私有数据体量远超任何模型的上下文窗口容量；2）模型存在“lost in the middle”问题，难以有效处理长上下文中间部分的信息；3）长上下文处理带来的时间成本和费用开销非常大；4）RAG 架构提供的组件分离设计拥有更高的系统可维护性和问题可追溯性。
博客
MCP 与 A2A 两个 AI Agent 协议的关系和区别是什么？
04-30 1273
本文通过一个规划夏威夷旅行的生动案例，清晰拆解了这两大协议的本质区别：MCP 更像是为单个 AI Agent 赋能的“超能力工具箱”，而 A2A 则是构建了 AI Agent 专家团队间的“协作网络”。"工具"与"智能体"的界限其实很模糊。但问题在于：Claude 是根据过往的数据训练出来的，既不了解实时的天气状况，也无法预测下周的天气。通过统一标准实现"一次开发，通用适配"——任何新开发的工具或智能体都能无缝接入现有生态，不同组件之间就像标准化接口的乐高积木，无需针对特定组合重复开发对接程序。
博客
Google A2A 与 Anthropic MCP 该如何选择？
04-30 336
本文通过一个规划夏威夷旅行的生动案例，清晰拆解了这两大协议的本质区别：MCP 更像是为单个 AI Agent 赋能的“超能力工具箱”，而 A2A 则是构建了 AI Agent 专家团队间的“协作网络”。"工具"与"智能体"的界限其实很模糊。但问题在于：Claude 是根据过往的数据训练出来的，既不了解实时的天气状况，也无法预测下周的天气。通过统一标准实现"一次开发，通用适配"——任何新开发的工具或智能体都能无缝接入现有生态，不同组件之间就像标准化接口的乐高积木，无需针对特定组合重复开发对接程序。
博客
面对开源大模型浪潮，基础模型公司如何持续盈利？
04-25 536
依我看 —— 观点 1（译者注：标准化产品（如 ChatGPT 的聊天框）已能满足多数用户需求）有一定道理，观点 2（译者注：LLM 推理成本的长期下降趋势是真实的）纯属扯淡，观点 3（译者注：若推理成本真能持续下降，订阅模式利润将显著提升）虽有可能但面临重大技术障碍与组织惯性阻力。唯一的风险在于"旗舰模型"可能会因调用量不足而缺乏实战验证 —— 这个隐患可通过在订阅制的聊天界面给用户使用这些“旗舰模型”，但限制用户的模型可使用量来缓解：这样既能收集用户反馈，又能提升平台的活跃度，在产品之间产生协同效应。
博客
GenAI 时代，数据唾手可得，但真正的挑战已经转变...
04-23 671
现在，你只需不到一美分的成本，就能获得高度个性化的、非常详细的答案，这在过去是根本无法实现的。简而言之，大语言模型（LLMs）推动了用户行为的变化（让用户更愿意提问或交互），这种高频使用生成了海量对话数据，而这些数据中天然包含了用户的真实需求和未被满足的痛点。我们分析了这些对话，以期发现文档中的问题和不足，识别产品缺陷，并收集客户在其他反馈渠道没有表达出来的功能需求。我们今天为大家带来的文章，作者的观点是：在生成式 AI 时代，数据从未失去其“黄金属性”，只是淘金（价值挖掘）的方式变了。
博客
「DeepSeek-V3 技术解析」：DeepSeek-V3-Base 预训练阶段解析
04-21 594
然而，由于余弦函数和正弦函数是周期性的，(pos_i, pos_j) 之间的内积可能看起来与 (pos_i, pos_k) 之间的内积相似，因此在固定 θ 的情况下，仅使用 1K tokens（即位置索引 1~1000） 进行预训练的模型在测试时可能会混淆，因为测试时遇到的位置索引（如 5K 或 10K）可能远远超出了预训练时的上下文窗口。由于我们已在前文中讨论过相关内容，此处不再赘述。需特别说明，得益于本系列文章中介绍的各项创新技术，DeepSeek-V3 的优异性能是在极高的训练效率下实现的。
博客
能否将扩散模型思想应用于 LLMs 领域？大型语言扩散模型（LLDM）详解
04-17 611
这一步会产生部分被掩码的 token 序列。该序列被输入模型的核心组件 —— mask predictor（这是一个基于 Transformer 的模型），该模型通过计算掩码 token 上的交叉熵损失，训练其还原被掩码的 token。与预训练类似，我们随机掩码样本中的部分 token，但此次仅掩码响应部分的 token，保留提示词完整。更令人惊喜的是，LLaDA 在逆向推理任务中表现出色，有效解决了自回归模型在“逆向诅咒”上的局限性，甚至在诗歌逆向补全任务中超越了 GPT-4o 和 Qwen 2.5。
博客
LLMs.txt：让大模型更懂你的 Web 文档
04-11 826
然而，它们在处理网站内容时往往受限于有限的上下文窗口，加上 HTML 页面中大量非核心内容的干扰，导致理解效率低下。随后，越来越多的由 Mintlify 托管的文档开始采用这一标准，为 LLMs.txt 的提议创造了一波知名度。与 /llms.txt 仅提供导航视图和文档结构不同，/llms-full.txt 包含了全部的文档内容，这些内容都是用 markdown 编写的。目前，LLMs.txt 提供了一个切实有效的解决方案，帮助 AI 系统更深入地理解和运用网络资源，特别是在技术文档和 API 领域。
博客
「DeepSeek-V3 技术解析」：多词元预测技术（Multi-Token Prediction, MTP）
04-10 1127
此外，该技术可与推测解码（speculative decoding）结合，在推理时，MTP module 并行生成草稿词元，main model 通过单次前向传播验证并修正，凭借 85%-90% 的高接受率实现 1.8 倍的推理加速。在文献 [2] 中，作者尝试通过 MTP 技术预测未来的 2 个词元（token），并将其与推测解码相结合，结果发现第二个词元预测的接受率约为 85%~90%，这表明其 MTP 策略的生成质量稳定可靠。在本实验中，MTP module 在推理时被完全丢弃，因此推理时间无差异。
博客
基于 DeepSeek GRPO 的 1.5B Rust 代码生成模型训练实战
04-07 1070
部分输出示例：https://www.oxen.ai/ox/Rust/file/GRPO_82_2025-03-02_22-49-17_Qwen2.5-Coder-1.5B-Instruct/outputs/GRPO_82_2025-03-02_22-49-17_Qwen2.5-Coder-1.5B-Instruct/cargo_test_rewards.jsonl?需要观察模型在每个奖励维度（如代码编译通过率等）上的改进情况，定期抽查模型接收的提示词（输入）及其生成的代码（输出）。
博客
「DeepSeek-V3 技术解析」：无辅助损失函数的负载均衡
04-02 1442
在混合专家模型（MoE）的实践中，负载不均衡俨然已成为制约模型性能提升的关键瓶颈之一。传统的均衡策略往往需要引入复杂的辅助损失函数，不仅增加了训练的复杂度，还可能干扰模型的核心学习目标。工程师们在提升模型效率的道路上，一直苦苦追寻着一个优雅而高效的平衡解决方案。DeepSeek 团队的这项研究，为这一长期困扰业界的技术难题提供了令人耳目一新的解决思路：通过在门控分数中直接添加专家层面的偏置项，在绝大部分不引入额外损失函数的情况下，实现了模型训练过程中的自适应负载均衡。
博客
为什么大模型在 OCR 任务上表现不佳？
03-28 1217
更令人震惊的是，我们在最新的 SOTA 模型（OpenAI 的 o1、Anthropic 的新版本 3.5 Sonnet 和 Google 的Gemini 2.0 flash）上运行相同测试时，所有模型都会犯完全相同的错误。这些见解来自 Pulse 项目团队的一线实战经验，他们在为大型企业构建数据提取解决方案的过程中，积累了宝贵的第一手资料。当时我们还未曾意识到，在实现这一目标的过程中，会遇到一个障碍，而这个障碍彻底改变了我们对 Pulse 的开发思路。以一个包含“1,234.56”的简单表格单元格为例。
博客
图解「模型上下文协议（MCP）」：从与传统 API 的比较入手
03-26 2986
文章详细介绍了 MCP 的核心架构，包括 Host（提供 AI 交互环境的应用程序）、Client（实现与 MCP Servers 通信）和 Server（提供特定能力和数据访问）三大组件。我们今天带来的这篇文章，作者的核心观点是：MCP 通过标准化通信协议，让 AI 应用与外部工具、数据的交互如同 USB-C 接口一般高效且灵活，彻底改变传统 API 架构的僵化限制。MCP 的核心遵循客户端-服务器（client-server）架构，Host 应用程序可以连接到多个 Server。
博客
「DeepSeek-V3 技术解析」：DeepSeekMoE
03-21 1018
应用更细粒度的专家分割（fine-grained expert segmentation）后，每种菜系所需的技能被拆分给多个专家掌握，于是我们得到一组专精中餐的厨师和另一组专精意大利菜的厨师，每位厨师只需掌握该菜系的特定技能。图3 © 也展示了该策略的实现方式：选定一个专家作为共享专家（绿色高亮标记），所有输入 token 均不经路由层（Router）直接激活该专家，同时将激活的专项专家数量从 4 个减至 3 个，使总激活专家数量与图 3 (b) 保持相同。换言之，路由专家具有更高专业性且冗余度更低。
博客
「DeepSeek-V3 技术解析」：多头潜在注意力机制（MLA）
03-19 854
在每个解码步骤中，仅计算新的查询向量 Q（Query），而缓存中存储的 K（Keys）和 V（Values）会被复用，注意力机制将通过新计算的 Q 与复用的 K、V 进行运算。为了更清晰地理解这一点，来看看使用公式 (7) 计算注意力时的情形：当我们对 q 进行转置并与 k 相乘时，矩阵 W^Q 和 W^{UK} 会出现在中间环节，它们的组合等效于从将 d_c（输入向量的维度）映射到目标维度 d。具体而言，RoPE 会对每个词元（token）的查询向量和键向量应用一个与位置相关的旋转矩阵。
博客
如何高效地为「推理模型」编写最佳提示词？万字长文介绍
03-14 655
作者 | Agustinmantaras编译 | 岳扬OpenAI 的 O1 和 O3-mini 是两款先进的推理模型，与基础版 GPT-4（通常称为 GPT-4o）在提示词处理和答案生成方式上存在明显差异。这些模型通过模拟人类的分析方法，在处理复杂问题时会投入更多时间进行“深度思考”。禁止尝试提取模型的内部推理过程，此类行为违反使用准则。本文将探讨 O1 与 O3-mini 在输入处理、推理能力和响应行为等方面与 GPT-4o 的区别，并阐述优化推理模型性能的提示词工程最佳实践。最后，我们将这些方法论应用
博客
为什么说 JSON 不一定是 LLM 结构化输出的最佳选择？
03-12 683
如前文所述，CSV 格式的挑战在于逗号在数据中较为常见，这可能会导致两种情况：要么是需要更多的 tokens 来处理这些逗号，要么是 LLM 在处理时未能正确进行转义，从而产生错误的数据。因此，如果你的数据可能包含逗号，最好避免使用 CSV，或者设计一个详尽的提示词，并实施有效的评估流程，以便准确衡量其可靠性。我们今天为大家带来的文章中，作者通过实际测试给出建议：在某些场景下，相比广泛使用的 JSON 格式，不妨考虑一下其他数据格式，做一些测试，挑选出既能控制成本又能保证稳定性和速度的最佳选项。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值