1. Milvus 向量数据库
1.1 搜索模式详解
语义搜索（Semantic Search）
- 核心机制：基于向量嵌入（embedding）的相似性匹配
- 工作原理：使用深度学习模型（如 BERT、text2vec、OpenAI Embedding）将文本转换为稠密向量，然后计算向量之间的相似度（如余弦相似度、L2 距离）
- 优势：能处理同义词、语义相近但字面不同的表达
- 示例：查询"如何做蛋糕？"返回"烘焙甜点的步骤"（虽无"蛋糕"字眼，但语义相近）
- Milvus 实现 ：存储
FLOAT_VECTOR类型字段，使用client.search(..., anns_field="dense_vector")进行 ANN 搜索
全文检索（Full-Text Search）
- 核心机制：基于关键词或词项（term）匹配
- 工作原理：对文本分词，建立倒排索引，支持布尔查询、前缀、模糊匹配等
- Milvus 实现（2.3+） ：使用稀疏向量（
SPARSE_FLOAT_VECTOR）模拟倒排索引（如用 BM25 或 SPLADE 模型生成稀疏向量） - 优势：精确匹配关键词、支持通配符、对短语/术语敏感
- 劣势：无法理解语义（"手机" ≠ "移动电话"除非同义词扩展）
- 示例 ：查询
content like "%GPU%"或使用稀疏向量搜索含 "GPU" 的文档
混合搜索（Hybrid Search）
- 核心概念：同时结合语义搜索 + 全文检索（或关键词过滤）
- 目标：既保证语义相关性，又保留关键词精确性
- 实现方式 ：
- 稠密 + 稀疏向量融合：分别搜索稠密和稀疏结果，使用 RRF 或加权融合
- 向量搜索 + 标量过滤 ：先通过
expr筛选，再在结果子集上做语义搜索
- 适用场景：用户搜索 "iPhone 15 电池续航" → 既要"iPhone 15"（关键词精确匹配），又要"续航"相关语义内容
先过滤再检索 vs 先检索再过滤
- 先过滤再检索 ：使用
filter参数，Milvus 会在执行向量 ANN 搜索前，先用filter条件筛选出候选子集，只在这个子集上做向量相似性计算 - 优势：性能更优，特别是当过滤条件能大幅缩小搜索范围时
- 实现 ：
client.search(..., filter="field == 'value'")
1.2 API 差异与参数传递
MilvusClient API（新 API，2.4+）
-
初始化 ：
client = MilvusClient(uri="http://localhost:19530") -
搜索参数 ：
filter=而不是expr=search_params=而不是param=- 必须传
collection_name
-
调用示例 ：
python
1
2
3
4
5
6
7
8
9
results = client.search(
collection_name=collection_name,
data=[query_vector],
anns_field="content_vector",
search_params={"metric_type": "COSINE", "params": {"nprobe": 64}},
limit=5,
filter="source_document == 'doc_name'",
output_fields=["chunk_id", "content"]
)
Collection API（旧 API）
- 初始化 ：
client = Collection(collection_name) - 搜索参数 ：
expr=而不是filter=param=而不是search_params=- 不需要传
collection_name
- 参数顺序陷阱：避免同时通过位置参数和关键字参数传递同一参数导致冲突
参数传递冲突问题
- 根本原因：参数顺序混乱导致 SDK 内部将关键字参数误认为位置参数
- 常见错误 ：在
CollectionAPI 中错误地传入collection_name参数 - 解决方法：严格按照 API 规范调用，注意参数顺序
1.3 索引类型与性能优化
HNSW（Hierarchical Navigable Small World）
- 原理：类"高速公路+小路"的多层图结构，高层快速跳转，底层精细搜索
- 优势：查询快、召回率高、支持高并发
- 劣势：内存占用高、建索引慢
- 适合场景：高精度、低延迟要求（如推荐、语义搜索）
- 参数 ：
ef（搜索时考察的邻居数），越大越准越慢
IVF（Inverted File Index）
- 原理 ：先把向量聚成
nlist个簇，搜索时只查最近的nprobe个簇 - 优势：内存占用低（尤其 IVF_SQ8）、建索引快
- 劣势 ：
nprobe太小会漏结果、对分布不均的数据效果差 - 参数 ：
nprobe（搜索时查几个簇），越大越准越慢，最大 =nlist
ANN vs 精确搜索
- ANN 搜索：近似最近邻，速度快但可能不精确，依赖向量索引质量
- 精确搜索：暴力计算，100% 精确，但速度慢
- 选择策略：小数据集（如 < 1000 chunks）用精确计算更准确，大数据集用 ANN 需调优参数
2. Python 开发与环境管理
2.1 conda 环境复制策略
导出环境文件（推荐）
- 完整导出 ：
conda env export -n source_env > environment.yml - 跨平台兼容 ：
conda env export -n source_env --no-builds > environment.yml - 从文件创建 ：
conda env create -f environment.yml -n new_env_name
导出包列表（适合跨平台）
- 导出 conda 包 ：
conda list -n source_env --export > package_list.txt - 导出 pip 包 ：
pip freeze > pip_packages.txt - 安装 ：
conda install --file package_list.txt+pip install -r pip_packages.txt
直接克隆环境（最快）
- 命令 ：
conda create --name new_env_name --clone source_env - 优点：完全复制，包括所有包和版本
- 缺点：占用额外磁盘空间
2.2 Python 文件编码处理
编码声明
- 标准格式 ：
# -*- coding: utf-8 -*- - 位置要求：必须出现在文件的最开始，且不能有非 ASCII 字符出现在它之前
编码转换
- 工具 ：
iconv - 语法 ：
iconv -f source_encoding -t target_encoding input.txt > output.txt - 常见编码 ：
gbk、gb2312、iso-8859-1→utf-8
模块导入路径管理
- sys.path：Python 模块搜索路径列表
- 添加路径 ：
sys.path.insert(0, path_to_add) - 路径构造 ：
os.path.join(os.path.dirname(__file__), "relative_path") - 相对路径 vs 绝对路径：相对路径基于脚本位置，绝对路径固定
2.3 HTTP API 调用最佳实践
超时处理
- 设置超时 ：
requests.post(url, json=data, timeout=60)# 60秒 - 超时异常 ：
requests.exceptions.Timeout - 重要性：避免客户端无限等待，提高程序健壮性
错误类型区分
- 400 Bad Request：客户端发送的请求格式不正确，服务器无法处理
- 502 Bad Gateway：上游服务器作为网关未能及时获得有效响应
- 连接失败：无法建立到目标服务器的网络连接
连接管理
- HTTP/1.1 特性：请求-响应完成后连接自动断开
- 会话保持 ：使用
requests.Session()可以复用连接 - 网络连通性 ：使用
ping、telnet等工具测试
3. FastAPI 与 Web 服务
3.1 路由与 HTTP 方法
HTTP 方法定义
- @app.post()：处理 POST 请求，用于创建或更新资源
- @app.get()：处理 GET 请求，用于获取资源
- @app.put()：处理 PUT 请求，用于完整更新资源
- @app.delete()：处理 DELETE 请求，用于删除资源
路由参数
- 路径参数 ：
/items/{item_id} - 查询参数 ：
/items/?skip=0&limit=10 - 请求体参数：使用 Pydantic 模型定义
Pydantic 模型
- 请求模型：定义 API 输入数据结构
- 响应模型：定义 API 输出数据结构
- 类型验证：自动验证数据类型和格式
3.2 ASGI 服务器配置
Uvicorn
- ASGI 实现：异步服务器网关接口
- 启动命令 ：
uvicorn.run("module_name:app_name", host="0.0.0.0", port=8000) - 多进程 ：
--workers参数支持多进程部署
服务器配置
- host 参数 ：
0.0.0.0：监听所有网络接口127.0.0.1：仅监听本地回环localhost：本地访问
- port 参数：指定监听端口
- log_level：控制日志输出级别
3.3 无状态协议特性
HTTP 特性
- 请求-响应模式：每个请求独立处理
- 连接断开：响应完成后连接自动断开
- 无状态：服务器不保存客户端状态
多轮对话实现
- 请求体携带历史：将对话历史信息包含在每次请求中
- 会话 ID 机制：使用会话 ID 在服务端维护对话状态
- 客户端状态管理：客户端负责维护和传递对话上下文
4. PyTorch 与 GPU 计算
4.1 版本管理
稳定版 vs 开发版
- 稳定版：经过充分测试，API 稳定，适合生产环境
- 开发版：包含最新功能，可能不稳定，适合尝鲜
- 版本号含义 ：
2.4.0（稳定）vs2.10.0.dev20251208（开发）
CUDA 版本
- 命名规则 ：
cu121表示支持 CUDA 12.1，cu128表示支持 CUDA 12.8 - 兼容性：CUDA 版本需要与 GPU 驱动和硬件架构匹配
- 安装命令 ：
pip install torch --index-url https://download.pytorch.org/whl/cu121
4.2 GPU 使用策略
自动检测机制
- 优先使用 GPU：PyTorch 默认尝试使用 GPU
- 可用性检查 ：
torch.cuda.is_available() - 自动回退：无 GPU 时自动使用 CPU
设备管理
- 指定设备 ：
model.to('cuda')或model.to('cpu') - 设备检查 ：
torch.cuda.device_count()、torch.cuda.get_device_name() - 模型加载：模型加载时根据保存设备信息自动分配
5. Git 与版本控制
5.1 换行符处理机制
换行符类型
- LF（Line Feed） ：Unix/Linux/macOS 使用
\n - CRLF（Carriage Return + Line Feed） ：Windows 使用
\r\n
Git 配置
- core.autocrlf ：
true：提交时转换 CRLF 为 LF，检出时转换 LF 为 CRLFfalse：不进行转换
- .gitattributes：显式指定特定文件类型的换行符策略
.gitattributes 配置
- 文本文件 ：
*.txt text eol=lf - 二进制文件 ：
*.png binary - 统一策略：避免团队协作中的换行符混乱
5.2 提交操作详解
提交信息格式
- 第一行：简短标题（50字以内）
- 空行分隔：标题和详细描述之间空一行
- 详细描述：解释修改原因和影响
提交信息最佳实践
- 使用祈使句：如 "Fix bug" 而不是 "Fixed bug"
- 首字母大写：保持一致性
- 避免敏感信息：不要包含密码、密钥等
6. 网络与调试技术
6.1 网络连接诊断
连接测试工具
- ping：测试网络连通性
- telnet：测试特定端口是否开放
- curl：测试 HTTP 请求
网络配置检查
- IP 地址：确认服务端 IP 地址
- 端口映射：确认端口是否正确映射
- 防火墙规则：检查防火墙是否阻止连接
6.2 调试策略
日志输出
- 调试信息 ：使用
print()输出关键变量值 - 日志级别：DEBUG、INFO、WARNING、ERROR
- 结构化日志：使用日志库进行格式化输出
异常处理
- 捕获异常 ：使用
try-except块 - 异常类型：区分不同类型的异常
- 错误恢复：实现错误后的恢复机制
7. 软件架构与设计模式
7.1 微服务通信
远程 API 调用
- 计算位置：计算在远程服务端执行
- 数据传输：通过网络传输请求和响应
- 服务解耦：各服务独立部署和扩展
本地计算 vs 远程计算
- 本地计算：模型在本地加载，计算在本地执行
- 远程计算：通过 API 调用远程服务，计算在远程执行
- 性能权衡：本地延迟低但资源占用高，远程资源集中但网络延迟
7.2 配置管理
环境变量
- 配置外部化：避免硬编码配置信息
- 环境隔离：不同环境使用不同配置
- 安全性：敏感信息通过环境变量传递
配置文件
- YAML/JSON：结构化配置格式
- 版本控制：配置文件纳入版本管理
- 动态加载：运行时动态加载配置
7.3 性能优化策略
批处理
- 减少网络请求：批量处理多个数据项
- 内存效率：合理设置批次大小
- 负载均衡：避免单次请求过大
缓存机制
- 结果缓存：缓存计算结果避免重复计算
- 模型缓存：缓存已加载的模型
- 数据缓存：缓存频繁访问的数据