𝐺ℎ𝑎𝑜 の 𝐵𝑙𝑜𝑔

1. 前端优化思路对前端来说，核心目标是：在保证体验的前提下尽可能降低请求数和 QPS。在百万级直播间场景中，主要涉及两个操作： 用户的点赞行为 点赞总数的展示 可以从以下几个方面做优化： 批量上报点赞 用户每次点击并不立刻发起接口请求，而是在一个时间窗口内本地统计点击次数，合并为一次请求上报。 例如：前端每秒上报一次当前时间段内的点赞增量。这样可以将请求量压缩到原来的很小一部分，通常能减少 80% 以上的请求。 点赞数展示做“近似实时”而非“完全实时” 点赞总数的展示不要求完全精确，可以定时拉取，例如每隔 1 秒请求一次点赞量。 但在百万级直播间里，如果所有用户在同一时间点发起请求，后端压力依然很大。可以在前端引入随机抖动：在一个时间窗口内随机选择一个时刻发起请求，从而把请求时间打散，进一步削峰。 限制用户操作 + 接入风控 对单个用户在一定时间内的点赞次数设置上限，避免极端频率的操作。 同时接入风控，对疑似恶意账号（如刷量账号）进行限频、封禁等处理，从源头减少无效请求。 2. 后端优化思路对后端而言，可以围绕缓存 + 消息队列（削峰填谷） 来设计整体方案。 ...

1. 两数之和给定一个整数数组 nums 和一个整数目标值 target，请你在该数组中找出 和为目标值 target 的那 两个 整数，并返回它们的数组下标。 你可以假设每种输入只会对应一个答案，并且你不能使用两次相同的元素。 你可以按任意顺序返回答案。 示例 1： 123输入：nums = [2,7,11,15], target = 9输出：[0,1]解释：因为 nums[0] + nums[1] == 9 ，返回 [0, 1] 。 示例 2： 12输入：nums = [3,2,4], target = 6输出：[1,2] 示例 3： 12输入：nums = [3,3], target = 6输出：[0,1] 提示： 2 <= nums.length <= 104 -109 <= nums[i] <= 109 -109 <= target <= 109 只会存在一个有效答案 题解暴力12345678910111213class Solution { public int[] twoSum(int[] nums, i...

完整复盘掌柜智库项目的 RAG 核心流程：准备阶段 7 个节点与检索阶段 7 个节点，汇总 LangGraph、Milvus、MCP、reranker 等核心技术点，并记录 tester/runner 打桩面试点与后续安排。 本篇要点 为什么用 RAG，以及 RAG 的基本准备 / 检索流程 项目准备阶段 7 个节点、检索阶段 7 个节点的作用与意义 项目核心技术点清单：技术点 + 关键用法 项目相关面试（tester / runner 的 patch 打桩）、AI 生成页面的基本流程与后续安排 项目总览项目阶段 ≈ Python 基础阶段，不用过多去理解，更多的去写、去敲——键盘敲烂，月薪过 3 万。 整篇总结分为五块：项目核心流程（RAG 扩展 + 准备 7 节点 + 检索 7 节点）、项目核心技术点清单、项目相关面试、使用 AI 生成页面的基本流程、后续安排。 1、项目核心流程1.1 RAG 流程的扩展1.1.1 为什么使用 RAG现在的模型上下文窗口已经巨大了，为什么还要用 RAG？ 模型窗口大小：每次真的使用都会消耗 token...

用权重加 RRF 思路精炼两路向量检索结果，再引入 bge-reranker-large 对多源候选统一打分与动态 TopK 截取，最后通过 output_answer 节点生成答案并正则提取图片地址。 本篇要点 node_rrf 节点：用“权重 + RRF”把两路向量检索结果再次精炼 reranker 节点：面向多源候选统一打分与动态截取 MTEB 模型对比、bge-reranker-large 加载与 compute_score 打分 token 长度计算与重排序模型上下文超长处理 output_answer 节点：流式 / 非流式返回、正则提取 image_urls、保存聊天记录 内容回顾1、检索节点 node_search_embedding：rewritten_query 的向量与 chunks 的 content（item_name + title + content）做混合 + 条件检索，生成 embedding_chunks。 node_search_embedding_hyde：先用大模型基于原问题生成假设性标准回答，再用“问题 + 答案”...

承接 item_name 识别，先回顾 Milvus 单列检索与混合检索并改造公共类，再实现 node_search_embedding、node_search_embedding_hyde 与 node_web_search_mcp 三个检索节点。 本篇要点 回顾 Milvus 单列检索与混合检索（AnnSearchRequest、WeightReranker / RrfReranker） 改造 Milvus 公共类，封装 create_requests / hybrid_search 实现 node_search_embedding 节点：重写问题的向量做混合 + 条件检索 实现 node_search_embedding_hyde 节点：用假设答案增强召回 实现 node_web_search_mcp 节点：MCP 概念、协议与百炼联网搜索工具接入 内容回顾1、node_item_name_confirm 节点 作用：从提问与历史上下文中识别 item_names，并重写 original_query → rewritten_query；也有...

记录 task_util 与 sse_util 的作用和 SSE 事件类型，实现查询 web api 三个接口并修复三处 bug，整理 MongoDB 安装/CRUD/索引与 pymongo 历史记录管理，最后解读 node_item_name_confirm 节点。 本篇要点 task_util 与 sse_util 的作用和关联，以及 SSE 六种事件类型 查询 web api 接口实现（html / 健康检查 / 提问），流式与非流式的区别 三处 bug 修复：final 提前推送、节点状态缓存、清空 task MongoDB 安装、CRUD 命令与索引原理 pymongo 封装与历史聊天记录管理，node_item_name_confirm 节点 内容回顾1、上一天主题（Day07） 导入模块三个接口：html 页面返回、文件上传、状态查询 查询模块 8 个节点的图结构定义，以及并发节点 state 增量更新报错 SSE 基本使用：数据格式、前端 EventSource 三种交互方案、task_util 与 sse_ut...

BGN29 小红的优惠券贪心 描述小红的购物车结算金额为 nn 元，她手中有 mm 张优惠券。第 jj 张优惠券的规则为“满 aja**j 元立减 bjb**j 元”，即若 n≧ajn≧a**j，则使用该券后需支付 n−bjn−b**j 元。 小红至多使用一张优惠券，请问最少需要支付多少元？ 输入描述：第一行输入两个整数 n,m(1≦n≦105; 1≦m≦100)n,m(1≦n≦105; 1≦m≦100)。接下来 mm 行，第 jj 行输入两个整数 aj,bj(1≦bj≦aj≦105)a**j​,b**j​(1≦b**j​≦a**j​≦105)，描述第 jj 张优惠券。 输出描述：输出一个整数，表示小红使用最优策略后需支付的最少金额。 示例1输入： 1234100 3300 50200 3050 5 输出： 195 说明： 1仅第三张券可用，支付 100−5=95100−5=95 元。 题解1234567891011121314151617181920import java.util.*;public class Main { public static...

记录导入模块三个接口（html 返回、文件上传、状态查询）的实现，梳理查询模块 8 个节点的图结构与并发 state 报错，并整理 SSE 基本用法及 task_util 与 sse_util 的关系。 本篇要点 导入模块三个接口：html 页面返回、文件上传、状态查询 查询模块图结构定义：8 个节点的读 / 写字段规划 并发节点 state 增量更新的报错原因与规避方式 SSE 技术的基本使用与前端三种交互方案 内容回顾1、上一天主题（Day06） node_bge_embedding：item_name + content 拼接成向量，批量处理，8192 token 上限、6 个一批 node_import_milvus：创建 schema 与 index，先删后插写入 Milvus FastAPI 使用回顾：路径、参数（路径 / 查询 / json / 文件）、响应（json / 文件 / 流式）、异步 BackgroundTasks 今天内容1、导入模块的三个接口实现1.1 三个接口的约定导入模块一...

记录 node_bge_embedding 的向量生成与批量策略、node_import_milvus 的集合创建与先删后插，以及 FastAPI 路径、参数、响应与异步任务回顾。 本篇要点 node_bge_embedding：把 item_name + content 拼起来生成向量，批量提交 批量数量的约束来源：bge-m3 的 8192 token 上下文窗口、CPU 缓存与 GPU 显存，最终 6 个一批 node_import_milvus：创建 schema / index、先删后插、导入完成日志 FastAPI 回顾：路径、参数、响应（文件 / json / 流式）与异步 BackgroundTasks 内容回顾1、Day05：精细切割与 item_name 识别节点 refine_chunks 精细切割：过长的块（> 600）交给 _split_long_chunk 短切并保留 overlap，过短的块（< 400）用 _merge_short_chunks_same_parent_title 合并，合并上限...

在标题切割之后做 refine_chunks 精细切割，并梳理 item_name 识别节点的动机、bge-m3 与 Milvus 的准备工作以及节点的实现步骤。 本篇要点 refine_chunks 精细切割：长块短切（带 overlap）、短块合并、parent_title / part 补全 为什么必须识别 item_name：用主体名缩小向量检索范围 向量回顾：稠密 dense（注意维度，推荐 1024）与稀疏 sparse 准备工作：bge-m3 的下载与两种加载方案、Milvus 部署与 MilvusGateway 封装 item_name 识别节点的作用、参数与六步实现流程 内容回顾1、Day04：node_document_split 节点 先定下切块产物结构：content（标题 + 内容）、title、file_title、parent_title、part，向量相关字段留到后面补 四大切割原则：语义优先、长度可控、边界清晰且有合理重叠、可追溯 项目切割参数：CHUNK_MAX_SIZE = 1000、CHUNK_SIZE = 600、C...