1 分•作者: Abbit•3 天前
返回首页
最新
3 分•作者: kmundy•3 天前
我花了上个月的时间，重建了1970年至2024年的美国联邦预算，以寻找我们财政崩溃的“根本原因”。
数学计算表明，我们没有主权债务危机，我们面临的是定价危机。
我将联邦医疗保健支出分离出来，并将其与CPI + 1.7%的“创新溢价”（以德国作为对照组）的基线进行比较。
研究结果：
联邦医疗保健超额支付导致了我们26万亿美元的国债。
如果没有这种“垄断溢价”，美国的债务今天将仅为9万亿美元。
结构性原因：我将其追溯到1997年的住院医师数量上限（供应冻结）和85%的最低损失率（这使得保险公司变成了成本加成承包商）。
我希望社区对“三重乘数”逻辑（价格 + 创新 + 利率）提出反馈意见。
附注：我目前正在LinkedIn上深入讨论这些数据的政策影响，链接为bit.ly/3YEv6kl
3 分•作者: ethegwo•3 天前
2 分•作者: octave12•3 天前
一个全掌控的云平台，助您更快地部署、管理和交付项目。没有厂商锁定，没有不必要的复杂性——只有对您的部署和工作流程的完全掌控。
19 分•作者: mywork-dev•3 天前
几天前，我发布了 MCPShark（一个用于模型上下文协议的流量检查器）。
我刚刚发布了一个 VS Code / Cursor 扩展，可以直接在编辑器中查看 MCP 流量，这样您就不用在终端、日志和“我认为这是发送的内容”之间来回切换了。
VS Code 市场：
[https://marketplace.visualstudio.com/items?itemName=MCPSharkInspector.mcp-shark-viewer-for-vscode](https://marketplace.visualstudio.com/items?itemName=MCPSharkInspector.mcp-shark-viewer-for-vscode)
主仓库：
[https://github.com/mcp-shark/mcp-shark](https://github.com/mcp-shark/mcp-shark)
功能请求 / 问题：
[https://github.com/mcp-shark/mcp-shark/issues](https://github.com/mcp-shark/mcp-shark/issues)
网站：[https://mcpshark.sh/](https://mcpshark.sh/)
如果您正在构建 MCP 代理/工具：什么能让 MCP 调试真正变得简单——时间线视图、会话分组、差异工具参数、导出跟踪，还是其他什么？如果您能在此处提交功能请求，我将不胜感激：[https://github.com/mcp-shark/mcp-shark/issues](https://github.com/mcp-shark/mcp-shark/issues)
20 分•作者: whatisabcdefgh•3 天前
4 分•作者: ryry•3 天前
嘿，各位 HN 用户！
很久以前，我做了一个火车地图，网址是 trains.fyi。后来我意识到没人买下 planes.fyi 这个域名，所以这是我的新地图项目。
它包含很多东西，但主要是围绕特定机场的 3D 飞机地图，以及以独特方式可视化的天气、ATIS 和其他数据源。
和我做的其他东西一样，它没什么实际用途，但我认为它很酷。如果你喜欢飞机，可以看看 CYYZ/KJFK 地图、天气和跑道标签——我在这上面花了很多功夫。
也欢迎大家提出任何功能请求、问题、评论等等！
40 分•作者: jmsflknr•3 天前
21 分•作者: rajvarkala•3 天前
1 分•作者: thunderbong•3 天前
1 分•作者: gslin•3 天前
3 分•作者: billybuckwheat•3 天前
1 分•作者: maxicohen•3 天前
1 分•作者: f311a•3 天前
1 分•作者: giuliomagnifico•3 天前
1 分•作者: martey•3 天前
1 分•作者: brandonb•3 天前
1 分•作者: matt_d•3 天前
1 分•作者: maguszin•3 天前
2 分•作者: 2dogsanerd•3 天前
过去几个月，我一直在为受监管环境设计一个 RAG 系统。我不是专业开发人员，但我以严格的“系统工程”和审计思维来构建它。
虽然大多数教程止步于“LangChain + VectorDB”，但我发现，要使其在法律上站得住脚并在运营上保持稳定，需要大约 40 多个额外的组件。
我们从一个简单的摄取脚本转移到“多车道共识引擎”（灵感来自六西格玛），因为标准的 OCR/提取对于我们的用例来说，太容易产生幻觉了。
我们不得不构建广泛的审计、细化到文档级别的 RBAC，以及混合图数据库+向量检索，以获得可接受的准确性。
目前的架构包括：
摄取：4 个并行提取车道（视觉、布局、文本、法律），带有一个共识引擎（“Solomon”），该引擎仅索引由多个来源确认的数据
检索：混合 Neo4j（图数据库）+ ChromaDB（向量数据库），采用互易秩融合
性能：语义缓存（Redis），专门用于含义相似的查询（加速 40 倍）
安全性：完整的 RBAC、对每个提示/检索的审计日志记录以及 PII 屏蔽。
我记录了完整的功能列表和差距分析
[https://gist.github.com/2dogsandanerd/2a3d54085b2daaccbb1125601945ceeb](https://gist.github.com/2dogsandanerd/2a3d54085b2daaccbb1125601945ceeb)
我向社区提出的问题是：
看看这个列表——“稳健的生产工程”和“过度工程”之间的界限在哪里？
对于那些从事金融科技/医疗科技 RAG 的人来说：我还在这个列表中遗漏了哪些关键的失效模式？