，以及不调库的 RAG)
上下文与检索Context Window f(Context)以及不调库的 RAG配套课程第三章11 讲 智能检索主线。对应考点上下文不是越多越好、压缩与细节找回、RAG 不止于“丢给向量库”。1. 一句话点破误区面试官你的 Agent 怎么管理上下文候选人把历史对话全塞进 prompt 就行了。面试官长任务跑 50 轮呢token 爆了、噪声淹没关键信号怎么办课程的原话是Context Window f(Context)—— 上下文是“上下文状态”的函数不是堆得越多越好。本系统的memory_agent.py同时做了上下文管理和检索两件事而且零三方依赖不用 langchain、不用向量数据库方便你读源码、改源码、讲源码。2. 上下文管理 f(Context)该放什么、该丢什么、丢了怎么找回来2.1 工作记忆 预算压缩def_compress(self,sid):whileTrue:size(sum(len(str(h))forhinhistory)len(str(entities))len(str(prefs)))ifsizeself.WORK_BUDGETorlen(history)3:breakoldhistory.pop(0)# 丢最早的细节self.compressed[sid][key]old# 但细节进“压缩存储”超预算时丢弃早期历史细节但保留实体与偏好机票、上海、低预算这类关键信息永不离场。被丢的细节不是没了而是进了compressed存储。2.2 细节找回detail recoverydefexpand(self,sid,key):return{key:key,detail:self.compressed[sid].get(key)}需要时可以按 key 把压缩掉的细节重新展开。这就是课程说的“压缩之后细节怎么找回来”。2.3 相关度过滤不是越多越好get_context支持按当前任务做相关度过滤——只把与当前任务相关的实体送进窗口iftaskandentitiesinctx:ctx[entities_relevant][eforeinctx[entities]ifeintask]这一行就是f(Context)的具象上下文是“当前任务”的函数。3. 智能检索不用向量库的 RAG 也能跑课程说“智能检索不止 RAG”。但 RAG 本身也要讲清楚“该查什么、去哪查、chunk 粒度与召回精度怎么平衡”。本系统用一个零依赖的 TF-IDF 字符 bigram 向量实现真实检索deftokenize(text):toks[w.lower()forwinre.findall(r[a-zA-Z0-9],text)]cnre.sub(r[a-zA-Z0-9],,text)foriinrange(len(cn)-1):toks.append(cn[i:i2])# 中文按字符 bigram 切规避分词依赖returntoksclassTFIDFIndex:defquery(self,q,top_k3):# 构造查询向量 → 与每篇 doc 的 tfidf 向量算余弦 → 取 top_k为什么不用现成向量库为了把检索原理讲透。面试时能说出“chunk 粒度太小召回碎、太大引入噪声”“查询改写提升准确率、索引提升性能”比“我调了 xxx 向量库”强。3.1 真实召回效果S2 里retrieve(机票)命中《机票产品知识》片段“机票预订支持单程与往返价格随淡旺季与提前天数波动。通常提前 21 天以上预订最划算……”S3 里retrieve(云服务器)命中《云服务器规格与计费》。检索相关性指标在实测里 1.0。3.2 chunk 粒度与召回/精度的权衡语料corpus_data.py把知识切成一条条 chunk每条一个概念/一个产品演示了 chunk 粒度的选择太细一个概念拆成 5 段 → 召回碎、拼不起来太粗整章一个 chunk → 噪声多、精度掉本系统取“一个概念/产品一条”是兼顾召回与精度的折中。4. 检索失败怎么办也是 Replan 的素材当查询过窄导致0 条命中执行层返回结构化失败PlanAgent 把它分类为retrieval根因插入“放宽检索/切换知识源”的纠正步。这就把“智能检索”和“规划执行”连起来了。5. 面试话术模板“上下文管理我用f(Context)的思路上下文不是越多越好。我给工作记忆设预算超阈值丢早期细节但保留实体和偏好丢弃的细节进压缩存储可按 key 找回get_context还按当前任务做相关度过滤只把相关上下文送进窗口。检索侧我实现了一个零依赖的 TF-IDF 字符 bigram 检索讲清楚 chunk 粒度、查询改写和重排对召回/精度的影响而不是黑盒调向量库。”下一篇执行与评估TAO 工具选择与评估反馈闭环
上下文与检索Context Window f(Context)以及不调库的 RAG配套课程第三章11 讲 智能检索主线。对应考点上下文不是越多越好、压缩与细节找回、RAG 不止于“丢给向量库”。1. 一句话点破误区面试官你的 Agent 怎么管理上下文候选人把历史对话全塞进 prompt 就行了。面试官长任务跑 50 轮呢token 爆了、噪声淹没关键信号怎么办课程的原话是Context Window f(Context)—— 上下文是“上下文状态”的函数不是堆得越多越好。本系统的memory_agent.py同时做了上下文管理和检索两件事而且零三方依赖不用 langchain、不用向量数据库方便你读源码、改源码、讲源码。2. 上下文管理 f(Context)该放什么、该丢什么、丢了怎么找回来2.1 工作记忆 预算压缩def_compress(self,sid):whileTrue:size(sum(len(str(h))forhinhistory)len(str(entities))len(str(prefs)))ifsizeself.WORK_BUDGETorlen(history)3:breakoldhistory.pop(0)# 丢最早的细节self.compressed[sid][key]old# 但细节进“压缩存储”超预算时丢弃早期历史细节但保留实体与偏好机票、上海、低预算这类关键信息永不离场。被丢的细节不是没了而是进了compressed存储。2.2 细节找回detail recoverydefexpand(self,sid,key):return{key:key,detail:self.compressed[sid].get(key)}需要时可以按 key 把压缩掉的细节重新展开。这就是课程说的“压缩之后细节怎么找回来”。2.3 相关度过滤不是越多越好get_context支持按当前任务做相关度过滤——只把与当前任务相关的实体送进窗口iftaskandentitiesinctx:ctx[entities_relevant][eforeinctx[entities]ifeintask]这一行就是f(Context)的具象上下文是“当前任务”的函数。3. 智能检索不用向量库的 RAG 也能跑课程说“智能检索不止 RAG”。但 RAG 本身也要讲清楚“该查什么、去哪查、chunk 粒度与召回精度怎么平衡”。本系统用一个零依赖的 TF-IDF 字符 bigram 向量实现真实检索deftokenize(text):toks[w.lower()forwinre.findall(r[a-zA-Z0-9],text)]cnre.sub(r[a-zA-Z0-9],,text)foriinrange(len(cn)-1):toks.append(cn[i:i2])# 中文按字符 bigram 切规避分词依赖returntoksclassTFIDFIndex:defquery(self,q,top_k3):# 构造查询向量 → 与每篇 doc 的 tfidf 向量算余弦 → 取 top_k为什么不用现成向量库为了把检索原理讲透。面试时能说出“chunk 粒度太小召回碎、太大引入噪声”“查询改写提升准确率、索引提升性能”比“我调了 xxx 向量库”强。3.1 真实召回效果S2 里retrieve(机票)命中《机票产品知识》片段“机票预订支持单程与往返价格随淡旺季与提前天数波动。通常提前 21 天以上预订最划算……”S3 里retrieve(云服务器)命中《云服务器规格与计费》。检索相关性指标在实测里 1.0。3.2 chunk 粒度与召回/精度的权衡语料corpus_data.py把知识切成一条条 chunk每条一个概念/一个产品演示了 chunk 粒度的选择太细一个概念拆成 5 段 → 召回碎、拼不起来太粗整章一个 chunk → 噪声多、精度掉本系统取“一个概念/产品一条”是兼顾召回与精度的折中。4. 检索失败怎么办也是 Replan 的素材当查询过窄导致0 条命中执行层返回结构化失败PlanAgent 把它分类为retrieval根因插入“放宽检索/切换知识源”的纠正步。这就把“智能检索”和“规划执行”连起来了。5. 面试话术模板“上下文管理我用f(Context)的思路上下文不是越多越好。我给工作记忆设预算超阈值丢早期细节但保留实体和偏好丢弃的细节进压缩存储可按 key 找回get_context还按当前任务做相关度过滤只把相关上下文送进窗口。检索侧我实现了一个零依赖的 TF-IDF 字符 bigram 检索讲清楚 chunk 粒度、查询改写和重排对召回/精度的影响而不是黑盒调向量库。”下一篇执行与评估TAO 工具选择与评估反馈闭环
