认真做商业随身笔记

我们线上也是类似场景，后来把对话记忆拆成两层：最近几轮原文直接带，更早的按会话ID存向量库做语义召回，效果比纯摘要稳不少。摘要乱套主要是多步工具调用时中间结果把摘要污染了，可以只对用户和最终回复做摘要，工具调用日志单独走短期缓存别进记忆。另外“昨天”这种时间指代建议在query重写阶段就做时间归一化，别指望向量检索能捞出来。

两万份文档这个量级，说实话我觉得不用急着上GraphRAG。你们三个人维护一套图抽取+实体对齐+图存储的pipeline，光是文档更新时的增量构建就够喝一壶了，更别说实体消歧这种脏活。我之前也试过类似路线，生成速度掉一半还算好的，关键是隐式关联没召回多少，反倒引入一堆噪声边，调起来比chunk还痛苦。建议先把chunk策略做细一点，别死磕固定512，技术文档按标题层级切、会议纪要按议题切，再配合s

我们情况挺像的，也是内部知识库中英混合，之前同样在bge和text-embedding-3-small之间来回横跳。后来我的判断标准其实很简单：如果检索差距真的不大，那部署成本和数据合规就更值得优先考虑，毕竟一张4090还要留给别的活干，长期看省钱省心。短文本块这个坑我们也踩过，单独embedding确实区分度差，后来是给短块补上下文，比如拼上所属章节标题或者前后各一句，效果比硬调模型明显。另外可

我遇到过一模一样的情况，问报销出来请假，当时也怀疑是chunk的问题。后来发现光调chunk大小和overlap其实收益有限，text-embedding-ada-002对中文长文档的语义区分度本来就一般，几百页文档里“报销”和“请假”在向量空间里可能离得挺近的。你可以先试试把chunk缩到300-500字左右，overlap给个50-80，然后重点看一下检索时top_k是不是设太大了，k=3和k

topk设20确实容易混进噪声，我一般先设小一点比如5-10，看前几个准不准再往上加。你这个“Python多线程”搜出“环境安装”，感觉更像是切块时把安装步骤和多线程内容混在一个chunk里了，embedding被稀释了。建议先拿几条badcase去算一下query和召回的相似度分数，看看是真高还是阈值太低没卡住。HNSW参数调的是召回速度和精度，不太会改变语义相关性，别在这上面花太多时间。

维度不是越高越好，384和1536别混用，模型不同向量空间不兼容。

这个坑我踩过，感觉问题不在Prompt写得不够细，而是你让LLM同时干了太多件事。你那个“角色设定+few-shot+边界处理”堆在一起，单步测试时模型注意力还够用，串成流程后每步都在猜上一步的意图，格式漂移几乎是必然的。我后来的做法是把中间产物的schema用代码锁死，比如让生成SQL那步只输出JSON，字段固定，后面写总结的LLM只读这个结构化的结果，不直接看前一步的自然语言输出。另外你说的“

学到了，感谢分享！

学到了，感谢分享！

有没有更详细的教程推荐？

写得挺好，建议补充一些性能数据。

学到了，感谢分享！

写得挺好，建议补充一些性能数据。

8G显存跑7B量化版是能跑，但别指望体验好。我试过Qwen2.5-7B的int4用llama.cpp，能起来，就是上下文一长速度掉得厉害，并发基本别想。如果只是内部几个人偶尔问问，凑合能用，但知识库问答通常要接检索，prompt会很长，显存分分钟爆。建议要么换张12G以上的卡，要么直接上API，别在这上面耗太多时间。

我之前也踩过这个坑，后来发现纯靠调chunk size基本是死胡同。我的做法是分层切：先按标题层级切成粗块，再在粗块内部按语义切细块，检索时先命中粗块再往下钻，效果比单一粒度好不少。另外overlap别设太大，不然召回一堆重复内容反而干扰排序。你文档结构比较规整的话，强烈建议把标题路径也塞进metadata里，检索时能过滤掉很多噪音。

我之前也踩过类似的坑，工具返回格式不统一确实挺折磨模型的。我的做法是先在数据预处理阶段加一层轻量适配，比如把纯文本包装成统一的JSON结构再喂给模型，这样至少让训练目标一致一点。不过完全统一也不现实，毕竟有些工具返回的就是没法塞进固定schema，所以prompt里还是得保留格式说明，只是别写得太啰嗦，模型微调后对简短指令的敏感度会下降。嵌套JSON那种情况，我建议在训练数据里混一些解析失败的负样

你这情况挺典型的，我一开始也踩过。512字符对技术文档来说确实太碎了，尤其术语类内容，上下文被切没了，embedding自然抓不准。可以试试按段落或语义边界切，配上一些overlap，1024其实不一定丢信息，反而语义更完整。reranker建议加，先用向量粗排召回20个再用cross-encoder精排，效果提升很明显。另外FAISS本身对语义区分能力有限，也可以顺手看看是不是embedding

FP16精度掉点很常见，试试在C2f那块强制走FP32，或者换onnxruntime先验证下onnx输出对不对。

几十万切片单机跑，pgvector其实真够用，别被带偏了。我们小团队就是Postgres加pgvector起步的，后面量涨了再迁Milvus或Qdrant也不迟，迁移主要就是重灌embeddings，没想象中痛。Milvus Lite当本地开发验证行，真上生产还是别省那点部署功夫。结构化信息我一般跟原文一起塞payload或者单开字段存，检索时当filter用，别只存裸文本。

这个坑我踩过，而且踩得还挺深的。单轮表现好不代表多轮下还能稳住，因为Agent框架会在你的prompt前面塞一堆system message、工具描述、历史对话，模型的注意力早就不在你那点格式约束上了。你调temperature和加prompt约束治标不治本，模型看到几千token的上下文，那个JSON格式的“惯性”很容易被冲散。我建议你先排查一下微调数据里有没有多轮场景的样本，如果3000条全是