招募兼职 AI 工程师(支持远程,以交付结果为核心,中关村附近最佳)，按结果付费，周期约 1 个月，交付后发放 5000–10000 元（视完成质量而定）

我们工作地点在人民大学附近,优先考虑中关村附近高校,支持远程,最主要的是看交付结果,效果好可继续参与长期合作或转全职

我们已经完成完整的系统概念设计，正在组建核心技术团队，需要你做后端协作，共同完成 Demo 关键模块的工程实现

我们正在打造一款 企业级文档智能化 Demo 产品，聚焦多 Agent 协作、非结构化知识库、智能内容生成。

现招募兼职 AI 工程师(支持远程,以交付结果为核心,中关村附近最佳)，按结果付费，周期约 1 个月，交付后发放 5000–10000 元（视完成质量而定）

我们工作地点在人民大学附近,优先考虑中关村附近高校,支持远程,最主要的是看交付结果,效果好可继续参与长期合作或转全职

我们已经完成完整的系统概念设计，正在组建核心技术团队，需要你做后端协作，共同完成 Demo 关键模块的工程实现

LLM-as-Judge 的 5 个规律, 完全可以用在 Prompt 的思想上, 之前我还是用评分, 下次设计提示词就按照下面的让 LLM 直接做选择, 尤其针对写标题的细分场景

使用成对比较：与其让 LLM 对单个输出进行评分，不如给出两个选项，让它选择更好的那个。这种方式通常能得到更稳定的结果
控制位置偏差：选项的呈现顺序可能会影响 LLM 的决策。为减轻这种偏差，可以对每对选项进行两次比较，并交换选项的顺序
允许平局：有时两个选项可能同样优秀。因此，允许 LLM 声明平局，而不必为了做出选择而勉强决定
控制响应长度：LLMs 往往偏向较长的响应。为减轻这种偏差，确保成对的响应长度相似
使用思维链（Chain-of-Thought）：让 LLM 在给出最终答案之前解释它的决策过程，可以提高评估的可靠性

就目前来看，大模型的总结能力实在不行。之前就觉得GPT的总结能力不太行，因为它的概括性太强，导致关键信息、我最想看到的具体术语和机制介绍等专业细节信息全都没有了

这样的总结一点价值也没有，最终还是得我自己亲自去看

最近我在看一个叫Get笔记软件，它也有一个根据网页链接总结内容的功能。我试了一下，发现总结的内容还是特别少，也就100来字，不会给你总结得特别细，所有的信息细节都会遗漏，还是只有期待图RAG

----------

针对图RAG我写过的文章：
📌 一文搞懂GNN、GAT、GCN | 我看完 11 篇 GNN论文整理的图神经网络入门指南:mp.weixin.qq.com

📌GraphRAG: 知识图谱关系问答,提升 LLM 总结精准性,避免笼统(架构说明+用户反馈): mp.weixin.qq.com

📌阻碍AI知识库生产落地的3大困境, 3 个RAG新框架真能救场?(HippoRAG): mp.weixin.qq.com

看完 Tony Fedall 的书, 再看这篇最近很火的 founder mode 的文章, 就觉得很水, 连作者自己都不知道founder mode是什么, 而且还那么多人去追捧

真正的经过 10 年,20 年失败的经验都在书里

我今天写的这篇文章尝试解答以下3 个问题:

"微调和 RAG,到底选哪个?两者区别"
"有了支持超长上下文窗口的 LLM,是否还需要 RAG "
"目前现实可行, 已经落地的 RAG 优化方案有哪些"

-------

"微调和 RAG,到底选哪个?两者区别"

这个问题在这 2 篇论文中有专门研究: arxiv.org和arxiv.org

结论是: RAG在生成质量上往往优于（有监督/无监督）微调的语言模型,特别是在需要外部知识回答的场景下

其他的比较点:

RAG 不仅在保持高效性能的同时使用更少的算力资源，还具备灵活应对信息检索准确性问题的能力。具体而言，当检索到的信息不准确或有害时，RAG 允许对索引进行调整或替换，而不需要重新训练整个模型

此外，RAG 的模块化设计使得不同的组织可以根据需求使用专属的知识库，避免了将所有数据混合在一个不可解释的黑箱模型中的问题，从而提高了模型的透明度和可定制性。这种架构对企业和研究机构尤其有吸引力，因为它能够更好地管理专有数据和知识

---------
"有了支持超长上下文窗口的 LLM,是否还需要 RAG "

现在支持超长上下文窗口long context LLM（如 10M tokens的 gemini 1.5）的模型已经出现，许多人认为 RAG 已经没有必要，因为可以将数百个文档直接上传给 LLM 进行阅读和处理。

但是，需要考虑以下三个关键问题：

相关性：上传如此多的文档，仍然需要考虑哪些文档与问题最相关，否则容易导致答案偏离

性能影响：上传大量文档对模型性能的影响有多大？模型是否能够高效地处理并回答相关问题？

算力成本：上传过多文档会导致算力成本显著增加，这也是为什么很多 LLM 目前仍然无法支持过多上下文窗口的原因。比如，GPT-4 在处理 30k 汉字内容时可能会出现宕机的情况

对于超长上下文窗口一个有趣的类比是：尽管我们的 RAM 内存足够大，但很多操作仍需在硬盘上进行读写传输，而不是全部存储在 RAM 中

----

第 3 个问题请看文章, 这里不多说

我写的其他 RAG 相关文章:

一手体验AnythingLLM: 总感觉现在的RAG项目徒有其表, 太生硬: mp.weixin.qq.com

阻碍AI知识库生产落地的3大困境, 3 个RAG新框架真能救场?(HippoRAG): mp.weixin.qq.com

微信居然有这个功能，read note

微信订阅号,原来还可以这样看

总是被吐槽用词不准确, 不精确, 原来确实是精确往往比真诚更困难

去年我用GPT 时, 都能把那些网页的几百几千付费文档里的内容套出来呢; 今年都不能直接访问链接, 越狱也很难越狱, 常规提示词更一点用没有

只能把 gpt 的搜索功能当索引用, 具体的内容还得自己点进链接去看, 不能让 GPT 帮你看

安全性做得很好, 除了提示词, 还加了好几套安全过滤机制

怪不得上半年那么多大模型安全的研究