24小时热榜

自从我开始使用大型语言模型（LLMs）以来，我总有一种想要回到过去、改变历史，然后走上另一条分支的感觉。<p>对我来说，灵光一现的时刻是当谷歌AI工作室开始允许你实际编辑AI的回应时。我意识到，是的，我需要一种多元宇宙的情况来分支我所有的思维流和同一主题的变体。我想要在同一思路上同时尝试Gemini和ChatGPT。<p># 设想<p>Alyph的最初概念可以追溯到2024年。我有一些早期的概念，更多的是科幻风格（如果你查看代码库，会看到像Stargate、Hermes等名称）。<p>我甚至考虑过将其做成3D的，就像全息甲板一样，让你可以访问“行星”主题和内容。但现在的执行方式更为务实。<p># 现在的Alyph<p>Alyph是一个二维画布，你可以在上面并行地向LLMs提问。当你深入某个主题，最终得到答案（无论是代码还是文本）时，你可以提取那个答案，并删除中间所有不必要的来回交流。<p>Alyph还有一个多人模式，你可以和其他人在同一个板上一起进行这样的操作。（见下面的演示板）<p># 背景<p>在我看来，标准聊天用户界面的核心问题是上下文污染。<p>如果你深入了解LLMs的实际工作方式，你会意识到它们没有记忆。它们就像你手机上的一个非常高级的自动补全功能，每发送一条消息时，都会从头重新读取整个聊天记录。<p>这意味着：你所有的错误转折、侮辱（哎呀）、失败的调试循环和糟糕的主题都会随着每条后续消息一起发送。你的完整历史被用来预测未来。当你只想要一个干净的FaqSection.tsx时，这并没有帮助。<p>我注意到，对于更强大的模型来说，提示时的用词选择并不像随之而来的<i>上下文</i>那么重要。至少在我的使用案例中是这样。例如，如果你给LLM一个高质量标准的代码库（完全类型检查、清晰的前端组件、严格的风格指南，使用主流语言），它们往往能非常轻松地生成高质量的内容。<p>此外，如果你给模型<i>过多</i>的上下文，答案往往会退化。例如，Claude在300k-500k个标记下表现出色，但超过这个范围，它的表现可能会迅速下降（而Gemini在我看来在处理大量上下文时表现稍好）。<p>那么你该怎么办呢？目前的主流答案是让算法为你挑选上下文。<p>但是：我强烈认为模型会不断增大上下文窗口——我们最初的消费者模型是32K，现在Grok已经达到了2M。如果我们有100M的上下文，世界会发生怎样的变化？100B呢？<p>这就是我认为（异端！）目前的上下文压缩算法、代理等只是权宜之计的原因。它们在<i>我的</i>案例中并不太有效（因为它们有时会忘记重要的事情并偏离主题，产生杂乱的结果），而且我感觉它们就像一个黑箱，我作为肉体代理在按“接受”或“拒绝”。我是一位遥远的管理者。我不想做一个遥远的管理者。我想深入其中。<p>所以我构建的东西，有人可能会说，是一个过时的手动工具。可以说是手动变速器。我想对我的基线有100%的控制权。我想准确地输入我希望模型看到的内容，进行实验，并将一个文件夹直接放入其中（顺便提一下，Alyph尊重你的`.gitignore`文件，这很不错）。我认为，假设模型最终会允许更大的上下文窗口，手动控制这个基线是很重要的。<p>Alyph当然还有一些粗糙的地方，但这是我爱的成果。我很想分享它，看看它是否真的对其他人有效。<p>如果你讨厌它，告诉我。如果你喜欢它，也请告诉我。我也在寻找合作伙伴，所以请联系我。<p>访问：<a href="https://alyph.ai" rel="nofollow">https://alyph.ai</a>，免费试用。

我在过去几个月里一直在构建 LuffyFiles.com，这是一个现代化的文件共享平台，专注于简洁性和性能。 网站： https://luffyfiles.com/ - 大文件上传 - 不可靠连接的可恢复上传 - 直接下载链接 - 无需等待计时器或下载限速 - 简洁、极简的界面 - 游客上传无需注册账户 - 注册用户的文件管理功能

现在互联网上充斥着太多令人厌烦的臃肿软件。我在尝试构建某个东西时，发现其他人也在做同样的事情，真是让人无语，结果发现那些代码都是由人工智能生成的，而且非常臃肿。我讨厌每一个使用人工智能编写代码的人，不是像我那样只是告诉它该做什么并复制粘贴回应，而是那些因为不会写代码而依赖它的人才是问题所在。我真的觉得我们应该关闭这个该死的互联网，因为这些愚蠢的人。