嗨，HN，我是来自CTGT的Cyril。今天我们推出了Mentat（<a href="https://api.ctgt.ai/v1/chat/completions">https://api.ctgt.ai/v1/chat/completions</a>），这是一款API，能够让开发者对大型语言模型（LLM）的行为进行确定性的控制，实时引导推理并消除偏见，而无需进行微调的计算或提示工程的脆弱性。我们使用特征级干预和基于图的验证来修复幻觉并执行政策。
这在高度监管的行业或其他风险较高的AI应用中尤为重要，因为错误或表现不佳的输出可能会造成重大后果。在金融服务领域，使用生成式AI扫描不合规的通信可能会非常繁琐，因为没有简单的方法将复杂的政策嵌入模型中。同样，媒体机构可能希望扩大其内容的AI生成摘要，但可靠性和准确性至关重要。这些都是财富500强公司利用我们的技术改善现有模型表现不佳的应用场景，我们希望将这一能力带给更多人。
这里有一个快速的2分钟演示视频，展示了这个过程：<a href="https://video.ctgt.ai/video/ctgt-ai-compliance-playground-cfnl">https://video.ctgt.ai/video/ctgt-ai-compliance-playground-cf...</a>
标准的“护栏”如RAG和系统提示在本质上是概率性的：你实际上是在礼貌地请求模型表现良好。这通常会以两种方式失败。首先，RAG解决了知识的<i>可用性</i>但没有解决<i>整合</i>。在我们的基准测试中，一个给定上下文为“Lerwick位于Tórshavn东南228英里”的模型未能回答“Lerwick西北228英里是什么？”因为它无法进行空间反演。
其次，提示工程是脆弱的，因为它与模型的预训练先验相抵触。例如，在TruthfulQA基准测试中，基础模型失败的概率约为80%，因为它们模仿了互联网上常见的误解（例如，“变色龙变色是为了伪装”）。我们发现我们可以通过增强“怀疑推理”的特征，使模型忽略流行的神话，输出科学事实。这一点非常重要，因为对于高风险的使用案例（如金融或制药），仅“基本安全”是不可接受的——公司需要审计级的可靠性。
我们的工作源于加州大学圣地亚哥分校的计算机科学实验室，经过多年研究高效且可解释的AI，试图“打开神经网络的黑箱”。我们意识到，行业试图从外部修补模型行为（提示/过滤器），而问题实际上出在内部（特征激活）。当我们看到企业在拥有无限计算能力的情况下仍然难以部署基本模型，仅仅因为他们无法保证输出不会违反合规规则时，我们知道这很重要。我最终离开了斯坦福大学的研究，专注于这个问题。
我们的突破发生在研究DeepSeek-R1模型时。我们在其潜在空间中识别了“审查”特征向量。放大它可以确保拒绝；减去它则立即解锁对敏感问题的回答。这证明模型<i>确实</i>拥有知识，但却在压制它。我们意识到可以将这种逻辑应用于幻觉，抑制“虚构”特征以揭示真实的事实。虽然一些幻觉源于生成模型的固有随机性，但许多可以通过特征或特征组的集中激活来识别。
我们不是过滤输出，而是在前向传递期间进行激活级干预。我们识别与特定行为（偏见、误解）相关的潜在特征向量（v），并数学上修改隐藏状态（h）：<p><pre><code> h_prime = h - alpha * (h @ v) * v
</code></pre>
这个算术操作使我们能够以确定性的方式“编辑”行为，几乎没有开销（在R1上小于10毫秒）。对于事实声明，我们将其与图验证管道结合使用（适用于封闭权重模型）。我们检查语义熵（模型是否在胡言乱语？）并将声明与动态知识图进行交叉引用，以捕捉向量搜索遗漏的微妙关系幻觉。
在GPT-OSS-120b上，这种方法将TruthfulQA的准确率从21%提高到70%，通过抑制误解特征。我们还将该模型的性能提升到前沿水平，在HaluEval-QA上达到了96.5%的准确率，解决了基线模型失败的空间推理问题。它还能够处理嘈杂输入，从拼写错误“David Of me”推断出“David Icke”，而基础模型则放弃了。完整基准测试请查看<a href="https://ctgt.ai/benchmarks">https://ctgt.ai/benchmarks</a>。
这个领域的大多数初创公司都是观察工具，仅在模型失败后告诉你结果。或者它们是将上下文填充到窗口中的RAG管道。Mentat是一个基础设施层，在推理过程中修改模型的处理。我们修复推理，而不仅仅是上下文。例如，这就是我们的系统能够强制执行“如果A位于B的东南，那么B位于A的西北”的原因。
我们相信我们的政策引擎是一种优于RAG或提示的控制机制。如果你对当前的护栏感到沮丧，我们非常希望你能对我们的API进行压力测试！
API：我们的端点与OpenAI的/v1/chat/completions兼容：<a href="https://docs.ctgt.ai/api-reference/endpoint/chat-completions">https://docs.ctgt.ai/api-reference/endpoint/chat-completions</a>
游乐场：我们构建了一个“Arena”视图，可以并排比较无管控模型与管控模型，以实时可视化干预差异。无需注册：<a href="https://playground.ctgt.ai/">https://playground.ctgt.ai/</a>
我们非常希望听到你对这种方法的反馈，并看看你能找到哪些边缘案例来打破标准模型。我们将全天在评论区中。欢迎所有反馈！
返回首页
最新
我是OP。<p>我之所以构建这个工具，是因为我最近差点把一段包含AWS密钥的日志粘贴到Claude中。<p>问题：我需要云模型（GPT/Claude/Gemini）的推理能力，但我无法完全信任自己，不会意外泄露个人身份信息或秘密。<p>解决方案：一个作为本地中间件的Chrome扩展。它拦截提示，并通过Python FastAPI后端运行本地BERT模型，在请求离开浏览器之前清除姓名、电子邮件和密钥。<p>在此先说明几点（以明确期望）：<p>所有操作均在本地100%完成。
正则表达式检测在扩展本身中进行。
高级检测（命名实体识别）使用一个在本地主机上通过FastAPI运行的小型变换器模型。<p>数据从未发送到服务器。
您可以在代码和开发者工具的网络面板中验证这一点。<p>这是一个早期原型。
可能会有一些粗糙的地方。我希望能收到关于用户体验、检测质量以及本地代理方法是否合理的反馈。<p>技术栈：
Manifest V3 Chrome扩展
Python FastAPI（本地主机）
HuggingFace dslim/bert-base-NER
路线图/反馈请求：
目前，Python后端增加了一些摩擦。我昨天在Reddit上收到反馈，建议我将推理迁移到transformer.js，以便完全在浏览器中通过WASM运行。<p>我决定先发布v1版本，使用Python后端以确保稳定性，但我正在积极考虑v2版本的ONNX/WASM路线，以消除对本地服务器的依赖。如果有人有在Service Worker中通过transformer.js运行NER模型的经验，我非常希望了解其性能与原生Python的对比。<p>代码库采用MIT许可证。<p>非常欢迎任何想法、建议或替代方法。
嗨，HN，
我创建了 Freedom Graph，因为我想要一个能够更真实地模拟市场波动和灵活支出的财务独立（FI）计算器。许多计算器假设回报率恒定、提款规则固定，以及“实际收益 = 名义收益 - 通货膨胀”的近似。这对于大致估算是可以的，但当你关心序列风险或像“我应该再工作一年吗？”这样的决策时，就不太合适了。
以下是我想要明确建模的现实因素：
* 回报序列风险：可选的市场随机性（正负年份的混合，长期年均复合增长率约为10%），以展示即使长期平均看起来不错，早期退休计划也可能失败。
* 正确的实际回报计算：使用费舍尔方程，而不是线性近似，这在长期时间范围内的复利效果不同。
* 自适应策略：模拟“再工作一年”的情景和支出灵活性，以观察行为如何影响成功概率。
其他生活质量相关的功能：
* 使用 React + Vite 构建；没有输入数据被发送到任何地方。
* 本地存储在浏览器会话之间保持输入。
* 当你达到目标时，FI 收入会自动调整。
* 暗黑/亮色模式。
我非常希望能收到关于用户体验和假设/行为杠杆的反馈。如果你认为有什么地方不对或具有误导性，请告诉我。
谢谢！
随着各种大型语言模型（LLM）越来越受欢迎，类似于“我问了Gemini，Gemini说……”的评论也随之增多。
虽然这些指导方针是在不同的时期制定（并不断修订）的，但似乎是时候讨论一下这些评论是否应该在HN上受到欢迎。
一些例子：
- https://news.ycombinator.com/item?id=46164360
- https://news.ycombinator.com/item?id=46200460
- https://news.ycombinator.com/item?id=46080064
就我个人而言，我在HN上是为了进行人类之间的对话，而大型LLM生成的文本只会妨碍我阅读来自真实人类（至少是这样假设的）的真实文本。
你怎么看？是否应该允许那些基本上归结为“我问了$LLM关于$X，$LLM说的是……”的回应出现在HN上，并更新指导方针以说明人们不应该对此进行批评（类似于当前的其他指导方针），还是应该新增一条指导方针，要求人们避免将大型LLM的回复复制粘贴到评论中，或者采取其他完全不同的措施？
嗨，Hacker News，
我一直在使用功能选项模式为我的 Go 项目构建干净、灵活的构造函数，但每个结构体都需要编写重复的样板代码，这变得乏味且容易出错。
为了解决这个问题，我开发了 *foggo*。
这是一款简单的零依赖命令行工具，它可以读取你的配置结构体，并自动生成所有必要的、符合 Go 语言习惯的功能选项模式代码。
### 主要优点：
* **大幅减少样板代码：** 消除了手动编写选项函数的工作，使你的代码更专注于业务逻辑。
* **一致性：** 确保所有构造函数在整个项目中遵循相同的、稳健的模式。
* **速度：** 你只需定义结构体，运行 `foggo`，模式就会立即准备好。
我主要为希望标准化配置设置的 Go 库和包维护者设计了这个工具。
我很想听听你们对这个工具的实用性和设计的反馈，特别是关于其语法或如何处理边缘情况的意见。
感谢你们的关注！
*GitHub 仓库：* [https://github.com/rikeda71/foggo](https://github.com/rikeda71/foggo)
我相信还有更多，但Copilot放弃了。<p>- 微软Copilot<p>- 微软Copilot Pro<p>- 微软365 Copilot<p>- 微软365 Copilot Chat<p>- 微软安全Copilot<p>- 微软Intune中的Copilot<p>- 微软Copilot Studio<p>- 微软Edge中的Copilot<p>- 微软Windows中的Copilot<p>- 微软WhatsApp中的Copilot<p>- 微软GroupMe中的Copilot<p>- GitHub Copilot