potoior

记一次 RAG 检索系统的“bug”与优化之旅：从“黄油煎虾”霸榜到精准检索背景在开发我的 “尝尝咸淡” (Smart Cooks) 智能食谱助手时，我遇到在一个非常经典的 RAG (检索增强生成) 问题。后端使用 FastAPI，核心是一个混合检索系统（结合了 Vector Search 和 BM25）。 案发现场：诡异的“黄油煎虾”用户提问：“我有胡萝卜，木耳，猪肉，我可以做什么菜？”标准答案：“鱼香肉丝”。系统回答： 黄油煎虾 黄油煎虾 黄油煎虾 …. 第一回合：此路不通 - 阈值调整 (The Threshold Trap)思考过程现象观察：看到“黄油煎虾”这种完全风马牛不相及的结果，我的第一反应是：系统一定是在“凑数”。检索器可能根本没有找到相关文档，但是因为没有设置下限，把不相关的结果也硬塞给了大模型。 我的推测：向量检索的相似度阈值 (score_threshold) 太低了（默认 0.4）。许多只有一点点相关的文档（包含个别字）混了进来。 决策：我决定提高门槛，宁缺毋滥。我将 config.py 中的阈值从 0.4 提高到了 0.6。 代码尝试代码修改 ...

从“搜不到”到“一搜就有”：RAG 场景下的 Query 重写技术全景指南 一、为什么写这篇文章做 RAG（Retrieval-Augmented Generation）的同学几乎都被一句话折磨过：“检索不到，生成啥都白搭”。在真实业务里，30%~50% 的 Bad Case 并不是因为知识库没有答案，而是用户 query 太短、太口语、有错别字，导致向量检索阶段直接漏掉了相关文档。Query 重写（Query Rewriting / Reformulation）就是用来解决这个“最后一公里”问题的技术。本文尝试把学术前沿、工业落地、代码实现、踩坑经验一次性讲透，让你“拿来就能用”。 二、问题拆解：检索失败的 6 大根因 根因 典型例子 传统关键词硬伤 向量检索硬伤 1. 过短 “EMSPLoS” 无上下文 向量太稀疏 2. 指代 “他写的论文” 无实体 语义漂移 3. 错字 “Transfomer” 拼写失配 子词切错 4. 同义 “小孩发烧怎么办” vs “幼儿发热处理” 字面不匹配 向量距离大 5. 歧义 “苹果发布会” vs 水果 多...

NGINX 负载均衡算法深度解析 这是一个关于技术创业者土豆和他的亲密伙伴 NGINX 的真实故事。通过土豆电商平台从零到千万用户的技术演进，我们将深入探索负载均衡算法的奥秘。 第一章：创业伊始 - 单服务器的美好与局限1.1 技术选型的初心2018 年，土豆辞去大厂工作，开始了”土豆优选”的创业之旅。技术选型时，他选择了 NGINX + Spring Boot + MySQL 的经典架构。 123456789101112131415161718# 最初的单服务器配置server { listen 80; server_name potoiorshop.com; # 静态资源直接由NGINX处理 location /static/ { root /var/www/html; expires 30d; } # 动态请求转发到应用服务器 location / { proxy_pass http://127.0.0.1:8080; proxy_se...

早期 Agent 珍贵录像项目 url：https://gitee.com/hazhenyu/mgterp.git 自然语言转化为订单的流程如下： 首先用户输入 input-> 判断用户输入的问题是不是和 erp 有关系的 如何判断用户输入的问题是不是和 erp 有关系的：简单的字符串匹配即可。比如 12345678910111213String[] generalKnowledgeKeywords = { "什么是", "如何实现", "怎么做", "介绍一下", "解释", "定义", "历史", "原理", "方法", "区别", "比较", "教程", "讲解", "写一篇", "生成", "创作", "...