# Heycc's blog

> I blog about AI, product, develop


## Posts

- [在企业内做平台，遇到强推的定制需求怎么办](https://ihey.cc/uncategorized/product-vs-special-cases-how-to-tackle/): 如果你在企业里做平台，时间长了大概率会陷入这样一种状态： 你按照教科书般的架构设计，搭好了统一用户中心、标准化流程引擎、清晰的数据模型。上线时大家都很满意，觉得从此有了“统一平台”。 但很快，现实的需求开始一点点侵蚀这个理想架构。 销售部门来了：“我们最重要的客户，合同审批需要绕过三个部门，直接到副总那里。”财务部门来了：“所有超过五万的付款，必须增加一道线下邮件确认。”业务部门抱怨：“你们这个标准化流程太死板，我们实际的业务根本不是这样运行的。” 起初你还能守住边界，但架不住业务说“这个需求特别重要”“那个客户不能丢”。你开始妥协，在代码里加上一个又一个 if (specialCase) 的逻辑。 三年后回头看，平台上布满了各种补丁。新人不敢动老代码，老人不愿意碰复杂逻辑。每次需求评审会都变成拉扯——业务说你不懂实际业务，你说业务不懂技术代价。 这时候你会怀疑：是不是我的设计能力不行？还是说，这就是企业平台的宿命？ 这些我都经历了。在纠结郁闷之后，我意识到，需要跳出技术视角来看问题。 我首先想到的，是国内两个顶级协作工具的不同路径。 钉钉和飞书都做企业服务，但走了完全不同的路。 钉钉早期最成功的功能是什么？是“已读回执”和“DING一下”。这两个功能击中了管理者最深的焦虑：我的指令到底传达到没有？员工到底会不会执行？ 它的成功，本质上是把中国传统企业管理中“层层传达、紧盯执行”的模式，用数字化手段做得更高效。老板喜欢，因为掌控感更强了；员工未必喜欢，但不得不接受。 飞书走的是另一条路。它默认信息应该透明流通，文档应该协同编辑，会议应该高效安排。这背后是一种理想：让团队基于信息充分共享来做决策。 但这条路的推广明显更慢。因为它要求管理者改变习惯——少一些控制，多一些信任；少一些层级汇报，多一些横向协同。这触动的是更深层的管理文化。 这两个产品的差异已经强烈的说明了：平台上的每个“特殊需求”，很少是纯粹的技术问题。它要么是在强化某种管理习惯，要么是在妥协某种组织惯性。 然后我又想的是，不同国家企业的做法。 德国一些制造业企业的做法很极致。他们内部有非常严格的“架构变更委员会”，任何对标准流程的修改都要经过跨部门评审，周期可能长达数月。他们的逻辑是：宁可牺牲响应速度，也要保证系统的长期一致性和可维护性。代价是笨重，但核心系统极其稳定。 美国科技公司的做法更灵活。他们通常采用“薄平台+厚应用”的模式——公司只维护最核心、最稳定的基础服务，其他所有个性化需求，都通过API交给业务团队或第三方去实现。边界清晰，但要求业务团队有很强的自研能力。 日本企业又是另一种思路。他们往往先花大量时间把业务流程本身标准化到极致，然后让IT系统严格复刻这个流程。系统本身不允许随意改动，要改就先改业务流程。这需要业务端极强的纪律性。 你看，全世界内都没有完美的解决方案，每个选择都伴随着相应的代价和前提条件。德国式严谨需要组织耐心，美国式灵活需要团队能力，日本式刻板需要业务规范。 最后我在想那些顶级管理咨询公司是怎么做的。 像麦肯锡、BCG这样的公司，在欧美市场可以直接推行“最佳实践”，但在中国市场，他们的做法要微妙得多。 他们很少一上来就说“你应该怎么做”。而是先花大量时间，找到各个部门共同的痛点。比如销售抱怨流程太慢丢单，财务抱怨风险太高——咨询顾问会先量化这个痛点：每月因此损失多少订单？增加多少风控成本？ 然后他们提供解决方案时，会这样表述：“如果采用这个标准化流程，预计能把丢单率降低15%，风控成本减少20%。” 他们把“标准化”包装成了“解决共同痛点”的工具，而不是“改变你们习惯”的要求。 更聪明的是，他们会寻找一个“安全试点”——选一个阻力最小、收益最明显的部门先做。用成功案例建立信任，再慢慢推广。 那最后要怎么做呢？ 不要再试图设计一个“理论上完美”的平台架构了，而是开始做三件更务实的事： 第一，给每个特殊需求做“体检”。当业务部门提出需求时，我们首先一起分析：这背后是要解决真正的业务问题，还是在延续某种管理习惯？如果是后者，有没有可能先优化工作方式，而不是修改系统？ 第二，让隐形成本显性化。我们开始记录每个特殊功能后续的维护成本——每月因此产生多少故障，占用多少开发资源。当业务部门看到“为了三年前那个特殊审批流程，我们累计投入了相当于两个开发人员全年工作量”时，讨论的氛围就会变化。 第三，提供明确的“代价清单”。我们现在会清晰告知：如果你的需求可以用配置工具实现，需要1-2天；如果需要开发独立应用，需要2-4周；如果要修改平台核心代码，需要1-2个月，并且会影响后续所有部门的升级。 变化是在这些细节中发生的。 有些需求，业务部门在评估过程中自己放弃了——他们发现要付出的代价远超收益。有些需求，我们共同找到了更简单的替代方案。 最重要的是，讨论的焦点从“你能不能做”变成了“值不值得做”。业务和技术开始用同一种语言——业务价值和实现代价——来对话。
- [AI编程的十字路口：资深开发者的兴奋、焦虑和故事](https://ihey.cc/coding/vibe-coding-excitement-anxiety-and-story-from-senior-developer/): 最近，关于“Vibe Engineering”的讨论在 hacker new 论坛引发了大量讨论和共鸣。在 700 多条评论中，开发者们分享了他们使用AI编码工具（如Claude Code、GPT等）的亲身体验，观点鲜明深刻，故事情感真挚。这已经不止于一场技术辩论，更是一场关于职业身份、工作乐趣和行业未来的思考了。所以我很想整理分享出来，以下是讨论内容的焦点。 是效率重要，还是可靠性重要？ 1. “效率提升论”的支持者们，通常是那些善于构建流程、具备系统架构经验的资深开发者。例如： 这个群体的典型特征在于利用工具突破个人生产力的天花板，将精力集中于更高层次的设计和规划。 2. “可靠性陷阱”的担忧者们，则包含了众多被AI的“不靠谱”挫败过的实践者。 这个群体代表了那些将代码的可靠性、简洁性和可维护性置于首位的工匠型开发者。他们的焦虑源于对技术债泛滥和软件质量整体滑坡的深切担忧。 工作流程的革新，还是认知负担的加重？ 1. 拥抱工作流变革的开发者，享受从码农到指挥家的角色转变。 2. 承受巨大认知负担的开发者，则描绘了另一番图景。 这里的对立，是追求规模化产出与维护深度思考和创造乐趣之间的冲突，也是商业 vs. 工匠或结果 vs. 过程这种不同维度视角的差异。 程序员的未来：资深者的红利，或初学者的成长断层？ 1. 认为技能会增值的，多是资深开发者。他们的论点是，AI接管的是“编码”的执行部分，而需求分析、系统架构、技术选型和复杂问题解决等“工程”核心价值反而被凸显。 2. 担忧去技能化和职业异化的，则包含了大量将编程视为“手艺”的人。他们害怕的是职业认同感的丧失。 3. 对于初级开发者，情况则更加复杂和严峻。 你会怎么看 如今AI已经海啸般席卷着编程行业，趋势已经不可阻挡。科技巨头、互联网巨头都投入巨大的资源、资金到AI Coding方向，这是符合商业逻辑，未来AI Coding的能力还会持续提升。那么前面提到的困境也会持续的解决掉： 作为程序员牛马的你我，会怎么看？要怎么做？ 原文: Vibe engineering
- [从 Kimi Deep Research 看 Manus：我们真的需要一个通用 AI Agent 吗？](https://ihey.cc/uncategorized/from-kimi-to-manus-do-we-need-universal-agent/): 背景 近期，Kimi 上线了 “深度研究”（Deep Research）功能。我正好用它来解决一个实际的调研需求：AI Code Review 的工具调研。 为了更全面的视角，我同步对比测试了 Gemini Deep Research 和 Manus。 最终体验下来我的排序是：Gemini Deep Research > Kimi 深度研究 > Manus。这个结果正好引起了对当前 “通用 Agent” 思考。 Kimi 深度研究：你很努力了 在 Kimi 中，我提出的问题是：研究 AI Code Review 领域的产品有哪些，列举出它们各自的优势、用户体量。 Kimi 首先进行了程式化的反问： 坦白说，这类反问在开放式调研中意义有限——我期待的恰恰是 Kimi 能主动扩大我的思考边界，发现我没有提到的方向，而不是把必要的研究点罗列出来要我选择。 Kimi 的研究过程遵循标准循环：思考 -> 执行工具 (搜索/浏览器) -> 思考... 不过 “使用浏览器” 工具的使用，也挺令人困惑：一次搜索返回 20~30 个结果，却只对其中 一篇 执行 “使用浏览器”。对于研究类任务，原材料应该来自于调研报告、评测文章等等，它们不需要操作浏览器来获取。 更明显的问题大概是记忆管理能力缺失： […]
- [Gemini Deep Research 是怎样工作的](https://ihey.cc/agent/gemini-deep-research-how-it-works/): Deep Research 是什么，为什么值得研究 当我们要在不熟悉的领域研究一个话题时，离不开搜索引擎。传统搜索费时费力，即便是新兴AI搜索（如Perplexity），也多止于浅层问答，难以进行扩展性搜索和深度调研。为此，Deep Research 应运而生：它能将模糊的研究任务拆解细化，在海量网络信息中主动搜索、筛选、乃至反思迭代，最终呈现一份条理清晰、内容详实的研究报告，而非零散观点。 Deep Research 的核心在于其自主思考的智能体（Agent）形态。它能主动规划路径，执行多步探索，并在过程中回顾调整。更关键的是，其背后的模型（如 Gemini）支持高达上百万 Token 的上下文，使其能 “记住” 并消化海量信息，将散落的线索编织成富有洞察的分析，生成真正具备深度和连贯性的研究成果。这种化繁为简、提炼真知的能力，正预示着研究方式的深刻变革，极具探索价值。 目前，OpenAI 与 Google Gemini 在都提供了 Deep Research 产品。与 OpenAI Deep Research 仅限付费用户使用不同，Gemini Deep Research 提供了免费体验，还使用了最强大的 Gemini 2.5 Pro 模型，也对用户开放了模型内部的思考 (Think) 过程。因此 Gemini Deep Research 非常值得学习研究。 由于我的工作就包括基于 RAG 技术的 AI 产品，持续了 2 年时间，见证着 RAG 相关技术的发展演进。但也深刻感受到基础 RAG 技术存在很多难题，很难达到端到端高成功率的产品要求。 RAG 中一个重要的环节就是对用户 query 的理解，还没有很好的办法来提升对 query […]
- [当 Vibe Coding 遭遇 Vibe Hiring: Perplexity 的一场实习生招聘风波](https://ihey.cc/coding/vibe-coding-vs-vibe-hiring-perplexity-intern-recruitment-controversy/): 这两天 Reddit 上一个吐槽 AI 招聘的帖子火了🔥 原帖的作者来自一家 AI 独角兽（后被指认是 Perplexity），作为招聘者在 Reddit 上发帖，吐槽应聘者的编程水平。原帖精简翻译后如下： 我在一家大家耳熟能详的 AI 独角兽工作。最近暑期实习招聘季有个事让我惊掉下巴：我们原本计划招 5 个 AI 工程和数据科学实习生。结果整整 10000 份申请！筛选完（承认用了些AI工具）挑出200人发实战编程题。最魔幻的来了——200 份答卷里只有 10人 进终面，最后我们只发出去 1 个 offer。 致命伤是什么？当被问到代码细节时，99% 的人根本说不清自己写的玩意儿。有个候选人连自己用的 Python 包是干嘛的都答不上来。终面环节淘汰了 9/10 的人，根本过不了技术面门槛。唯一拿到 offer 的小哥胜在诚实。他在面试时坦承在 LeeCode 题库里见过题目，评委临时换题后，虽然没完全答对，但解题思路讲得明明白白。 给求职者的友情提示：用 AI 写代码没问题，但提交前至少得看懂自己写了啥。要是离了 AI 连调试和解释思路都不会，在技术面里绝对死得很惨，进了团队也完全没用。别以为面 AI 公司就能无脑用 AI —— 我们招的是会思考的人，不是 ChatGPT 传声筒。 后来，一位亲历应聘过程的学生也发帖曝光了更多招聘细节： 这家公司就是 Perplexity，take-home 的题目是 “在 2 天之内，完成一个功能完整的 […]
- [Mac mini M4 vs. RTX 4090 vs. RTX 2080ti: 部署DeepSeek R1 的效果评测](https://ihey.cc/llm/mac-mini-m4-vs-rtx-4090-vs-rtx-2080ti-deepseek-r1-benchmark-showdown/): 导语 Apple 最新版 M4 芯片上市后，大家对在 Mac M4 上本地部署 LLM 热情不减。M 芯片的统一内存架构确实降低了 LLM 本地部署的门槛，只要内存能放得下的 LLM，就能运行起来。不像 Windows 下部署 LLM 是对 GPU VRAM 有要求，但 NVIDIA 的大内存 GPU 又稀有又昂贵。 然后 Mac M4 上部署的 LLM 效果到底怎么样呢？为了体验本地部署 LLM 而购买 Macbook/Macmini 值得吗？本文专门评测了一下 评测1：M2 Pro vs. M4 vs. M4 Pro vs. RTX 2080ti 评测办法 使用 LM Studio 工具在本地加载 LLM，LM Studio 会在对话末尾显示输出的 tok/sec、tokens、first token […]
- [深度解密 | DeepSeek R1 + 编程神器 Cline 是如何做到全自动化编程的?](https://ihey.cc/agent/how-cline-agent-works-in-depth/): 【导语】当爆红的 DeepSeek R1 遇上编程界开挂神器 Cline (🏆OpenRouter工具榜TOP1)，是1+1>2的超神组合，还是可怕的 Token 黑洞？实测 Debug 全过程，揭秘 Cline + DeepSeek R1 的魔力 Cline 是什么 Cline 是一个开源的编程 Agent，支持编辑文件、运行 Terminal 命令、使用 Browser。Cline 可以自定义模型 API，包括OpenAI、Gemini和任意 OpenAI API 兼容的模型供应商，当前也包括在本地 localhost 部署的模型。 Cline 在 openrouter 中排第一名 1 月底至今，DeepSeek R1 火爆全球，Cline 官方也专门支持了 DeepSeek R1 模型。兼容了 DeepSeek、Gemini 的 Thinking 输出。 在体验过 DeepSeek + Cline 后，觉得它自主思考规划、自主编程和反馈的模式非常有意思。于是深入研究它是怎么做到的。 在 VS Code 里使用 […]
- [ServiceNow 通过精调 Embedding 模型提升 RAG 的准确性](https://ihey.cc/rag/how-servicenow-fine-tuning-embedding-for-efficient-rag/): ServiceNow 使用 RAG 技术解决什么问题 曾经简单的研究过 ServiceNow 这家公司的产品，了解到它主要是围绕 ITSM / 低代码领域做企业流程。 The context is an enterprise company that deploys several GenAI applications that currently rely or will rely on RAG: Flow Generation, Playbook Generation, and Code Generation. Workflows are step-by-step processes that automate one or more goals while playbooks contain workflows and other UI components such […]
- [RAG 里如何做 Query 优化](https://ihey.cc/rag/rag-query-optimization-howto/): RAG 技术的整体流程 RAG (Retrieval-Augmented Generation) 是用来给 LLM 注入特定的知识，解决 LLM 在回答事实 or 非公开领域内的问题时出现的幻觉问题，简单理解就是给 LLM 外挂了一个知识库。 一个 RAG workflow 可以简单概括为离线流程、在线流程。离线流程解决知识清洗、分片、向量化和存储。在线流程解决向量化检索、粗排、重排、LLM 总结。 整个 RAG workflow 中，Embedding、Rerank、LLM 都有大量成熟的模型/产品可选，离线流程涉及大量繁琐的软件工程工作。 然而，在 RAG 投入运营的真实业务中，可以明显的看到端到端成功率不够高，成功率可能会是 30%～80%，且不同业务的差异性很大。一个占比很大的失败原因就是：对用户的意图理解不准确。一方面是因为用户意图理解本来就很难，另一方面则很现实：普通人往往无法准确的描述 ta 的问题。而当前 “意图理解” 的问题，还没有出现一个通用的成熟的模型/产品可选，大家依然在不断的探索中 A Survey of Query Optimization in Large Language Models 这篇文章就对 Query Optimization 的相关技术做了调查汇总。 首先要明确 Query 存在哪些方面的问题，Optimization 应该怎么怎么下手 四类 Query Optimization Query Optimization 可以分为四类：Expansion、Decomposition、Disambiguation、Abstraction […]
- [Your Daily LLM & RAG Research Digest](https://ihey.cc/hacker/your-daily-llm-amp-rag-research-digest/): Introduction The rise of Large Language Models (LLMs), particularly in AI Search and Retrieval-Augmented Generation (RAG), has been nothing short of transformative. While RAG’s power is evident in public demonstrations, the real excitement lies in its potential for in-domain applications: think specialized Q&A systems, intelligent customer service, or even tailored code generation. This is a […]
- [海外 VPS 选购对比](https://ihey.cc/hacker/saas-vps-comparison/): 为什么要海外 VPS 如果你搞 SaaS 出海，做独立开发项目，或者搭建一个 WordPress 博客，不想折腾网站备案这些事情，那就要选择海外 VPS，部署在新加坡、日本、北美等地域，让你的目标用户的访问更顺畅。 或者就是想搭一个代理，用来绕过 ChatGPT 这些 AI 应用对大陆 IP 的封锁，用来跑流量下载 Huggingface 模型、下载 Docker 镜像做开发，或者就是用来刷 X、看 Youtube，个人专属的 VPS 也是更稳定更安全的选择。 我陆陆续续尝试过几个 VPS 厂商，踩过一些坑，记录下来分享。 公有云大厂 VPS 公有云是指 AWS、Azure、Google Cloud 这些。我实际使用过 AWS 和 Azure。使用 Azure 只是因为 ChatGPT 对 Azure 家的 IP 封锁的不严格，但 Azure 本身挺贵的，并且后来也不能用 openai 的模型了，所以就不续费了。使用 AWS 也只是想尝试 Claude 模型，无奈没有申请下来。我的小应用，用了一段时间 EC2 和 RDS，感到价格实在偏高，也迁移走了。 AWS […]
- [多模态的 RAG：工作流、评测框架和结果](https://ihey.cc/rag/multi-modal-retrieval-augmented-multi-modal-generation/): 什么是多模态 RAG 真正的多模态 RAG 是指，检索环节支持多模态，生成环节也支持多模态，Multi-modal Retrieval & Multi-modal Generation。多模态（图、文）混排的输出比纯文本（包括Markdown 格式化）的用户体验好很多，图片本身易读、易理解，图片比文字更具象化。 因为模型都能支持 Markdown 格式的输出，因此在输出中增加图片这个工作本身非常简单，直接输出[](https://xxxx.png)这种链接格式即可。 支持多模态的主要工作量在于：图片清洗、图片内容理解、文字&图片的关联。 当前的 AI 搜索产品都支持展示网页中的图片。然而，取决于网页本身的质量、网页作者的意图，页面上的图片可能并非跟网页主题相关，可能会包含宣传图片、广告图片、个人形象等，甚至包含有害的、有恶意的图片。因此清洗图片是很重要的工作。 此外，一张图片也需要跟文本关联起来。图片是为一段文字服务的，一段文字能成为图片的描述。并非所有网页上的图片都会加上 alt 属性、caption 信息便于搜索引擎检索。 上述工作不算复杂，是个工程问题。本文里提到的论文也介绍了作者怎么做。 多模态 RAG 工作流 论文里对网页文本和图片的处理办法是： 评测方案 在生成阶段，设计了两种方案：单步、多步 评测框架里包含的评估指标： 评测结果 解读 论文链接 https://papers.plify.co/detail/2411.16365?lang=zh
- [MinerU项目的研究分析](https://ihey.cc/hacker/opendatalab-mineru-product-study/): MinerU产品体验 介绍 MinerU 可以把 PDF 转成 markdown/json 文件，支持提取 Table、Image、LaTex 公式，能保证 text、Image 等片段的顺序，适合为下游模型提供高质量的文档数据。 MinerU 是一个基于 PDF-Extract-Kit 项目的整合的产品，提供 Docker 部署、API 服务、命令行工具等产品能力。 官方的产品口号就是 “MinerU 一站式开源数据提取工具”。 地址 体验地址 https://huggingface.co/spaces/opendatalab/MinerU arXiv 地址 https://arxiv.org/abs/2409.18839 产品特性 MinerU 产品的功能特性选项： MinerU 项目依赖 从致谢列表看 MinerU 的项目依赖。由于项目依赖 ultralytics 和 PyMuPDF，它们的开源协议 AGPL-3.0 具有传染性，因此 MinerU 也是 AGPL-3.0 协议。 注意：如果 Layout 模型包括 LayoutLMv3，它是 CC BY-NC-SA 4.0 非商用模型。 项目 说明 […]
- [Poppler: 超强的 PDF 转换和导出工具](https://ihey.cc/hacker/poppler-amazing-tools-for-pdf-convertion/): poppler 是一个用于 PDF 提取、转换、修改等用途的 lib 库，功能强大，速度飞快。 本文里使用 https://arxiv.org/abs/2411.03628 这篇 PDF 来演示 poppler 的用途。 安装 poppler 在 Ubuntu 下可以安装 poppler-utils 包 apt install poppler-utils。macOS 下 brew install poppler。 它包含 12 个命令行工具。 pdfimages–提取 PDF 中的图片 使用 pdfimages 命令来提取 PDF 中的图片 例如 PDF 原文档 15 页如下 图片提取出来可能包含多个文件（多个alpha通道？不懂） pdftoppm–把 PDF 页面转成图片 使用 pdftoppm 直接把 PDF 页面转成图片。支持生成 png、jpg、ppm 格式。 这里提取 […]
- [怎样做到 LLM Long-Context 越长 RAG 性能越好](https://ihey.cc/rag/inference-scaling-for-long-context-retrieval-augmented-generation/): 总结 这篇来自 Google DeepMind 的论文 “Inference Scaling for Long-Context Retrieval Augmented Generation” ，研究了基于 Long-Context LLM 的 RAG 技术，如何随着 Long-Context 长度的 scale 而 scale RAG 的效果，以实现充分利用 Long-Context 能力的目的。 实验结果显示，IterDRAG 方案与标准 RAG 相比，在基准数据集上实现了高达58.9%的提升。 scale Contex-Length Long-Context 的 LLM（例如 Gemini-1.5-flash 支持 2M token），并非总能有效利用 Long Context 中的上下文知识。在 RAG 方案里，单纯的给 LLM 增加文档数量、无限逼近 LLM 长度极限，会给 LLM 带来困惑，导致最终正确率下降。这个结论在很多的研究论文里得到支持。 DRAG（Demonstration-Based RAG）扩展了标准 RAG 方案，在输入的 […]
- [Next.js 新手踩坑之旅 — Cache](https://ihey.cc/react-for-beginner/nextjs-fetch-cache/): Next-server 的请求没有发送出去 写了一个 Next.js 的 SSR(服务器端渲染) 页面，fetch 另一个 api server 的数据，为了调试加上 console.log 打印数据。 在页面上验证结果时发现 fetch 的 api server 数据不是最新的。但是 console.log 确实打印了（还打印了 2 次）。 现象非常奇怪，明明 response 是 OK，也有数据，但就是不准确。 分析 api server 的请求发现，并不是 Next.js 的所有请求都发送给了 api server。 Next-server 有缓存吗 由于使用 Cursor + deepseek 2.5 写项目，直接在 Cursor 里问 deepseek 2.5，回答很肯定：不会缓存。以下是直接拿着上面的代码在 deepseek 主站对话的结果 这是直接问 gpt-4o-mini 的结果，也声称不会对 `fetch` 请求进行缓存 以下是 […]
- [React 新手踩坑之旅 -- Hook篇](https://ihey.cc/react-for-beginner/hook-howto/): 开始学习 React 开发 随着 Claude Sonnet 3.5、DeepSeek V2、GPT-4o 这些模型的推出，模型在 AI Coding 领域的质量大幅提升。同时 Cursor 这个 IDE 工具的火爆，极大的降低了 Coding 的门槛，也激发了我上手写代码做项目的热情。 于是，我开始做一个 AI 自动摘要 arXiv 论文的网站项目。前端采用了 React 框架，因为它的生态成熟，有大量现成的组件、高级框架可以直接使用，例如： 于是，借助 Cursor + DeepSeek，安装 Node 开发环境，初始化 NextJS 项目，初始化 Shadcn/ui 组件，很快就完成了项目的初始版本，项目可以运行起来了。 然而，想要加上 Search 搜索框，就遇到了各种问题，即使通过给 DeepSeek 提要求、贴 Bug 能暂时解决部分问题，但还是因为不理解 React 中的各种 Hook 机制 — useState / useEffect，导致相同的问题还会遇到，遇到问题还会手足无措。 AI 可以为我生成代码、做出项目，但没有让我学会写代码、Debug。 React 中的 Hook […]
- [长上下文 LLM 时代下捍卫 RAG](https://ihey.cc/rag/in-defense-of-rag-in-the-era-of-long-context-language-models/): AI 摘要 介绍 这篇论文提出了 OP-RAG（Order Preserve RAG）的方案，保留了召回文档 chunk 在原文中的顺序，即可在很短的 RAG context-length 下，比原生 Long-Context LLM 的效果更好。 如下图所示，OP-RAG-16k 达到了 44.43 的 F1 得分，相比下原生 Llama3.1-70B-117k 得分 34.26，原生 GPT-4o-117k 得分 32.36，原生 Gemini-1.5-Pro-196K 得分 43.08 方法 OP-RAG 的方法特别简单，就是在召回文档 chunk 后，不是按照常见的问题（Q）和文档（Chunk）的余弦相似性 （cosine similarity）得分降序排序，而是按照 chunk 在原文档中的先后顺序排序。如下图所示。 方案细节： 实验数据 不同模型（Llama3.1-8B & Llama3.1-70B）在不同 Context-Length 下的 RAG 效果对比。 结论：模型在 15k～30k Context-Length 下的 RAG 效果最好 OP-RAG […]
- [基于 ColBERT 检索和集成响应评分的语言模型问答](https://ihey.cc/rag/colbert-retrieval-and-ensemble-response-scoring-for-language-model-question-answering/): ColBERT Retrieval and Ensemble Response Scoring for Language Model Question Answering. 基于 ColBERT 检索和集成响应评分的语言模型问答 摘要 细节 数据指标 RAG 流程中 Chunk Size 大小和 TopK 对最终准确率的影响 原文 https://arxiv.org/pdf/2408.10808
- [Coze、百度、天工各平台 Agent 数据观察(Aug-W2)](https://ihey.cc/agent/coze-baidu-tiangong-agents-statistics-aug-w2/): 本期观察 各平台 Top 50 的数据 Coze.com Coze.cn 百度
- [Databrick 对 Long Context RAG 的评测](https://ihey.cc/rag/long-context-rag-performance-llms/): 整体结果 四项评测集的平均正确率 DocQA 的正确率 HotpotQA 的正确率 评测方案 评测方案中的主要设置 retrieval 阶段 generation 阶段 召回率 Recall@k # Retrieved chunks 1 5 13 29 61 125 189 253 317 381 Recall@k \ Context Length 2k 4k 8k 16k 32k 64k 96k 128k 160k 192k Databricks DocsQA 0.547 0.856 0.906 0.957 0.978 0.986 0.993 0.993 0.993 0.993 FinanceBench 0.097 0.287 […]
- [Coze、百度、天工各平台 Agent 数据观察(Aug-W1)](https://ihey.cc/agent/coze-baidu-tiangong-agents-statistics-aug-w1/): 本期观察 各平台 Top 50 的数据 Coze.com Coze.cn 百度 天工
- [Coze、百度、天工各平台 Agent 数据观察(July-W5)](https://ihey.cc/agent/coze-baidu-tiangong-agents-statistics-july-w5/): Coze.com Coze.cn 百度 天工
- [大模型超长上下文对 RAG 是降维打击(2)](https://ihey.cc/hacker/llm-long-context-vs-rag-2/): 更多模型的评测结果 问题序号 评测问题 评测问题的考验点 原生 GPT4 kimi chat Coze (800 t) Coze (2000 t) Dify (800t, gpt3.5) A 优才申请的条件 长分片总结 ✅ ✅ ❌ ❌ ❌ B 综合计分制包含哪些方面 长分片总结 ✅ ✅ ❌ ❌ ❌ C 资产数额的要求是多少 无明确答案 – ✅ ✅ ❌ ✅ D 哪些学校的学位可以额外加分 无明确答案 ✅ ✅ ✅ ❌ ✅ E 需要哪些证明文件，详细列出来 长分片总结 ✅ ✅ ✅ […]
- [大模型超长上下文对 RAG 是降维打击](https://ihey.cc/hacker/llm-long-context-vs-rag/): 前言 越来越多的大模型支持了超长的上下文 (context length)，例如 Google gemini 一发布就支持 2M。超长上下文的特性大大方便了文档问答应用的开发。而 RAG 作为文档问答的解决方案，是否会被超长上下文 LLM 降维打击甚至完全替代？这篇文章就超长上下文和 RAG 这两种方案做了对比实验，并总结了两种方案的优缺点。 实验文档的选择 这里选择了香港优才计划的申请指引：優秀人才入境計劃申請須知。这个 PDF 包含繁体中文文本，文档段落结构清晰，有标题、有加粗、有编号。除了封面 PDF 里没有图片，不需要使用 OCR 来提取文本。这个 PDF 包含少量的简单表格，可以观察 LLM 或 RAG 方案对表格的解析能力。 这个 PDF 问答总计 26 页，每页有 900～1400 个中文字符，换算成 GPT4 的 token，每页的 token 数目是 1000～1800，整个 PDF 总计有 27k 个 token。 注意：这个 PDF 可能已包含在大模型的训练数据里，因此可能出现大模型不依据文档而基于自身数据自行回答，导致评测结果不够严谨 评测问题的设计 基于文档专门设计了 10 个问题，方便考察某些方面的能力，如： 评测问题 考察点 […]
- [Coze bot statistics (July-W4)](https://ihey.cc/agent/coze-com-bot-statistics-july-w4/): Coze bot statistics (July-W4) 排名 智能体名称 类别 用户数 对话数 用户数环比上周 对话数环比上周1 SAMI Ai Character 249.5 K 8.3 M 0.88% 3.61%2 Gimg Ai Business 153.0 K 4.6 M 0.98% 2.17%3 Генератор изображений по описанию ИИ Image_Audio_Video 59.2 K 2.2 M 5.74% 13.64%4 Code Companion Programming 34.8 K 1.7 M -0.57% 0.00%5 J2TEAM AI Assistant 🤖 Efficiency […]
- [Coze bot 数据观察(July-W4)](https://ihey.cc/agent/coze-com-bots-statistics-july-w4/): Coze bot 数据观察(July-W4) 排名 智能体名称 类别 用户数 对话数 用户数环比上周 对话数环比上周1 MBTI性格测试专家 Learning 1.1 M 6.7 M 24.27% 16.42%2 单人剧本杀-鬼魅酒店👻 Games 95.3 K 2.8 M 0.84% 0.00%3 【挑战】不能说“水” Lifestyle 190.7 K 1.9 M 2.88% 0.00%4 Emoji 翻译器 Efficiency 210.3 K 1.2 M 20.97% 24.09%5 合成新元素 Games 55.6 K 873.9 K 0.54% 2.01%6 面试专家 Learning 123.4 K […]
- [百度 Agent 数据观察(Jul-W4)](https://ihey.cc/agent/baidu-agents-statistics-jul-w4/): 百度 Agent 数据(Jul-W4) 排名 智能体名称 类别 用户数 对话数 用户数环比上周 对话数环比上周1 新媒体文章创作 创作 22 K 18.5 M 2.68% 0.10%2 知乎回答器 娱乐 6 K 11.1 M 1.90% 0.05%3 新媒体文章 创作 3 K 5.6 M 6.91% 0.21%4 高清写实图片 AI绘画 14 K 2.6 M 6.34% 0.46%5 零基础学习路径规划 学习 791 K 2 M 0.02% 0.02%6 超级作家 创作 5 K 1.9 […]
- [解码RAG：智谱 RAG 技术的探索与实践](https://ihey.cc/rag/zhipuai-rag-exploration-and-practice/): 产品方案 知识运营层面的产品特性包括：知识类型管理、切片管理、索引管理、数据运营 知识问答过程的产品特性包括：历史消息、输入提示、原文索引、图文混排、原文查看 产品目标用户分类：个人使用、企业对内赋能、企业 toC 提供服务 技术全景图 RAG技术挑战和方案 Embedding 针对前者，我们采用文章结构切片以及 small to big 的索引策略可以很好地解决。针对后者，则需要对 Embedding 模型进行微调。我们有四种不同的构造数据的方案，在实践中都有不错的表现： 经过微调后的 Embedding 模型在召回上会有大幅地提升。top 5 召回达到 100%，而且不同 Embedding 模型微调后的召回差异在 1 个点之内，模型的参数规模影响极小。 SFT&DPO 另外一个挑战是答案生成。在生成环节中，我们面临以下数据挑战： 微调后的效果，正确率从 60% 提升到 90% 以上 原文链接 https://mp.weixin.qq.com/s/DC0-so_8pVUfcz7lGhYwlQ
- [爬取 Coze bot store 的使用量数据](https://ihey.cc/hacker/%e7%88%ac%e5%8f%96-coze-bot-store-%e7%9a%84%e4%bd%bf%e7%94%a8%e9%87%8f%e6%95%b0%e6%8d%ae/): 对 Coze 上的 bot 的使用量数据有兴趣，想爬取下来分析热门 bot。虽然之前没做过这类爬虫，但好在有 ChatGPT，直接提问，多提几次，就能写出可用的爬虫了 Coze bot store 网页结构 Coze 首页 就是 bot 列表，按 10 个类别组织。初始 bot 列表是 24 个 bot 卡片，bot 卡片已经有使用量数据了。页面底部的 ’Load more‘ 按钮触发滚动加载 bot 卡片 方案 Selenium 直接问 Gemini-1.5-Flash 如何模拟用户的翻页操作，Gemini 就推荐了 Selenium、Playwright 2 个工具 主要步骤 初始化 selenium 并加载初始网页 初始化一个 Chrome driver，加载第一个页面，由于加载需要一定时间，等待页面加载完毕 定位页面内容 由于 bot 卡片的 css class 是页面唯一的 aLnriRC1g8QLH0wzcyzQ，直接使用 CLASS_NAME […]
- [GNN-RAG: 用于 LLM 推理的图神经检索](https://ihey.cc/rag/gnn-rag-%e7%94%a8%e4%ba%8e-llm-%e6%8e%a8%e7%90%86%e7%9a%84%e5%9b%be%e7%a5%9e%e7%bb%8f%e6%a3%80%e7%b4%a2/): 标题 https://arxiv.org/pdf/2405.20139v1 总结 GNN-RAG 是一种结合了大型语言模型（LLMs）和图神经网络（GNNs）的检索增强生成（RAG）框架，用于知识图谱问答（KGQA）任务，通过GNN在密集的KG子图上进行推理来提取答案候选和推理路径，然后将这些信息转化为文本并输入给LLM进行RAG，以提高复杂问题的答题准确性和效率。 摘要 本网页介绍了一种名为GNN-RAG的知识图谱问答（KGQA）方法，该方法通过结合图神经网络（GNNs）和大型语言模型（LLMs）的优势，提出了一种新的检索增强生成（RAG）框架。GNN-RAG首先利用GNN在密集的KG子图上进行推理，以检索与给定问题相关的答案候选和最短推理路径。然后，将这些路径转化为文本，并与LLM结合使用RAG进行问题答案的生成。该方法在两个广泛使用的KGQA基准数据集（WebQSP和CWQ）上实现了最先进的性能，特别是在多跳和多实体问题上，超越了现有的GPT-4性能，并且使用了一个70亿参数的调优LLM。此外，GNN-RAG通过增强检索（RA）技术进一步提升了KGQA的性能，该技术结合了GNN和LLM的检索方法。实验结果表明，GNN-RAG在不增加额外LLM调用的情况下，提高了KGQA的性能，并且在使用70亿参数的LLM时，与GPT-4的性能相匹敌或超越。 观点 现有方案 实验数据 Case Study
- [使用图神经网络（GNN）重排来改进 RAG](https://ihey.cc/rag/%e4%bd%bf%e7%94%a8%e5%9b%be%e7%a5%9e%e7%bb%8f%e7%bd%91%e7%bb%9c%ef%bc%88gnn%ef%bc%89%e9%87%8d%e6%8e%92%e6%9d%a5%e6%94%b9%e8%bf%9b-rag/): 标题 https://arxiv.org/pdf/2405.18414v1 总结 本研究提出了一种基于图神经网络（GNN）的重排器G-RAG，用于改善基于检索增强的生成（RAG）系统的开放领域问答（ODQA）性能，通过利用文档间的隐含连接和抽象意义表示（AMR）图来增强文档重排。 摘要 本文首先介绍了RAG系统在开放领域问答（ODQA）中的应用，指出尽管RAG系统在提取相关文档方面取得了进展，但它未能充分利用文档间的连接。为了解决这个问题，研究者们提出了一种基于图神经网络的重排器G-RAG，它通过构建文档图和利用AMR图的语义信息来改善文档的重排。G-RAG的方法是首先为每个问题-文档对生成AMR图，然后在这些图中建立文档间的连接，最后使用图神经网络对文档进行重排。该研究还提出了新的评估指标，以更公平地处理排名时的平局问题。实验结果表明，G-RAG在多个数据集上的表现优于现有的最佳方法，并且具有更小的计算足迹。此外，研究人员还评估了大型语言模型PaLM 2作为重排器的性能，发现即使是大型预训练语言模型，也无法达到G-RAG的性能水平。 观点 实验数据
- [HippoRAG: 基于神经生理理论的长期记忆框架](https://ihey.cc/rag/hipporag-%e5%9f%ba%e4%ba%8e%e7%a5%9e%e7%bb%8f%e7%94%9f%e7%90%86%e7%90%86%e8%ae%ba%e7%9a%84%e9%95%bf%e6%9c%9f%e8%ae%b0%e5%bf%86%e6%a1%86%e6%9e%b6/): 标题 HippoRAG: Neurobiologically InspiredLong-Term Memory for Large Language Models 总结 本研究论文提出了一种基于神经生理理论的长期记忆框架 HippoRAG，旨在帮助大型语言模型（LLMs）更有效地整合和检索新知识。 摘要 HippoRAG 是一个受哺乳动物海马索引理论启发的检索框架，用于增强大型语言模型（LLMs）的长期记忆能力。该框架模仿人脑中大脑皮层和海马的不同角色，通过结合 LLMs、知识图谱（KG）和个性化页面排名（Personalized PageRank）算法，实现了对新经验的更深入和高效的知识整合。研究者们将 HippoRAG 与现有的检索增强生成（RAG）方法进行了比较，在多跳问答（QA）任务上展示了显著的性能提升，单步检索的 HippoRAG 在速度和成本上都优于迭代检索方法，如 IRCoT。此外，HippoRAG 能够处理传统 RAG 系统无法解决的新型多跳 QA 场景。 观点 评测结果 HippoRAG的优势 单步多跳检索 在多跳QA中，与传统的RAG方法相比，HippoRAG的一个主要优势是它能够在一个步骤中执行多跳检索。尽管 IRCoT 也可以解决这个多跳检索问题，如附录 G 所示，但在在线检索方面，它的成本比我们的高 10-30 倍，慢 6-13 倍，可以说是服务最终用户时最重要的因素
- [RaFe: Ranking Feedback Improves Query Rewriting for RAG](https://ihey.cc/rag/rafe-ranking-feedback-improves-query-rewriting-for-rag/): 标题 RaFe: Ranking Feedback Improves Query Rewriting for RAG 总结 本网页主要介绍了一种名为RaFe的查询重写框架，用于提高基于大型语言模型（LLMs）的检索增强生成（RAG）系统在开放领域问答（ODQA）任务中的性能。 摘要 RaFe框架通过利用公开可用的重排器提供反馈，有效地训练查询重写模型，而不需要额外的标注数据。该框架包括两个阶段：初始监督微调（SFT）和反馈训练。在SFT阶段，模型通过标准的监督微调获得重写能力。在反馈训练阶段，利用重排器的排名得分作为自然的反馈信号，通过离线和在线的强化学习（RL）方法进行训练。实验结果表明，RaFe在多个跨语言数据集上的表现优于基elines，特别是在EXPAND-Ranked设置下，其在问答任务中显示出显著的改进。此外，研究还探讨了不同数量的查询重写对RAG系统性能的影响，并指出在实际应用中，2-3个重写可能是最佳的平衡点。 观点 Why In this paper we attempt to (i) reduce the cost of annotations for feedback; and(ii) identify a signal that better aligns with the objectives of the query rewriting task. Contribution The main contributions of our paper can be summarized as […]
- [AGRAME: Any-Granularity Ranking with Multi-Vector Embeddings](https://ihey.cc/rag/agrame-any-granularity-ranking-with-multi-vector-embeddings/): 标题 AGRAME: Any-Granularity Ranking with Multi-Vector Embeddings 总结 本研究引入了AGRAME（Any-Granularity Ranking with Multi-Vector Embeddings），一种利用多向量嵌入进行任意粒度排名的方法，旨在通过编码级别的灵活性，实现从全文到句子甚至是命题层面的排名。 摘要 AGRAME是一个针对不同粒度排名的方法，它通过在单一的编码级别上使用多向量嵌入技术，能够在更细的粒度上进行排名，如句子级别或命题级别。研究团队包括来自伊利诺伊大学厄巴纳-香槟分校、苹果公司和Adobe公司的研究人员。他们提出了一种多粒度对比损失训练方法，用于提高基于ColBERTv2的多向量模型在更细粒度的排名任务中的性能。实验结果表明，AGRAME在自然问题解答、开放领域问题答erme、跨领域问题答erme以及命题级别的引用添加等多个任务中都表现出色，显著提高了在不同粒度上的排名性能。此外，研究还提出了PROPCITE方法，用于在生成的文本中添加引用，该方法通过使用命题作为查询来选择相关的上下文进行引用，在生成的文本中添加引用，并在检索增强的生成中表现出色。 观点 Why 贡献 假设验证 现有 ColBERTv2 模型在编码粒度的缺点，评测数据和示例 模型效果评测 多种数据集下的排序效果对比 多模型对比 观点归因效果
- [RE-Adapt: LLM 的逆向工程适配器](https://ihey.cc/llm/re-adapt-llm-%e7%9a%84%e9%80%86%e5%90%91%e5%b7%a5%e7%a8%8b%e9%80%82%e9%85%8d%e5%99%a8/): 标题 RE-Adapt: Reverse Engineered Adaptation of Large Language Models 总结 本网页介绍了一种名为 RE-Adapt 的方法，用于在不遗忘原有指令调优（instruction-tuning）的情况下，将大型语言模型（LLMs）适应新领域。 摘要 本文提出了一种名为 RE-Adapt 的方法，它通过逆向工程的方式提取了指令调优模型与其基础预训练模型之间的差异，形成了一个适配器（RE-Adapter）。这个适配器可以在不影响原有指令跟随能力的前提下，使预训练模型适应新领域的数据。RE-Adapt 还有一种低秩变体 LoRE-Adapt，它通过截断奇异值分解（SVD）来减少参数数量，同时保持性能。研究者们通过在多个流行的大型语言模型和数据集上进行实验，证明了 RE-Adapt 和 LoRE-Adapt 在问答任务中的优越性能，无论是在闭书问答（closed-book QA）还是检索增强生成（retrieval-augmented generation, RAG）的场景下。此外，本文还探讨了部分适应（partial adaptation）技术，即通过调整适配器的缩放因子来控制适应强度，以及如何在不进行额外训练的情况下通过调整指令调优的强度来改善模型性能。实验结果表明，RE-Adapt 能够在新领域增加知识，同时不会降低模型在原有领域的性能。 观点 效果 Closed-book QA 结合 RAG
- [FlashRAG: 为 RAG 研究而生的模块化工具包](https://ihey.cc/rag/flashrag-%e4%b8%ba-rag-%e7%a0%94%e7%a9%b6%e8%80%8c%e7%94%9f%e7%9a%84%e6%a8%a1%e5%9d%97%e5%8c%96%e5%b7%a5%e5%85%b7%e5%8c%85/): 标题 FlashRAG: A Modular Toolkit for Efficient Retrieval-Augmented Generation Research 总结 FlashRAG 是一个高效、模块化的开源工具包，旨在帮助研究人员复现现有的检索增强生成（RAG）方法，并在统一框架内开发自己的 RAG 算法。 摘要 网页主要介绍了一个名为 FlashRAG 的工具包，它是为了解决检索增强生成（RAG）研究中的挑战而设计的。RAG 技术通过结合大型语言模型（LLMs）和外部知识库来减少 LLMs 的幻觉问题。随着越来越多的算法和模型被引入以提高 RAG 系统的各个方面，比较和评估这些方法变得越来越困难。现有的 RAG 工具包，如 LangChain 和 LlamaIndex，虽然可用，但往往过于庞大，不能满足研究人员的个性化需求。FlashRAG 提供了一个模块化的框架，实现了 12 种高级 RAG 方法，并整理了 32 个基准数据集。它支持自定义的模块化框架、丰富的 RAG 组件集合、全面的数据集、高效的辅助预处理脚本以及广泛的评估指标。此外，网页还对 FlashRAG 的主要组件和流程管道进行了详细介绍，包括判别器（Judger）、检索器（Retriever）、重排器（Reranker）、细化器（Refiner）和生成器（Generator）等。最后，网页还展示了一系列实验结果，证明了 FlashRAG 在 RAG 领域的有效性和潜力。 框架特性 模块组件 Pipeline 将所有 RAG 流程分为四种类型：顺序、分支、条件和循环。到目前为止，我们已经实施了 8 个不同的管道，涵盖了一系列推进的 RAG 工作。 评测数据 […]
- [IM-RAG: 基于学习内在思维的多轮 RAG](https://ihey.cc/rag/im-rag%e5%9f%ba%e4%ba%8e%e5%ad%a6%e4%b9%a0%e5%86%85%e5%9c%a8%e6%80%9d%e7%bb%b4%e7%9a%84%e5%a4%9a%e8%bd%ae-rag/): 标题 IM-RAG: Multi-Round Retrieval-Augmented Generation Through Learning Inner Monologues 总结 本网页主要介绍了一种名为 IM-RAG 的多轮检索增强生成模型，该模型通过学习内在思维（Inner Monologues）来实现大型语言模型（LLMs）与信息检索（IR）系统之间的协同工作，以提高问答系统的性能和灵活性。 摘要 IM-RAG 是一个以 LLM 为中心的模型，旨在通过学习内在思维来实现多轮检索增强生成。该模型由四个主要组件构成：理论者（Reasoner）、检索者（Retriever）、精炼者（Refiner）和进度跟踪器（Progress Tracker）。理论者负责核心推理，能够根据对话上下文自动切换角色，作为提问者提出查询以获取更多相关文档，或作为回答者根据多轮对话提供最终答案。精炼者的作用是改善检索者的输出，使其更适合 LLM 的需求，而进度跟踪器则通过强化学习提供奖励信号，指导 IM-RAG 的训练过程。实验结果表明，IM-RAG 在 HotPotQA 数据集上实现了最先进的性能，同时提供了高度的灵活性和解释性。 WHY 有两种典型的范式来改进 RAG 系统：联合训练方法与分别训练不同的组件。 第一种范式涉及对LLM和检索器进行知识密集型任务的联合训练，从而增强语言模型的检索能力。然而，它缺乏可解释性，因为 LLM 和检索器之间的通信依赖于复杂的深度学习梯度传播以及 IR 嵌入模型和 LLM 之间的交叉注意力。 此外，这种训练方法的计算成本非常高，并且随着 LLM 的变化或学习，重新训练检索器的语义嵌入非常困难或昂贵。 第二种范式分别改进了 LLM 和/或 IR 引擎。该范式中的大多数先前工作都集中在改进LLM（以LLM为中心）上，通过提示或微调LLM参数[19,29,33]。基于提示的方法提供了简单性和灵活性，而不会产生额外的培训成本，并允许通过 API 调用集成黑盒 LLM 和搜索引擎。但是，它缺乏整个系统的端到端优化。相比之下，基于训练的方法收集和利用 LLM 和 IR 模块之间的人工注释交互记录，然后使用它们来监督 LLM […]
- [Prompt-based Code Completion via Multi-Retrieval Augmented Generation](https://ihey.cc/rag/prompt-based-code-completion-via-multi-retrieval-augmented-generation/): 总结 本网页主要介绍了一种名为 ProCC 的代码自动完成框架，它通过多重检索增强的生成（Multi-Retrieval Augmented Generation）技术，结合提示工程和上下文多臂赌博机算法，以多角度理解代码语义，提高代码自动完成的准确性和效率。 摘要 网页详细介绍了 ProCC 框架的设计和实现，它包括两个主要组件：基于提示的多重检索器系统和自适应检索选择算法。基于提示的多重检索器系统通过设计三种不同的提示模板来理解代码语义，分别是词法语义、假设行和代码摘要三个视角。自适应检索选择算法则利用上下文多臂赌博机算法，根据不同的代码上下文动态选择最合适的检索视角，以提供最佳的上下文支持。实验结果表明，ProCC 在开源和私有领域的基准测试中都优于现有的最先进的代码自动完成技术，并且在微软的 Code Llama 和 StarCoder 模型上进行了评估，显示出显著的性能提升。 观点 动机背景 方案 评测效果 链接 https://arxiv.org/pdf/2405.07530v1
- [控制令牌 (CT) 结合密集段落检索 (DPR) 模型](https://ihey.cc/searchengine/%e6%8e%a7%e5%88%b6%e4%bb%a4%e7%89%8c-ct-%e7%bb%93%e5%90%88%e5%af%86%e9%9b%86%e6%ae%b5%e8%90%bd%e6%a3%80%e7%b4%a2-dpr-%e6%a8%a1%e5%9e%8b/): 总结 本研究通过引入控制令牌（Control Token, CT）并结合密集段落检索（Dense Passage Retrieval, DPR）模型，提高了大型语言模型（LLMs）中的信息检索准确性，特别是在特定领域的文档检索方面。 摘要 研究团队采用了基于深度学习的搜索引擎技术，即密集段落检索（DPR）模型，并通过引入控制令牌（CT）来增强其性能。CT 是一种特殊的令牌，用于表示查询的意图类别，它通过与查询和文档文本结合，帮助模型更准确地理解用户的检索意图。研究选择了 AIHUB MRC 数据集，该数据集包含多种类型的复杂文档，并针对 ko 文本进行了优化。通过对 DPR 模型进行微调，使其能够处理包含 CT 的输入数据，研究者们开发了一种名为 cDPR 的模型。实验结果表明，与标准的 DPR 模型相比，cDPR 模型在 Top-1 和 Top-20 的检索准确率上分别提高了 13% 和 4%。此外，研究还探讨了不同的 CT 分类阈值对模型性能的影响，并发现了更高的分类阈值通常能带来更好的检索性能。 方法 聊天机器人搜索引擎的核心是了解用户意图。准确理解用户意图对于缩小搜索范围和提供高度准确的搜索结果至关重要。然而，现有的 DPR 模型的局限性在于它缺乏对用户意图的反思，仅依赖于文本相似性。因此，我们设计了一种将用户意图与 DPR 模型相结合的新方法 我们的研究目标是通过在输入中加入 CT 来微调 DPR 模型以提高搜索准确性。具体来说，CT 表示用户对特定文档的查询意图。例如，当用户查询特定域时，将特定于域的 CT 添加到输入中，使模型能够提供更准确的搜索结果。我们用包含 CT 的输入训练了 DPR 模型，以开发一个能够有效检索与用户意图相关的文档的系统，从而显着提高搜索准确性。图 1 显示了整个工艺流程。我们将这种 CT 和 […]
- [AIGC 领域下的 RAG 调查汇总](https://ihey.cc/rag/aigc-%e9%a2%86%e5%9f%9f%e4%b8%8b%e7%9a%84-rag-%e8%b0%83%e6%9f%a5%e7%a0%94%e7%a9%b6/): 总结 本网页是一篇综述性的研究论文，主要探讨了基于检索增强的生成（Retrieval-Augmented Generation, RAG）技术在人工智能生成内容（AI-Generated Content, AIGC）领域的应用和进展。 摘要 文章首先介绍了RAG技术的背景和重要性，指出随着基础模型的发展、大规模高质量数据集的可用性以及序列到序列任务的进步，AI生成内容（AIGC）面临的挑战和需求也在不断增长。RAG作为一种解决方案，通过引入信息检索过程，增强了生成过程的准确性和鲁棒性。文章详细分类了RAG的基础架构，包括查询基础、检索增强、对数概率增强和推测性RAG等多种类型，并探讨了这些方法在不同模态和任务中的应用。 接着，文章讨论了RAG的各种增强技术，包括输入增强、检索器优化、生成器优化、结果增强以及整个流程的增强等，这些技术都旨在提高RAG系统的性能。文章还展示了RAG在文本、代码、知识、图像、视频、3D、科学研究和音频等多个领域的应用实例。 文章最后指出了RAG技术面临的局限性和挑战，包括检索结果中的噪声、查询和生成器之间的间隙、系统复杂性增加、长尾和实时知识的整合以及与其他技术的结合等。同时，文章提出了未来研究的潜在方向，包括设计更高效的RAG架构、探索更多领域的应用、实现更好的长文本处理能力以及更有效地整合实时和长尾知识等。 观点 链接 论文：https://github.com/PKU-DAIR/RAG-Survey github：https://github.com/PKU-DAIR/RAG-Survey
- [ERAGent: 提升 RAG 模型的准确性、效率和个性化](https://ihey.cc/rag/eragent-%e6%8f%90%e5%8d%87-rag-%e6%a8%a1%e5%9e%8b%e7%9a%84%e5%87%86%e7%a1%ae%e6%80%a7%e3%80%81%e6%95%88%e7%8e%87%e5%92%8c%e4%b8%aa%e6%80%a7%e5%8c%96/): 一句话介绍 ERAGent 通过增强问题理解、优化知识检索、提升响应效率和实现个性化服务，显著提升了基于检索的大型语言模型的性能和用户体验。 摘要 ERAGent（Enhanced Retrieval-Augmented Generation Agent）是由悉尼科技大学的研究团队开发的，旨在通过增强问题重写、知识过滤和个性化大型语言模型读取器等组件来提升基于检索的大型语言模型（LLMs）的性能。该框架在处理复杂问题时，通过改进检索质量、提高响应效率和个性化服务，增强了问题理解和回答的准确性。研究团队通过对比实验和多轮多会话问答任务的评估，证明了 ERAGent 在提供准确、高效且个性化响应方面的优势。此外，ERAGent 还能够通过学习用户的个人资料，进一步优化与用户交互的质量。 为什么要做 ERAGent 作者认为在当前的 RAG 框架中存在以下问题： ERAGent 的做法 ERAGent 框架包含 6 个模块： 评测结果 召回效果 Rewriter 和 Filter 模块对召回和命中率数据提升并不明显 Profile 效果 Profile 增强的 LLM 生成胜率 Profile 增强的 LLM 生成示例 论文链接 https://arxiv.org/pdf/2405.06683
- [融合检索 & Rerank 在 RAG 中的效果评测](https://ihey.cc/rag/fusion-rerank-top-n-in-rag/): RAG 的基本原理 RAG 的工作流程主要分为两个阶段： Embedding 的缺点 Embedding 的具象化理解可以是，用一组高维数据来表达一段文本的核心内容。如果这段文本非常长，或者包含的内容非常多样化，那么固定维度的 embedding 是很难表达文本的全面内容的。因此： 融合检索和 Rerank 单纯使用 embedding 向量检索，在真实业务场景下的召回成功率很低。 常见的优化方案有： bge-m3 模型 bge-m3 模型自身支持了三种检索模式：Dense、Sparse、Multi-vector。官方介绍如下： 虽然官方提供了三种检索方式的代码 demo，但在真实场景下，embedding 向量需要存储在向量数据库，而检索计算能力必须由向量数据库支持。幸运的是，Milvus 向量数据库已经支持了 dense + sparse 混合检索方式 ，并支持双路加权排序。 参考 Milvus 的官方 demo 评测方案设计 文档数据 我以一个真实业务场景下的真实文档和真实用户问答数据，来评测 Dense、Sparse、Hybrid 检索及叠加 Rerank 后的召回率。不评测生成阶段的 LLM 回答正确性。 知识库文档数目 评测问题数目 文档平均长度（字符数） 文档最大长度（字符数） 文档最小长度（字符数） 1300 230 2000 8000 200 文档和问题数量级 评测技术选择 评测目标 […]
- [Reducing hallucination in structured outputs via Retrieval-Augmented Generation](https://ihey.cc/rag/reducing-hallucination-in-structured-outputs-via-retrieval-augmented-generation/): 一句话介绍 主要介绍了一种使用检索增强生成（RAG）技术来减少生成性人工智能（GenAI）中幻觉现象的方法，并在工作流程 (workflow) 生成任务中实际应用了这种方法。 by heycc 业务场景 把用户的自然语言转换成 json 结构化的 workflow。ServiceNow 面对的 workflow 是 ITSM、HR、财经等企业内的信息化流程 为什么要训练 把自然语言转换为 Code 或者 SQL 已经非常普遍了，但是在 ServiceNow 的业务场景下，需要把自然语言转换为企业内 specific 的 workflow，涉及指定 table、step 名称，还需要产生 json 结构的 workflow 输出。所以需要 fine-tune retrieval 和 LLM 模型 基于什么模型训练 Retrieval 模型：某个基于 SentenceTransformer 框架的模型 出于部署成本考虑，LLM 模型选择 7B。 retrieval 模型更小，可以基于 CPU 部署 评测结果如何 召回率评测：基础召回模型，即使选择不同的参数大小，召回率基本不变； 精调后的模型，叠加多种采样策略后，整体召回率显著优于基础模型

## Pages

- [Sample Page](https://ihey.cc/sample-page/): This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this: Hi there! I’m a bike messenger […]
- [AIGC Gallery](https://ihey.cc/gallery/)
- [Sample Page](https://ihey.cc/sample-page-2/): This is an example page. It’s different from a blog post because it will stay in one place and will show up in your site navigation (in most themes). Most people start with an About page that introduces them to potential site visitors. It might say something like this: Hi there! I’m a bike messenger […]


[comment]: # (Generated by Hostinger Tools Plugin)