这是我最近看到的一个例子 - https://x.com/ycombinator/status/1988366241460089118
最近我发现越来越多这样的无意义的商业模式，而我并不是唯一有这种感觉的人。你怎么看？
返回首页
最新
我不使用名片，更喜欢让人们扫描我手机上的二维码。不过，这里有两个问题：
- 其他人往往会给我名片，结果这些名片堆成一堆，难以区分。
- 当人们扫描我的二维码时，信息会直接进入他们的联系人中，之后再也看不到了。
为了解决这个问题，我创建了netcards。这是一个非常简单的渐进式网页应用（PWA），我和Claude一起编写了代码。工作流程如下：
- 在“我的名片”页面输入你的信息和事件名称并保存。二维码会随之出现。
- 在标签页面设置标签。
- 当人们用手机的应用扫描二维码时，信息会直接进入他们的联系人黑洞，但至少会有一个事件名称和你的所有信息。
- 如果在应用之间扫描，你可以选择标签，之后可以根据事件名称和标签进行筛选。
- 然后你可以分享联系人，为他们生成二维码，或者保存vcards以导入到你的本地联系人应用中。
显然，使用的人越多，这个工具就越有用，所以我想先在HN上分享一下。
技术：
- 原生JavaScript，支持离线的PWA
- 使用IndexedDB进行本地持久化
- 使用jsQR和qrcodejs进行扫描/生成
- Bulma CSS，所有依赖项来自CDN
- 网址：<a href="https://netcards.app" rel="nofollow">https://netcards.app</a>
GitHub: <a href="https://github.com/evronm/net-cards/" rel="nofollow">https://github.com/evronm/net-cards/</a>
我只在我的安卓手机上测试过这个，所以我特别想听听iPhone用户的使用体验。不过，总的来说，我想知道大家是否觉得这个工具有用，以及是否有人有任何建议。
我一直在开发 Fast LiteLLM——一个用于流行的 LiteLLM 库的 Rust 加速层，并且我有一些有趣的经验，可能会引起其他开发者的共鸣，他们也在努力从现有系统中挤出性能。
我的假设是，作为一个 Python 库，LiteLLM 会有很多优化的低垂果实。因此，我开始使用 PyO3 创建一个 Rust 层，以加速性能关键部分：令牌计数、路由、速率限制和连接池。
**方法**
- 使用 tiktoken-rs 构建令牌计数的 Rust 实现
- 添加无锁数据结构 DashMap 以支持并发操作
- 实现异步友好的速率限制
- 创建猴子补丁 shim 以透明地替换 Python 函数
- 添加全面的功能标志以实现安全、渐进的发布
- 开发性能监控以实时跟踪改进
在构建完所有 Rust 加速后，我进行了全面的基准测试，比较了基线 LiteLLM 和经过 shim 处理的版本：
| 功能 | 基线时间 | Shimmed 时间 | 加速比 | 改进 | 状态 |
|---------------------|----------------|------------------|------------|--------------|------------|
| token_counter | 0.000035s | 0.000036s | 0.99x | -0.6% | |
| count_tokens_batch | 0.000001s | 0.000001s | 1.10x | +9.1% | |
| router | 0.001309s | 0.001299s | 1.01x | +0.7% | |
| rate_limiter | 0.000000s | 0.000000s | 1.85x | +45.9% | |
| connection_pool | 0.000000s | 0.000000s | 1.63x | +38.7% | |
结果表明，LiteLLM 已经相当优化！核心的令牌计数几乎没有变化（慢了 0.6%，可能在测量噪声范围内），而最显著的提升来自于更复杂的操作，如速率限制和连接池，Rust 的并发原语在这些方面确实产生了实质性的差异。
**关键收获**
1. 不要假设现有库是低效的——维护者通常对他们的领域非常了解。
2. 关注算法改进而非重新实现——有时候，更好的方法胜过更快的语言。
3. 微基准测试可能会产生误导——现实世界的性能影响差异显著。
4. 最大的收益往往来自复杂部分，而非简单操作。
5. 即使是“适度”的改进在规模上也可能很重要——在高吞吐量应用中，速率限制的 45% 改进是有意义的。
虽然核心的令牌计数几乎没有改善，但速率限制和连接池的提升仍然为高流量用例提供了价值。我构建的基础设施（功能标志、性能监控、安全回退）为未来的优化奠定了坚实的基础。
该项目继续在 GitHub 上以 Fast LiteLLM 的名义进行，欢迎对 Rust-Python 集成模式感兴趣的朋友参与，尽管性能提升让人谦卑。
编辑：为了澄清——token_counter 的负性能可能在测量的噪声范围内，这表明 LiteLLM 的令牌计数已经相当优化。而在速率限制和连接池方面超过 45% 的提升仍然为高吞吐量应用提供了价值。
人工智能正在改变数据库系统。到目前为止，最大的影响可能是自然语言与查询语言之间的转换，即文本到SQL（Text-to-SQL）。然而，另一个巨大的创新正在酝酿中。
我非常兴奋地发布第131期Weaviate播客，嘉宾是麻省理工学院的博士生Matthew Russo！
人工智能为我们的查询语言提供了新的语义操作符。例如，我们都熟悉WHERE过滤器。现在我们有了AI_WHERE，在这个操作中，一个大型语言模型（LLM）或其他人工智能模型可以计算过滤值，而无需它已经在数据库中可用！
```sql
SELECT * FROM podcasts AI_WHERE “Text-to-SQL” in topics
```
语义过滤器只是冰山一角，语义操作符的列表还包括语义连接、映射、排序、分类、分组和聚合等！
而且这还不止于此！关系代数的一个核心思想是查询规划，以及找到应用过滤器的最佳顺序。例如，假设你有两个过滤条件：汽车是红色的，以及汽车是BMW。现在假设数据集中只有100辆BMW，但有50,000辆红色汽车！首先应用BMW过滤器将限制下一个过滤器的数据集大小！
随着大型语言模型的参与，这一基础思想现在有了各种扩展！这个机会催生了新的查询引擎和声明式优化器，如Palimpzest、LOTUS等！
在这个播客中有很多有趣的内容，我很喜欢与Matthew讨论这些话题，希望你也会觉得有趣！
YouTube: https://youtu.be/koPBr9W4qU0
Spotify: https://spotifycreators-web.app.link/e/ddUhVMmLoYb
Medium: https://medium.com/@connorshorten300/semantic-query-engines-with-matthew-russo-weaviate-podcast-131-131a42bbc521
相关内容：<i>更奇特的思考：年度最佳科幻创意</i> - <a href="https://news.ycombinator.com/item?id=45785154">https://news.ycombinator.com/item?id=45785154</a> - 2025年11月（75条评论）