最新

我一直在思考一个关于在大型语言模型（LLMs）时代的著作权的哲学和伦理问题，我很好奇HN社区是如何划定界限的。 假设你花了几个月深入研究一个小众话题。你做出了自己的发现，整理了自己的见解，并将所有这些精心策划、非常具体的背景信息输入到一个LLM中。你实际上是在构建一个定制的知识库，并根据你自己的思维框架训练模型。 当你最终想写一篇帖子或评论来分享你的发现时，你概述了自己的具体想法，并利用这个经过精心准备的LLM来构建和生成最终的文本。 我想问你几个问题： 1. 在没有“AI生成”免责声明的情况下发布这些内容是否不道德？ 2. 实际上展示的知识是谁的？LLM生成的是语法，但语义、见解和深层背景信息都是100%人类来源的。 这与使用代笔、编辑或高度先进的编译器根本上有何不同？如果我在进行背景工程和知识发现的重任，限制自己不利用LLM来构建最终输出似乎有些不合理。然而，互联网仍然普遍将任何AI生成的文本视为本质上“非人类”或低投入的。 人类的见解在哪里结束，AI的生成又从何开始？如果核心思想是你的，那么文本的媒介真的就是信息吗？

访问 chrome://flags/#vertical-tabs，然后右键点击你的标签栏，选择“将标签移动到左侧”。

最近在HN上有不少关于伊朗互联网被封锁和Starlink信号被干扰的文章。我想了解一下目前Starlink和其他卫星互联网服务提供商的情况如何。

嗨，HN， 我正在开发 Mumpix，这是一个以本地为先的基础设施栈，用于构建不依赖于集中式云平台的 AI 系统。 我们的目标是让 AI 的记忆、状态和基础设施能够在任何地方运行：手机、浏览器、桌面、服务器或边缘设备。 该栈目前有四个层次： **MumpixDB** 一个为 AI 记忆和应用状态设计的结构化层次数据库。 键的示例： - memory^assistant^context - memory^assistant^recent - workflow^task^42^status **特点：** - 层次化键模型 - 前缀扫描 - 状态变化的观察者 - 确定性快照 - 链接解析 - 基于生成的同步 --- **MumpixFS** 一个文件基础层，旨在与记忆层集成。 处理文件、别名和版本引用。 示例： - files^alias^report - files^versions^report^latest --- **MumpixSL** 系统级运行时和守护进程（mumpixd），通过以下传输方式将栈作为共享基础设施暴露： - Unix 套接字 - REST - WebSocket - D-Bus - Binder（Android） 这使得多个应用程序可以共享一个内存系统。 --- **MumpixFE** 前端运行时，直接在浏览器中运行 MumpixDB，允许相同的记忆模型在客户端工作。 --- **为什么会有这个项目** 目前，大多数 AI 系统严重依赖集中式 API 和基础设施。 这在模型推理方面效果很好，但记忆和应用状态不一定需要存储在云端。 如今，许多代理系统将状态存储在： - 提示 - 向量数据库 - 临时 JSON 数据块 MumpixDB 是一个尝试，旨在构建一个应用程序和代理可以依赖的确定性结构化记忆层。 --- **10 亿美元基础设施资助** 为了鼓励采用，我们还将推出 Mumpix AI 基础设施资助。 我们的想法是逐步分配价值 10 亿美元的基础设施和开发资源给构建以下项目的团队： - AI 代理 - 本地优先的 AI 应用 - 边缘 AI 系统 - 保护隐私的 AI 工具 基础平台将保持免费供开发使用。 --- **欢迎反馈** 这仍处于早期阶段，我希望能从 HN 社区获得关于以下方面的反馈： - 层次化键模型 - 守护进程与进程内使用 - 浏览器运行时（MumpixFE） - AI 代理的集成模式 欢迎提出问题。

我创建了Repovex来解决我在工作中遇到的一个问题：在出现问题之前，没有人真正了解他们的GitHub组织的健康状况。<p>它作为一个GitHub应用程序安装，每晚对您所有的代码库进行检查，并为每个代码库打分，满分为100分。检查内容包括：<p>- 分支保护和必需的审查 - 秘密扫描和启用Dependabot - CI配置、过期的PR、过期的代码库 - README、CODEOWNERS、LICENSE、CONTRIBUTING文件的存在<p>结果会显示在一个网页仪表板上，并在每周的Slack摘要中呈现，这样团队就可以保持关注，而无需主动查找。免费版支持最多5个代码库和每周的电子邮件摘要。<p>欢迎告诉我您希望添加哪些检查内容。