从0.63到0.89：一次RAG检索增强生成系统的调优记录
本文记录了一个企业知识库RAG系统从上线到调优的完整过程。初始版本Top-5命中率仅0.63，答案幻觉率高达22%。通过将固定长度切分改为语义+递归混合chunk策略、把embedding从text-embedding-ada-002切换到bge-large-zh-v1.5、并引入bge-reranker-large重排，最终Top-5命中率提升到0.89，幻觉率降到6%，P99延迟控制在1.4s
React 19与Vue 3.5跨框架状态管理迁移实录：从Prop Drilling到Pinia/Zustand的蜕变
当项目膨胀到230+组件、状态散落于12层Props与8个Context时，每次需求迭代都成噩梦。本文记录一个双框架（React 19.0.0 + Vue 3.5.13）项目中，将状态管理从Context/Props迁移至Zustand 5.0.2与Pinia 2.2.6的完整历程。通过对比迁移前后性能（渲染耗时降低57%、包体积仅增8KB、代码删除量达2400行），并拆解迁移策略、兼容层设计及3
React 16与Vue 3项目从Props drilling迁移到Zustand/Pinia的完整记录
在维护两个分别基于React 16.8和Vue 3.2的中后台项目时，组件层级超过5层后Props透传导致代码冗余率高达40%，且因Context触发全树重渲染导致列表页交互帧率降至20fps。本文记录了迁移到Zustand 4.3和Pinia 2.1的决策过程、分步迁移方案，以及迁移后首屏渲染时间缩短28%、重渲染次数减少67%的实测数据。适合正被状态管理混乱困扰的团队参考。
FastAPI慢查询根因追踪：Profiling与Redis缓存双层优化实录
一个生产环境接口P95延迟从820ms降至97ms，吞吐量提升4.6倍。文章记录了FastAPI服务遭遇的典型性能陷阱——SQLAlchemy懒加载导致的N+1查询及高并发下的缓存击穿。通过cProfile与Py-Spy定位热点，采用`selectinload`策略批量加载关联数据，并引入Redis分布式锁与多级缓存架构。实测数据：首字节时间(TTFB)降低88%，数据库QPS从2100降至340
React 19与Vue 3.5跨框架状态管理迁移实录：从Props钻透到Zustand 5与Pinia 3
当组件树超过5层，Context触发重渲染的代价是每次状态更新导致约40%无关组件重新执行render。本文记录了一个双框架项目（React 19.1 + Vue 3.5）从Props/Context迁移至Zustand 5.0.6与Pinia 3.0.3的完整过程。通过自研的`useSyncExternalStore`桥接层与Pinia的`setup store`，实现了在保留现有业务代码前提下
RAG召回率从61%到89%：chunk重构与Embedding选型全记录
一个月前，我们内部知识库问答系统的准确率卡在61%，用户问“A类设备保修政策”，系统总召回一段关于B类设备报废流程的废话。经过对chunk切分策略的三轮调整、Embedding模型从bge-small切换至bge-m3，再引入BGE-reranker-v2-m3后，最终在1287条真实测试集上，Recall@5从61.2%提升至89.4%，答案相关度人工评分从3.1分升至4.5分。本文记录完整优化
向量数据库选型：Milvus与Qdrant在RAG场景下的性能对决
在搭建千万级向量检索的RAG知识库时，Milvus和Qdrant是两大热门选手。本文基于Intel i5-13400 + 32GB内存的裸机环境，分别部署Milvus 2.4.1（Docker Compose）与Qdrant 1.9.7（单机二进制），使用768维CLIP向量、100万条真实图片元数据，对比了写入吞吐、P99查询延迟及内存占用。实测结果显示：Qdrant在过滤查询（带标量过滤）时P
Prompt模板迭代实录：从42%到91%的抽取准确率跃升
金融研报实体抽取任务中，初版Prompt准确率仅42%，经五轮结构化迭代（含few-shot示例优化、格式约束、Token预算控制），最终在120条测试集上达到91%准确率，单条推理成本从0.083元降至0.047元。本文记录完整实验过程、每个版本的Prompt差异、OpenAI/GPT-4o-mini与DeepSeek-V3的对比数据，以及一个关于“思维链长度惩罚”的隐藏坑。
Prompt工程化调优实录：实体抽取任务从57%到92%的跃迁
在构建知识图谱实体抽取管线时，我以GPT-4o-mini为基座，通过7轮Prompt迭代将F1分数从0.57提升至0.92。全程记录零样本、Few-shot、结构化指令与自纠错机制下的输出差异，实测token消耗从单次412涨至689（+67%），但有效输出率提升2.3倍。文中包含可复现的LangChain调用代码、JSON Schema约束写法及反例分析，供NLP工程化场景参考。
LoRA微调7B中文医疗问答模型全记录：从loss震荡到推理效果提升38%
在消费级显卡（RTX 3090 24G）上，我用LoRA微调了Qwen2-7B-Instruct，目标是让它能回答专业中医方剂问题。基线模型准确率仅52.3%，经过单卡3小时训练（batch_size=4，lr=2e-4，rank=8），准确率提升到72.1%，且推理速度几乎无损。本文记录整个实践过程：数据清洗时发现“标签污染”问题、训练中loss在step 2000后剧烈震荡的排查、以及最终通过
LangChain 0.3手写AI Agent：工具调用与记忆管理全拆解
本文用180行代码实现一个可运行的AI Agent，基于LangChain 0.3.7与OpenAI gpt-4o-mini模型，覆盖工具定义（含@tool装饰器与pydantic v2 schema）、记忆管理（BufferMemory + 滑动窗口裁剪）、错误重试（指数退避）与循环控制（max_iterations=5）。实测在“查询北京天气并计算温差”任务上，工具调用准确率92%，平均响应时
Prompt工程化调优实录：从42%到91%的SQL生成准确率跃迁
本文记录了一次针对Text-to-SQL任务的Prompt迭代全流程。通过5轮结构化实验，对比了零样本、Few-shot、思维链及格式约束等6种Prompt模板，在Spider数据集子集上完成评测。实验发现，引入数据库Schema感知指令与错误修复示例后，模型输出可执行率从42%提升至91%，单次推理Token消耗增加18.7%，但重试成本下降76%。文中包含完整代码与Token成本核算，为NL2
RAG系统三阶优化实录：分块、Embedding与Rerank的量化调优
在面向企业私有文档的问答项目中，RAG系统初始召回准确率仅62%。通过将固定256字符分块改为自适应Markdown结构分块（合并代码块与表格），Recall@5提升至71%；将BGE-large-zh（1024维）切换为GTE-Qwen2-7B-instruct（通过FlagEmbedding封装为3584维），Recall@5再涨至79%；最后引入bge-reranker-v2-m3进行二次重
asyncio重构Flask接口：Web API并发量提升3倍实录
一个内部报表接口因串行调用3次外部HTTP服务，在QPS达到200时平均延迟飙升到3.8秒，生产环境频繁告警。本文记录了使用Python 3.11 + asyncio + aiohttp对该接口进行IO密集优化全过程。通过引入`asyncio.gather`并发调用外部服务，将接口P95延迟从2.9秒降至0.9秒，API吞吐量从180 RPS提升至540 RPS。文中包含完整before/afte
Docker Compose编排三层应用：网络隔离、健康检查与依赖启动实战
本文记录一个真实项目从单机docker run到Compose编排的改造过程。服务包含Nginx网关、Spring Boot后端（初始内存占用850MB）和PostgreSQL 14（数据卷已达12GB）。通过Compose文件实现：自定义bridge网络隔离、bind mount热部署、基于healthcheck的启动依赖控制，将部署时间从手动敲命令的15分钟缩短至一条命令的90秒，并解决了困扰
7B模型LoRA/QLoRA微调实录：显存从24G降到6G的工程化实践
在业务语义理解任务中，直接微调ChatGLM2-6B需要约24GB显存（batch_size=16, seq_len=512），而使用QLoRA（4-bit NormalFloat + Double Quantization + PEFT）后，显存占用降至6.2GB，训练速度仅下降18%。本文记录从数据清洗到loss收敛的全过程，包含两次OOM的排查与解决，以及LoRA rank=8 vs ran
Prompt工程四轮迭代实录：从45%到92%的抽取准确率跃迁
本文记录了我用GPT-4o-mini完成“法律判决文书关键信息抽取”任务时，对Prompt进行四轮迭代的完整过程。基线Prompt准确率仅45%，通过引入结构化输出、Few-shot示例、自洽性校验和角色约束，最终在200条测试样本上将字段级F1从0.52提升至0.91，单条token消耗从1847降至632。文中包含每个版本的完整Prompt代码、OpenAI SDK调用细节、失败案例分析及成本
asyncio重构Flask接口：Web API响应时间从2.1s降至0.3s
在生产环境遇到一个棘手的性能问题：一个聚合多个上游HTTP服务的订单查询接口，平均响应时间高达2.1秒，P99直接飙到4.5秒。业务方天天催，DBA说SQL没问题，上游说服务正常。排查后发现瓶颈在串行的HTTP调用上——三次外部请求依次执行，每个耗时600-700ms。用Python 3.8的asyncio配合aiohttp重写核心逻辑，将串行IO切换为并发协程，接口P95从2.4s降到0.32s
Prompt工程调优实录：从3.2%到91.4%的指令抽取F1提升
在构建一个基于GPT-4o-mini的电商评论信息抽取系统时，我经历了从“能跑”到“能用”的Prompt调优全过程。初期零样本Prompt的F1仅3.2%，经过结构化指令、少样本示例与格式约束的三轮迭代，最终在200条测试集上将F1提升至91.4%，单条token消耗从412降至295。本文将公开完整的Prompt版本演进、消耗对比与踩坑记录，包含可直接运行的Python评测脚本，适合正在用LLM
React 19与Vue 3.5下从Props钻取到Zustand/Pinia的状态迁移实录
项目从16个组件层层透传props到引入Zustand 5与Pinia 3，重构后组件重渲染次数平均下降73%，首屏交互响应时间从210ms降至95ms。本文记录了在React 19.2与Vue 3.5.17双技术栈下，从Context/Props方案迁移至状态管理库的完整决策树——包括何时该无痛迁移、zustand的selector陷阱、Pinia的setup store与组合式API的冲突处理
