Prompt模板迭代实录：从42%到91%的SQL生成准确率跃升
在Text2SQL任务中，我通过5轮Prompt模板迭代，将GPT-4(0613)的SQL生成准确率从42%提升至91%。实测对比了零样本模板、Few-shot模板与结构化约束模板的差异，发现token消耗从每查询1837降至1142，而输出质量（执行通过率）提升118%。本文记录了包含错误类型分析、系统提示词设计、JSON模式约束在内的全套调优路径，附带完整的Python评估脚本和成本计算公式。
Docker Compose编排实践：多服务依赖控制与健康检查全解析
本文记录一个真实电商后台系统的容器化部署改造过程。项目包含Nginx网关、Spring Cloud Gateway、认证服务、订单服务、Redis与MySQL共6个服务，通过Docker Compose v2.20.2编排，解决了服务启动顺序失控、MySQL初始化脚本重复执行、网络隔离不彻底三个核心问题。改造后服务平均启动时间从原来的45秒缩短至28秒，容器重启恢复时间控制在5秒内。文中提供完整可
Docker Compose编排多服务项目：网络卷健康检查与启动顺序全解析
一个典型的微服务项目，后端API、前端Nginx、Redis、PostgreSQL、消息队列，五个服务手工启动耗时超过10分钟，且经常因依赖未就绪导致崩溃。改用Docker Compose 2.24编排后，启动时间压缩至45秒，健康检查失败自动重启，数据卷持久化零丢失。本文从一个真实电商后台项目出发，完整拆解docker-compose.yml的编写过程，覆盖自定义网络、命名卷挂载、healthc
RAG问答延迟降低42%：chunk重构与bge-reranker重排实践
线上RAG系统在2000份PDF知识库上问答准确率仅61%，Top-5召回命中率78%但答案幻觉严重。通过将固定512字符chunk改为语义段落+滑动窗口（chunk_size=384, overlap=64），Embedding从text2vec-large切换至bge-large-zh-v1.5，并引入bge-reranker-base二次重排，最终准确率提升至87%，首token延迟从1.8
LangChain手写Agent循环控制与记忆管理，AutoGPT架构降本60%
团队在构建知识库问答Agent时，直接调用LangChain的AgentExecutor导致单次任务成本超$0.8且频繁死循环。通过手写一个仅300行的Agent循环，配合自定义工具注册表和滑动窗口记忆，将单次任务成本降至$0.12，响应时间缩短43%。本文将拆解LangChain v0.2.3与AutoGPT的架构差异，并给出工具定义、错误恢复、记忆压缩的完整实现代码，适用于需要精确控制LLM调
7B模型LoRA/QLoRA微调实录：显存从80G降到24G的优化与loss曲线分析
上周尝试用QLoRA微调Llama-2-7B，在单张RTX 4090（24G显存）上完成中文医疗问答任务。对比全参微调（需80G A100）与LoRA（48G），QLoRA将显存压到19.8G，训练速度仅慢38%。本文记录了从数据清洗到推理部署的完整链路——包括4bit NF4量化配置、paged_adamw_8bit优化器参数、以及一组有趣的loss曲线：在2000步时出现“假收敛”现象，通过调
React 19与Vue 3.4项目从Props钻取到Zustand/Pinia迁移实录
一个管理后台从React 16 Context过渡到Zustand 4.5，以及另一个Vue 3.4项目从Props钻取迁移到Pinia 2.1的完整记录。文中对比了两种方案的优劣，给出了具体的迁移步骤和代码diff，并附带了迁移前后的性能对比数据：React项目组件重渲染次数从平均27次降为9次，Vue项目Props传递链缩短了4层，页面交互延迟从210ms降到95ms。文中也记录了迁移中遇到的
Prompt模板迭代实录：从3.2%到87%的JSON抽取精确率跃升
在构建企业级知识图谱时，非结构化文本的实体关系抽取曾让我的准确率卡在3.2%。通过五轮Prompt工程迭代——从零样本指令到角色扮演+思维链+Few-shot组合，我最终将GPT-4o-mini的F1分数从0.41提升至0.87，同时将单次调用token消耗从1864降至793。本文记录完整的实验设计、对比数据、失败案例及最终模板，包含可复现的LangChain调用代码与成本计算。
Docker Compose编排多服务容器化部署：网络、健康检查与启动顺序实战
本文记录一次基于Docker Compose v2.24.2编排一个包含Nginx 1.25、Spring Boot 3.2.0、PostgreSQL 16.1和Redis 7.2三个服务的完整过程。通过自定义bridge网络、Bind Mount卷挂载、基于healthcheck的依赖控制，最终将服务启动时间从手动docker run的12分钟缩短至一条命令的3分40秒，并解决了容器重启后IP变
7B模型LoRA微调实录：显存8G→6.2G的QLoRA榨干每一兆显存
本文记录基于ChatGLM3-6B的LoRA/QLoRA微调全过程。通过bitsandbytes的4bit NF4量化+LoRA（秩=8，alpha=16），将单卡显存需求从全参微调的84G压至6.2G，在单张RTX 3090上完成医疗问答任务微调。训练3个epoch后，BLEU从13.8提升至22.4，但发现灾难性遗忘问题——通用能力下降11.7%。文中给出完整的量化配置、训练脚本、loss曲线
Python异步重构：用asyncio把Web API响应时间从900ms压到150ms
负责的订单查询接口在压测时P99延迟飙到900ms，数据库连接池被打满，CPU却只用了12%。在Python 3.10环境下用asyncio+httpx重构了第三方API调用链，把串行阻塞I/O改成并发协程，配合信号量限流和连接复用，最终P99降到147ms，QPS从320提升到2100。文章记录了完整的before/after代码、压测数据以及四个真实的踩坑点（包括asyncio.run的隐藏坑
Prompt工程化调优实录：从7.2分到9.1分的RAG问答系统
在构建基于GPT-4o-mini的RAG知识库问答系统时，我发现同样的检索结果，仅因Prompt设计不同，最终答案的准确率从62%飙升到89%。本文记录了针对“多文档冲突信息处理”这一具体任务的12组Prompt对比实验，包含token消耗从平均814到1560的变化曲线，以及最终采用的“三层结构+角色约束+格式锚定”方案。文中所有代码和版本均来自实际生产环境（Python 3.11.4，Lang
RAG系统优化实录：chunk策略、Embedding切换与Rerank引入的收益分析
在搭建企业知识库问答系统时，我们遇到了一个典型问题：当文档量突破5000份、切片超过4.2万个时，Top-5召回准确率从88%骤降至67%，用户明显感觉到答案“答非所问”。本文记录了从chunk_size=512到多策略混合切片的调整过程，以及从bge-large-zh-v1.5切换至Qwen3-Embedding-0.6B、再引入bge-reranker-v2-m3后的完整对比实验。最终，Rec
RAG系统三阶优化实录：chunk重构与embedding切换及rerank融合
检索增强生成（RAG）系统在私有知识库问答中常面临“召回不准、生成幻觉”的双重困境。本文记录一次针对客服工单知识库的完整优化过程，涉及文本分块（chunk）策略从固定256字符到语义段落的转变、Embedding模型从`text2vec-large-chinese`到`bge-large-zh-v1.5`的升级，以及引入`bge-reranker-v2-m3`进行重排。最终，在内部评测集（500道
FastAPI服务压测502ms到89ms：SQLAlchemy查询与Redis缓存调优全记录
接手一个FastAPI + PostgreSQL的订单查询服务，压测发现P95延迟高达502ms，QPS只有382。通过py-spy定位到90%时间耗在SQLAlchemy ORM懒加载和N+1查询上；改用`selectinload`预取关联表后，P95降到217ms；再引入Redis缓存热点订单数据，配合`cachetools`做进程内二级缓存，最终P95稳定在89ms，QPS提升到2100+。
FastAPI接口耗时3370ms降至89ms：Profile与缓存调优全记录
生产环境某订单聚合接口在QPS 80时P99延迟飙至3370ms，经py-spy与SQLAlchemy慢日志定位，发现N+1查询占60%开销、Redis未利用且存在重复计算。通过联合加载、LruCache与Redis二级缓存三层优化，配合Gunicorn+Uvicorn多Worker部署，最终将P99降至89ms，吞吐量提升4.2倍。本文记录完整排查链路，附可复现代码与压测数据。
RAG准确率从62%到89%：chunk重切与embedding选型及rerank实践
线上一个基于LangChain的客服问答RAG系统，初期使用固定512字符切分、OpenAI text-embedding-ada-002，在1278条内部评测集上HitRate仅62%，且答案幻觉频发。本文记录了为期三周的优化全过程：通过中文语义感知的递归切分策略、切换至BAAI/bge-large-zh-v1.5并进行有监督领域微调，以及引入bge-reranker-v2-m3进行二次排序，最
Prompt工程化调优实录：从47%到89%的抽取准确率跃迁
在医疗文本结构化任务中，我通过系统性迭代12版Prompt，将实体抽取F1值从0.47提升至0.89，单次调用token消耗从1847降至623。本文记录了完整的实验矩阵——从零样本指令到Few-shot思维链，包含温度系数、分隔符、输出JSON约束等7个变量的控制变量测试。特别对比了ChatGPT-4-turbo与Claude-3.5-sonnet在同一套Prompt下的性能差异，最终沉淀出一套
Prompt编排四轮迭代：信息抽取任务从52%到91%准确率
文本结构化抽取是RAG落地的第一道坎。本文以“招标公告关键字段抽取”为实验场，对比零样本、角色约束、思维链与自一致性校验四类Prompt在gpt-3.5-turbo-1106上的表现。实验显示，仅靠“你是专家”式约束只能提升4个百分点；引入“先找边界再填字段”的分步指令后，F1从0.61跃升至0.78；最终通过Few-shot示例对齐输出格式并加入结果自检，准确率稳定在91.2%，单条Token消
Milvus与Qdrant选型实测：千万级向量检索下的部署与资源博弈
在电商以图搜图业务中，面对1000万条768维向量，Milvus 2.4与Qdrant 1.9在同等硬件下表现迥异。Milvus靠Knowhere索引库在查询延迟上胜出（P99 12ms vs 18ms），但Qdrant的Rust底层将内存占用压低了近40%。本文给出双系统的Docker Compose部署、压测脚本及调参全过程，并曝光一个Milvus的段文件合并坑——不处理的话，写入吞吐会直接腰
