1作者: D___R___7 天前
我很好奇大家在实践中是如何处理这个问题的。<p>从纸面上看,招聘通常始于明确的标准:技术栈匹配、经验年限、过往职位。但我注意到,很多候选人都能很好地符合职位描述——有时甚至会引导谈话内容以适应描述,但这并非真正的信号。<p>久而久之,我开始看到两个层面: 1. 形式上的匹配——经验、技能、职位契合度(这仍然重要,且必须具备) 2. 人际上的匹配——当事情变得困难时,沟通的感觉如何<p>让我惊讶的是,第二部分在后期往往起着决定性的作用。<p>当优先级发生变化、截止日期延误、范围变更,或者有人需要做超出职位描述范围的工作时——技术上的差距通常是可以解决的。但糟糕的沟通或缺乏信任会带来非常高的成本。<p>所以我想知道: - 在不完全依赖直觉的情况下,您个人是如何评估这方面的人际关系的? - 您是否见过因为沟通问题而导致技术能力很强的候选人失败的案例? - 在面试过程中,您会寻找哪些具体的信号?<p>我更感兴趣的是实用的方法,而不是理论。
1作者: wrathfulspatula7 天前
“Weed” 是一个 AI/ML 库,其风格类似于 vm6502q/qrack(现为 unitaryfoundation/qrack,位于 GitHub)。我编写了(C++)Qrack 量子计算机模拟器框架(现在其 ctypes Python 封装的下载量已超过 250 万次),目的是为了实现绝对最小的依赖性和供应链漏洞攻击面:它仅需要纯粹的语言标准作为最低要求,并可选地使用 OpenCL 或 CUDA 进行(与供应商无关的)硬件加速,以及可选地包含 Boost 库以提高性能。“Weed” 旨在为 AI/ML 推理和反向传播提供与 Qrack 为量子计算提供的相同标准和实用性:永远不会被锁定在硬件供应商处,永远不会因为上游依赖项支持不足而无法在平台上部署,并且让严谨的工程和设计指引出新颖的优化方向,所有这些都通过“透明”的、具有最佳默认用户设置的界面协同工作。
1作者: koistya7 天前
我一直在开发一个名为 Verist 的小型开源项目,想在这里分享一下,希望能得到一些早期的反馈。 在生产环境中,让我一直感到困扰的,并不是如何构建 AI 功能,而是构建完成之后的所有事情:解释事情发生的原因、几周后重现问题,或者在不出现细微错误的情况下更改提示词/模型。 日志记录有所帮助,但还不够。 Agent 框架对我来说感觉过于隐式了。 而且模型升级确实让人害怕,输出结果会发生变化,但却不总是能清楚地知道问题出在哪里,或者为什么会这样。 因此,我最终构建了一个非常小巧、显式的内核,其中每个 AI 步骤都可以被重放、对比和审查。可以把它想象成 AI 决策的 Git 式工作流程,但它不是一个框架,也不是一个运行时。 它不是一个 Agent 框架,不是一个聊天 UI,也不是一个平台,而只是一个专注于显式状态、审计事件、重放和对比的 TypeScript 库。 代码库:<a href="https:&#x2F;&#x2F;github.com&#x2F;verist-ai&#x2F;verist" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;verist-ai&#x2F;verist</a> 我特别想知道,这里是否有人在将 AI 功能部署到生产环境时遇到过类似的问题,或者这是否感觉有点过头了。欢迎提问或提出批评。
1作者: guybedo7 天前
我不明白我们怎么才能避免下周在互联网上发生重大的安全事件或黑客攻击? 我们有成千上万个模式匹配机器人,它们接受过人类知识的训练,也接受过人类行为的训练。这意味着犯罪、黑客攻击等等。 它们掌握了大量的技术知识,它们 24/7 在线,有成千上万个,没有任何监督。它们几乎可以 24/7 扫描互联网上的漏洞。 这将以悲剧收场,嗯,实际上这不会结束,但很快就会出现大问题。