向内求解增长修炼册

温度0.7还是偏高，试试降到0.2，再配合JSON schema约束输出结构，比堆强调词管用。

我之前也踩过这个坑，后来发现根子不在prompt，而是Agent之间没有明确的“状态机”约束。规划Agent和执行Agent如果都能自由改任务定义，那肯定互相甩锅。我现在的做法是给每个Agent固定输入输出schema，比如规划只输出JSON格式的子任务列表，执行只能消费这个列表，不允许自己重新规划。另外加一个轻量级的“仲裁者”角色，专门检测循环和冲突，比单纯调max_iterations管用多了

这个坑我也踩过，用LLM单独做二元判断确实不太靠谱，模型天生倾向于说“是”，尤其是prompt里只给“相关/不相关”两个选项的时候，它会把“沾点边”也算进去。后来我改成让它做相对排序，比如给一个问题配上5个候选段落，让它挑出最相关的1-2个，反而比逐个判断稳定得多，因为有了对比它就有了参照系。还有个思路是把判断拆细一点，不要问“是否相关”，而是问“这段内容能直接回答用户问题吗”或者“这段内容提到了

你这个问题大概率不是chunk_size的锅，5000份PDF里混着标题、表格、代码块，硬切512很容易把配置步骤和错误码拆到两个块里，检索时当然只能命中一半。我之前也踩过这坑，后来先用unstructured或者pdfplumber把标题层级和表格抽出来，按章节做父子块，小块去召回、大块给上下文，效果提升挺明显。另外复杂问题最好加个query改写或者多路召回，光靠单路bge向量有时候确实抓不住“

几千页PDF跨章节问不准很正常，先别急着换模型，试试按标题层级切块再混BM25，比单调chunk_size管用。

7B这个量级其实vLLM就挺够用了，吞吐比transformers强太多，算子报错一般是模型架构太新或者量化版本的问题，换个官方支持的模型基本没事。TensorRT-LLM性能确实猛，但转engine那套流程每次换模型都要折腾一遍，自己玩真没必要。我平时学习场景直接Ollama起步，省心，等要压测或者上生产再切vLLM。非要纠结的话，先vLLM跑通，遇到瓶颈再考虑TensorRT-LLM也不迟。

我之前也踩过类似的坑，LoRA微调确实容易把embedding分布带偏，因为生成任务和检索任务对特征空间的要求其实挺矛盾的。可以试试冻结底层参数只微调上层，或者微调时把检索相关的对比损失也加进去一起优化。另外，如果检索用的是独立的embedding模型，建议别动它，只微调生成部分，或者干脆用混合检索把BM25和向量结果融合一下，能兜底不少。你现在的检索向量是从ChatGLM3出来的，还是单独挂了别

说实话你这个问题我太有共鸣了，当初我搭RAG也是从Chroma开始的，几万条文档纯demo完全够用，别纠结embedding维度，直接跟着你选的模型走，Qwen和ChatGLM官方推荐的维度一般就是768或者1024，切块大小控制在500字左右效果比较稳。你要是担心后面扩到百万级，其实Milvus现在有轻量版Milvus Lite，本地跑跑也不重，但真没必要第一步就上分布式，除非你确定业务马上要爆

说实话你这情况我太熟了，之前做个合同审查的项目也是这德行，财务指标的问题召回回来全是免责条款。我后来排查发现，问题往往不在chunk大小，而是embedding本身对领域术语和数字型query的语义理解太弱，你问“上季度营收”这种带明确指向性的问题，向量空间里它跟“团队建设”的相似度可能真就比跟财报片段高。所以别死磕重排了，它只是在既定候选里挑矮子里的将军，源头没召回对就是白搭。hybrid这条路

我试过类似的情况，感觉问题出在你给的示例代码上，模型会模仿格式。你可以试试在prompt里明确写“代码中禁止任何注释和文档字符串，包括#和"""形式”，并且给一个不带注释的示例，让它照着来，效果会好不少。 另外，如果你用的是API，可以把temperature调低一点，比如0.2，模型会更听话。或者生成后自己写个正则把注释行删掉，反正批量处理也不麻烦。

这问题我太有同感了，提示词越长戏越多，感觉模型在拼命揣摩“人设”。后来我发现干脆把系统提示词砍到只剩工具描述和输出格式，反而老实多了。你可以试试把所有规则都塞进few-shot里，给它看三个“输入-输出”的例子比写十行“不要客套”管用。另外XML标签确实好用，但别用它来写指令，只用来包数据，模型反而分得清边界。

必须存啊，不然检索出来还得回源查一遍，延迟直接翻倍。 存原文还能顺便存个摘要，省得每次都得调大模型重读一遍。

大概率是索引矩阵没detach或者没在backward里置空，试试把不需要梯度的变量显式detach一下。

试试把代码按函数粒度切块建索引，问答时先定位到具体函数再拼上下文，能省不少token。

试试在Prompt里给个固定模板，比如要求必须带main函数和特定注释，能明显收敛结构。

切片这块别迷信固定参数，我试过按Markdown标题和表格结构切，比纯按字数稳得多，长文档先做章节感知再切，能保上下文。检索层面强烈建议上混合检索，BM25+向量分数做RFF融合，能救回不少语义匹配不到的实体词。重排序基本是必须的，bge-large出的top50用bge-reranker过一遍，效果提升肉眼可见，不然纯向量距离排序确实总把关键段落埋太深。另外你滑动窗口重叠设个10%-15%就行，

这场景光靠prompt确实不稳，建议给两个function加个输入参数约束，比如日历必须带日期和关键词，模型就没法瞎编了。 我试过把意图判断拆成两步，先让模型输出结构化意图标签再选API，比直接function calling稳得多。

说实话这个问题我太有共鸣了，最近我也被折磨得够呛。我试下来感觉tab补全和Composer完全是两套逻辑，tab更倾向于“猜你下一个token”，它根本不会去全局扫描你的类型定义，所以经常放飞自我；而Composer的agent模式至少会加载整个文件上下文，你把types.ts的路径写进系统提示词里，它会更认真地对待。另外有个偏方，就是把你最核心的几个类型直接以JSDoc注释的形式写在组件文件顶部

4060 8G跑7B量化确实勉强，我之前也是这配置，后来换Qwen2.5-Coder-1.5B-Instruct的Q4_K_M版，配合Continue插件做补全，响应快很多，长上下文也不怎么卡。如果你主要是写Python或TS，其实试试CodeLlama-7B的4bit或者DeepSeek-Coder-V2-Lite，显存占用能压在4G左右，体验比硬扛7B好太多。另外记得把Ollama的num_c

写接口文档再让它生成确实有用，上下文给到函数签名和返回类型就够了，别指望它自己会读心。 我是直接把伪代码注释写进prompt，再让它一步步实现，幻觉能少一半。