Jacin Blog

AI 大模型开发

分类下的全部文章

稀疏向量检索流程
AI 大模型开发
26 分钟

稀疏向量检索流程

这是一篇面向中文 RAG 原型实现的稀疏检索流程拆解，围绕“切块、分词、构建 BM25 索引、查询打分”串起完整链路。正文用 Python 示例演示如何借助 RecursiveCharacterTextSplitter 控制 chunk_size、chunk_overlap 和分隔符优先级，用 jieba 处理中文分词，再通过 rank_bm25 构建 BM25Okapi 索引并返回 Top-N 检索结果。文章进一步展开 BM25 内部保存的 idf、doc_freqs、doc_len、avgdl 等统计量，说明 IDF 是基于全部 chunks 的全局逆文档频率，文档侧权重包含 TF 饱和与长度归一化，而查询侧通常按 IDF 与查询词频生成稀疏向量。示例还展示了“苹果手机最新功能”能够命中包含相同词汇的 chunk，却无法匹配语义相关但字面不同的 “iPhone 16 Pro Max”，由此揭示 BM25 作为词汇匹配方法在同义词和近义表达上的天然短板。对于工程选型，正文区分了 rank_bm25 的内存线性扫描特性与 Elasticsearch、Milvus 等生产级倒排索引方案，并指出前者适合小规模验证，后者更适合大规模、增量更新和低延迟检索。最后通过传统 BM25 与 Learned Sparse 的对比，帮助读者理解可解释统计检索、神经稀疏检索和稠密检索在 Hybrid RAG 中各自的定位，适合正在搭建中文知识库检索、调试召回效果或评估 RAG 检索架构的开发者阅读。

向量
AI 大模型开发
8 分钟

稠密向量 与 稀疏向量

这篇笔记从 RAG 检索质量出发，解释文本向量化时常见的稀疏向量与稠密向量两条路线：前者维度通常等于词汇表规模，只有少量非零值，代表方法是 BM25 和 TF-IDF；后者维度较低但几乎每一维都有实数值，常由 BERT、BGE、OpenAI Embedding 等模型生成。内容重点说明 BM25 只基于已分词后的 token 计算 TF、IDF 和文档长度分数，本身不负责分词，因此中文、日语、泰语、阿拉伯语、德语复合词等场景会受到分词或形态处理质量影响。稠密向量部分则说明 Embedding 模型通过对比学习把语义相近文本拉近、语义不同文本推远，并列出余弦相似度、点积、欧氏距离等常见匹配方式。对比部分强调稀疏检索适合专有名词、数字和明确短语，解释性强且对精确关键词敏感；稠密检索更适合自然语言和模糊语义查询，但可能在稀有词、精确匹配和算力成本上存在短板。实践建议落在混合检索：并行使用 BM25 与 Embedding 召回，再通过 RRF 等方法融合排序，借助 Milvus、Qdrant、Weaviate 等向量数据库实现更稳健的 RAG 检索链路。

向量
使用 attu 创建向量数据库
AI 大模型开发
8 分钟

使用 attu 创建向量数据库

这篇操作笔记围绕在 Attu 中创建 Milvus Collection 展开，把 RAG 知识库建表时容易混在一起的字段设计、索引配置和检索参数拆开说明。正文先以 FloatVector(1024)、VarChar text 和 JSON metadata 为核心字段，解释向量维度必须与 Embedding 模型输出一致，原文文本用于最终回填给 LLM，元数据则服务于按文档、时间等条件做标量过滤。检索部分重点说明 COSINE 余弦相似度适合文本语义搜索，并区分相似度越大越相关、距离或 radius 越小越严格的参数含义，避免在 Milvus 查询时误解阈值方向。索引配置选择 HNSW，并解释 M=16 与 efConstruction=128 分别影响邻居连接数、内存占用、构建速度和查询准确率。文章还对比 Collection 与 Partition 的层级关系：前者类似表并定义统一 Schema，后者是在集合内按业务或时间切分数据，用于缩小搜索范围和控制内存加载。最后补充 Bounded 一致性在写入可见性与吞吐之间折中，以及 Dense、Sparse 和 Hybrid Search 如何把语义检索与关键词权重结合起来提升召回，适合正在搭建 Milvus RAG 数据库的开发者参考。

AI 大模型开发
11 分钟

RAG 架构的认识

这篇笔记把 RAG 从离线索引到在线回答拆成一条完整工程链路，关注的不是概念定义，而是每个环节如何影响召回准确率、响应速度和幻觉控制。数据准备部分强调先做 ETL 清洗，再选择合适的分块策略，并通过元数据记录来源、页码、日期、章节等结构化信息，让后续检索既能依赖向量相似度，也能进行更可靠的过滤。文章特别提醒入库和查询必须使用一致的 Embedding 模型与参数，并用 HNSW 解释向量索引为什么会带来“入库慢、查询快”的取舍。在线阶段则覆盖查询改写、子问题拆解、混合检索和 RRF 融合，说明向量检索适合语义相近内容，而关键词检索更适合型号、人名、缩写等精确信息。排序与生成部分进一步引入 Rerank、阈值过滤和上下文去噪，用更高成本的精排模型提升候选 Chunk 质量，并在低相关度时返回“不知道”以避免强行编造。最后通过 Prompt 约束和引用溯源把答案限制在检索上下文内，适合正在搭建或优化知识库问答系统、希望从“能检索”推进到“可解释、可调优、可追溯”的 AI 应用开发者。

rag
AI 大模型开发
7 分钟

CPU 跑 Rerank 太慢？一个脚本开启 INT8 量化，性能大幅度提升！

面向企业级 RAG 系统中在 CPU 服务器部署 HuggingFace text-embeddings-inference Rerank 的场景，内容聚焦默认 FP32 ONNX 模型推理慢、CPU 利用率不高的问题。文章先用 FP32 与 INT8 的数据宽度差异解释瓶颈来源：全精度权重占用更多内存带宽和计算资源，而 Rerank 更关注排序相对结果，适合通过量化降低推理成本。随后结合 AMD EPYC、Intel Xeon 等现代 CPU 的 AVX-512/VNNI 能力，说明 INT8 在 SIMD 并行吞吐和内存占用上的优势，并给出理论上更高并发处理能力的原因。实践部分提供了基于 optimum.onnxruntime 的动态量化脚本，将 bge-reranker-v2-m3 的 FP32 ONNX 文件转换到 quantized 目录，并使用 avx512_vnni 配置面向 CPU 推理优化。脚本中特别处理了 TEI 启动所需的 tokenizer、config 等文件复制，以及将 model_quantized.onnx 重命名为 model.onnx 的兼容性细节。最后只需在 docker-compose.yml 中把 rerank 模型挂载路径切换到 quantized 目录，TEI 镜像无需更换即可加载 INT8 模型，适合需要在现有 CPU 资源上提升 Rerank 吞吐的 RAG 开发和运维人员参考。

AI 大模型开发
7 分钟

tei-rerank 部署重排模型bge-reranker-v2-m3

这份记录聚焦在用 Hugging Face Text Embeddings Inference 的 CPU 镜像部署 BAAI/bge-reranker-v2-m3 重排模型，场景是为检索结果增加一个独立的 rerank 服务，而不是普通 embedding 服务。流程先通过 snapshot_download 将模型完整下载到本地目录，再安装 optimum、onnx、onnxruntime，并用 ORTModelForSequenceClassification.from_pretrained(export=True) 将 PyTorch 模型导出到模型目录下的 onnx 子目录，同时保存 tokenizer。docker-compose 配置的关键点包括使用 ghcr.io/huggingface/text-embeddings-inference:cpu-1.5，挂载本地模型目录到 /data/rerank，开放 38190:80 端口，并通过 --model-id 指向容器内路径，配合 --auto-truncate 和 --dtype float32 启动服务。文章特别强调 shm_size: 1g 的必要性，因为 Docker 默认共享内存只有 64MB，AI 推理程序在并发或大矩阵数据传输时可能因共享内存不足直接 Bus error 崩溃。最后用 /rerank 接口测试“我想买一个手机”与三星、苹果、联想笔记本三段文本的相关性排序，结果显示手机相关文本得分约 0.3，而笔记本得分接近 0.0001。读者可以从中获得一套可复现的 TEI rerank 部署步骤，并理解重排模型更应关注候选项之间的相对差距和排序效果，而不是孤立解读绝对分值。

AI 大模型开发
2 分钟

本地部署 ollma+ qwen 7B大模型

这是一份面向本机 Docker 环境的 Ollama 部署记录，目标是在本地启动可调用的 Qwen2.5 大模型服务，并通过接口验证生成能力。正文给出 docker-compose.yml 的核心配置，包括 11434 端口映射、./ollama_data 持久化模型数据、容器自动重启，以及 OLLAMA_KEEP_ALIVE、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_LOADED_MODELS、OLLAMA_ORIGINS 等运行参数。资源部分显式限制容器最多使用 18G 内存，同时用常驻内存、4 路并发和最多加载 2 个模型来平衡响应速度与本机资源占用。模型操作通过 docker exec 进入 ollama 容器执行 ollama run qwen2.5:7b，也补充了 qwen2.5:14b 的可选尝试，并提示 14B 的 4bit 量化大约需要 9GB 内存。文章还区分了模型文件存放在硬盘与按请求 model 参数加载到内存的行为：请求 7B 会加载 7B，请求 14B 时可能卸载 7B 再加载 14B。最后用 curl 调用 http://localhost:11434/api/generate，指定 qwen2.5:7b、prompt 和 stream 参数，作为部署是否可用的最小验证，适合需要快速搭建本地中文大模型 API 的开发者参考。

AI 大模型开发
7 分钟

搭建tei-embedding 与配置bge-m3 文本模型

这篇笔记聚焦于将 BAAI/bge-m3 文本向量模型部署为本地 Hugging Face TEI embedding 服务，适用于需要离线或内网提供语义向量接口的检索、RAG 和相似度计算场景。流程先用 huggingface_hub 的 snapshot_download 下载模型到指定绝对路径，并特别设置 local_dir_use_symlinks=False 以保存真实文件，同时启用断点续传，避免 Docker 挂载后因软链接或缓存路径导致模型不可用。部署部分给出 Docker Compose 配置，使用 ghcr.io/huggingface/text-embeddings-inference:cpu-1.5 镜像，将宿主机模型目录挂载到容器 /data/bge-m3，并通过 --model-id 指向该路径触发离线加载。配置中还清空代理环境变量、设置 no_proxy=*，并指定 cls pooling、最大客户端 batch size 为 32、dtype 为 float32，强调在 CPU 版本下以稳定可用为目标。验证环节先通过 curl 调用 127.0.0.1:8080/embed，若返回一组浮点向量即可确认容器、端口、模型加载和推理链路正常；若出现 Connection refused，则优先检查容器是否启动和端口映射。最后用 requests 调用接口、NumPy 计算三句话向量的余弦相似度，结果显示“男人吃苹果”和“吃水果”的相似度高于与“天气”的相似度，从语义区分能力上确认服务可用于后续文本向量化任务。

部署milvus 向量数据库与可视化attu
AI 大模型开发
11 分钟

部署milvus 向量数据库与可视化attu

这份笔记记录了用 docker-compose 搭建 Milvus Standalone 向量数据库及 Attu 可视化界面的完整过程，场景是已有或单独部署 MinIO 后，将 Milvus、Etcd、Attu 接入同一个外部 Docker 网络。配置部分分别给出 MinIO 的端口、数据卷和 root 账号密码设置，以及 Milvus v2.5.0 连接 Etcd、外部 MinIO、指定 bucket、暴露 19530 与 9091 端口的 compose 示例，同时提醒需要按实际情况修改 MINIO_ACCESS_KEY_ID 和 MINIO_SECRET_ACCESS_KEY。文章特别记录了启动时因鉴权配置导致报错的处理路径：先 down 掉容器、删除旧 milvus.yaml，下载官方 v2.5.0 配置文件后将 authorizationEnabled 从 false 改为 true，再重新 docker compose up -d。Attu 通过 MILVUS_URL 指向 standalone:19530，并将 Web UI 映射到 8000 端口；Milvus 开启鉴权后的默认账号为 root，默认密码为 Milvus，登录后可在界面中修改密码。后半部分用“计算中心、对象仓库、元数据记账本、前台界面”的分工解释 milvus-standalone、MinIO、Etcd 和 Attu 的职责，强调向量数据与索引主要落在 MinIO，集合结构和文件归属依赖 Etcd。它适合需要快速搭建本地或服务器端向量数据库实验环境、并希望理解各容器依赖关系和持久化风险的开发者参考。

langfuse追踪Trace
AI 大模型开发
14 分钟

langfuse追踪Trace

这篇笔记聚焦 Langfuse 在 LLM 应用中的调用追踪用法，适用于 OpenAI、LangChain 或自定义 Agent 这类需要观测请求链路的场景。正文先把 Langfuse 定位为面向大模型应用的 observability 平台，说明它可以记录一次调用的上下文、输入输出、耗时、错误、Token 成本、评分注释，并通过 Web UI 辅助分析。核心概念上，Trace 被解释为一次完整用户请求的顶层调用上下文，Span 则是 Trace 内部的子步骤，可以对应 OpenAI 调用、工具函数、向量检索或其他业务动作，并拥有自己的 start/end 生命周期。实现部分给出 Python 封装示例：通过环境变量初始化 Langfuse 客户端，创建 trace 与 span，在调用前写入 messages 作为 input，在调用结束后用 span.end 和 trace.update 记录最终 output。文章特别强调流式 GPT 响应默认不方便自动捕捉完整输出，因此需要在异步迭代 chunk 时用字符串累积 full_response，再把完整结果写回 Langfuse；异常路径则记录 error 后继续抛出。读者可以借此理解如何为自定义流式聊天接口补上可视化追踪、性能排查、错误定位和后续评估所需的数据基础。