最新

Hi HN， 我开发了 EchoEntry (<a href="https:&#x2F;&#x2F;echoentry.ai" rel="nofollow">https:&#x2F;&#x2F;echoentry.ai</a>) – 这是一个专门针对数字优化的语音转文本 API。 问题：通用的 STT API 在处理数字时表现不佳。“One oh five”有时会被转录成“105”，有时又变成“15”。对于医疗保健应用、仓库系统或 IVR 来说，这种不一致会破坏工作流程。 我的解决方案：在 1-999 的数字上对 Whisper-small 模型进行了微调，涵盖了 5 种英语口音。在 1-3 位数字上，准确率达到 95%。 技术栈： - 自定义 Whisper 模型 (1.7GB) - FastAPI 后端 - 部署在 8GB Linode 上 - FFmpeg 用于音频处理 立即试用（两个命令，无需注册）： # 下载测试音频 curl -O <a href="https:&#x2F;&#x2F;echoentry.ai&#x2F;test_audio.wav" rel="nofollow">https:&#x2F;&#x2F;echoentry.ai&#x2F;test_audio.wav</a> # 测试 API curl -X POST <a href="https:&#x2F;&#x2F;api.echoentry.ai&#x2F;v1&#x2F;transcribe" rel="nofollow">https:&#x2F;&#x2F;api.echoentry.ai&#x2F;v1&#x2F;transcribe</a> \ -H &quot;X-Api-Key: demo_key_12345&quot; \ -F &quot;file=@test_audio.wav;type=audio&#x2F;wav&quot; 目前是免费 Beta 版（每个密钥每月 1,000 次调用）。 正在征求以下方面的反馈： 1. 什么样的准确率门槛能让您认为它适合投入生产？ 2. 我是否遗漏了其他需要大量处理数字的用例？ 3. 您是否愿意为它付费，而不是使用通用的 STT？ 文档：<a href="https:&#x2F;&#x2F;echoentry.ai&#x2F;docs.html" rel="nofollow">https:&#x2F;&#x2F;echoentry.ai&#x2F;docs.html</a> 欢迎就微调过程或部署方面提出技术问题！

我用 Reddit 很久了，注意到对相似帖子的反应很不一致。有时候我会收到积极的反馈和点赞，有时候却会收到很多负面回复，而且没有明显的解释。用了 Reddit 两年，我仍然不理解 Reddit 用户的想法，也不明白这些反应背后的心理机制。

大家好， 我开发了 llm-schema-guard，因为 LLM 在生成 JSON 方面非常出色……直到它们突然不行。即使使用 JSON 模式或函数调用，你仍然会遇到字段缺失、类型错误，或者纯粹是语法错误，这些都会搞垮你的代理、RAG 流程，或者任何工具调用设置。 这是一个轻量级的 Rust HTTP 代理，位于任何与 OpenAI 兼容的 API（比如 Ollama、vLLM、LocalAI、OpenAI 本身、Groq，等等）的前面。它会获取生成的输出，根据你提供的 JSON Schema 进行检查，并且只有在有效的情况下才会放行。 如果无效，严格模式会返回一个干净的 400 错误，并附带详细信息。宽松模式会尝试通过使用修复指令和指数退避来调整提示，并重试几次。 其他一切都保持不变：完全支持流式传输（它会缓冲响应以进行验证），Prometheus 指标，以便你可以监控验证失败、重试、延迟等。配置使用简单的 YAML 文件，用于上游服务、每个模型的模式、速率限制、缓存等。甚至还有一个离线 CLI，如果你只想在本地测试模式。 它使用 Axum 和 Tokio 构建，以实现极低的延迟和高吞吐量，并在底层使用了 jsonschema-rs。Docker compose 使其可以非常简单地与 Ollama 一起启动。 这个项目源于我之前的 schema-gateway 项目，如果大家觉得有用，我很乐意添加 Anthropic 支持、工具调用验证或更好的流式修复等功能。 欢迎点赞或贡献！ 感谢你的关注 :)

我想学习汇编语言，以便在 Apple II 上制作游戏。有哪些关于学习 6502 汇编语言和 Apple II 本身（内存、屏幕管理）的旧书？在学习汇编语言之前，是否绝对有必要先学习 BASIC？

并非所有看起来像经纪商的平台都真正像经纪商一样运作。有些服务可以模拟市场界面，同时在幕后控制报价馈送和执行规则。当这种情况发生时，体验可能更像是参与一个结果被设计的系统，而不是交易。<p>围绕 ZSZRUN 的担忧主要集中在两种在高风险平台中经常出现的的技术模式上：重复的、单方面的滑点和突然的非市场价格飙升。在真实的市场中，滑点通常与波动性、流动性或订单规模有关。它不应该在平静的条件下持续出现，也不应该总是对用户不利。如果您反复下单，发现您的成交价几乎总是比显示的报价差——尤其是在市场稳定的情况下——这是一个有意义的警告信号。这表明执行可能旨在损害交易者，而不是反映真正的市场匹配。<p>第二种模式在图表上更明显。非市场飙升通常表现为尖锐的“针状”影线，它们短暂跳动，触发止损单，然后回落到之前的区间。市场可能存在噪音，但频繁且方便地出现在清算水平附近的极端飙升，很难解释为正常的波动性。如果这些飙升无法在信誉良好的外部图表上得到确认，风险就会更高。真正的市场变动会在多个来源中被观察到；仅在一个平台上存在的价格事件，是该平台可能正在产生自己的内部价格行为的强烈迹象。<p>执行行为通常会强化同样的担忧。一个值得信赖的交易场所应该产生一致、可预测的订单处理。如果盈利平仓被延迟，订单被无故拒绝，或者交易以与图表显示不符的水平成交，该平台可能正在使用后端控制来塑造结果。即使一个平台呈现干净的用户界面和现代图表，缺乏透明的报价来源和可验证的执行规则也是一种结构性风险。<p>如果您怀疑 ZSZRUN 或任何类似平台上存在这些模式，最好的回应是基于证据的验证。比较同一工具在同一时间在多个信誉良好的来源上的价格。记录带有时间戳的任何异常飙升。记录您下单时显示的报价与成交价。单个事件可能是随机的；但重复的、总是损害用户的模式则不然。<p>最重要的是，不要再汇款来“修复”交易问题、解锁提款或解决账户问题。合法的平台不需要额外付款来访问您自己的资金。如果一个平台在您尝试提款或平仓时开始增加新的条件、费用或延迟，请将其视为一个主要的风险信号并退后一步。<p>核心要点很简单：真实的市场是混乱的，但它们不是人为操控的。如果图表行为和执行结果反复看起来像是被设计的，最安全的操作是停止向账户注资，保留您的记录，并依赖透明、可验证的交易场所。

由于 Anthropic 的商标问题，Clawdbot 更名为 Moltbot。<p>Clawdbot → Moltbot Clawd → Molty<p>正如 Clawdbot 的创建者 Peter Steinberger 解释的那样：同样的产品，新的名称。 https://x.com/steipete/status/2016068265391354181