1. 大模型应用开发的技术栈演进与面试趋势
最近两年，大语言模型（LLM）技术正在以惊人的速度重塑AI应用开发的格局。从最初的简单Prompt工程，到如今的复杂RAG系统构建和多Agent协同工作，开发者技术栈的迭代速度远超想象。作为一名长期深耕AI工程化落地的从业者，我深刻感受到这个领域的变革正在加速。
在最近的面试和技术交流中，一个明显的趋势是：面试官不再满足于候选人背诵Transformer原理或Attention公式，而是更看重解决实际工程问题的能力。具体表现在：
- 工程化思维：如何将学术论文中的算法转化为可落地的生产系统
- 技术选型能力：面对琳琅满目的框架和工具链，如何做出合理选择
- 异常处理经验：在真实业务场景中遇到的各种"脏数据"如何处理
举个例子，当面试官问到"如何处理PDF中的复杂表格"时，他们期待的不仅是一个技术名词，而是完整的解决方案设计：从文档解析、表格识别到结构保留和检索优化的全链路思考。
2. RAG系统构建的核心挑战与解决方案
2.1 文档解析与预处理流水线
构建生产级RAG系统的第一个拦路虎就是文档预处理。以最常见的PDF为例，我们需要处理以下典型问题：
版面分析难题：
- 双栏排版的学术论文
- 包含页眉页脚的商业文档
- 图文混排的技术手册
解决方案是采用分层处理策略：
- 使用Unstructured或LayoutLM进行视觉区块检测
- 对识别出的表格区域采用TSR（表格结构识别）技术
- 文本区块通过OCR或直接提取
python复制# 示例：使用pdfplumber处理PDF表格
import pdfplumber
with pdfplumber.open("document.pdf") as pdf:
for page in pdf.pages:
# 提取表格
table = page.extract_table()
# 提取文本
text = page.extract_text()
2.2 文本切分的艺术与科学
文本切分是RAG系统的核心环节，常见的陷阱包括：
- 将完整的句子拦腰截断
- 破坏表格的结构完整性
- 忽略文档的层级关系
进阶切分策略对比：
| 切分方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 递归字符切分 | 保留段落结构 | 可能切断长句 | 普通文档 |
| 语义切分 | 话题完整性高 | 计算成本高 | 高价值文档 |
| QA切分 | 检索精度高 | 预处理成本高 | FAQ知识库 |
| 表格专用切分 | 保留二维结构 | 需要特殊处理 | 表格密集文档 |
实战建议：对于技术文档，我推荐先按Markdown标题层级切分，再对每个章节应用递归切分。这样既保留了文档结构，又控制了chunk大小。
2.3 表格处理的工程实践
表格是文档处理中最棘手的部分之一。经过多个项目的锤炼，我总结出以下最佳实践：
- 结构保留优先：使用HTML或Markdown格式存储表格
- 多向量检索：为表格生成文本摘要用于检索，保留原始表格用于生成
- 行级兜底策略：对超大表格，确保每行数据都携带表头信息
python复制# 表格处理示例
def process_table(table):
# 转换为Markdown
markdown = "|" + "|".join(table[0]) + "|\n"
markdown += "|" + "|".join(["---"]*len(table[0])) + "|\n"
for row in table[1:]:
markdown += "|" + "|".join(row) + "|\n"
return markdown
3. LangChain与LangGraph的实战应用
3.1 模块化设计理念
LangChain的核心价值在于其模块化设计，主要组件包括：
- Document Loaders：支持100+文档格式
- Text Splitters：多种切分策略
- Vectorstores：与主流向量数据库集成
- Retrievers：高级检索算法
3.2 复杂Agent系统构建
使用LangGraph构建Agent系统时，关键是要理解其状态机模型。一个典型的ReAct Agent包含以下组件：
- Planning Node：决定下一步行动
- Action Node：执行具体操作
- Observation Node：处理返回结果
python复制from langgraph.graph import Graph
from langgraph.nodes import Node
# 定义节点
planning = Node("planning", plan_next_step)
action = Node("action", execute_tool)
observation = Node("observation", process_result)
# 构建工作流
workflow = Graph()
workflow.add_node(planning)
workflow.add_node(action)
workflow.add_node(observation)
workflow.add_edge(planning, action)
workflow.add_edge(action, observation)
workflow.add_edge(observation, planning)
3.3 性能优化技巧
- 异步处理：对IO密集型操作使用async/await
- 缓存策略：对频繁访问的文档片段缓存Embedding
- 批量处理：将多个小请求合并为批量请求
4. 模型部署与推理优化
4.1 推理框架选型指南
根据项目需求选择合适框架：
| 框架 | 优势 | 适用场景 |
|---|---|---|
| vLLM | 高吞吐，兼容OpenAI API | 生产环境服务 |
| TensorRT-LLM | 极致性能 | 高并发场景 |
| Ollama | 简单易用 | 本地开发测试 |
4.2 Qwen模型部署实战
部署Qwen3.5时的关键注意事项：
- 资源评估：7B模型需要约16GB显存
- 上下文长度：根据业务需求设置合理值
- 量化选项：INT8量化可减少显存占用
bash复制# 使用Ollama运行Qwen
ollama pull qwen:7b
ollama run qwen:7b --num_ctx 2048
4.3 多模型部署策略
当需要在同一服务器部署多个模型时：
- 显存隔离：使用CUDA MPS或Docker资源限制
- 动态加载：按需加载模型，及时释放闲置模型
- 请求路由：根据请求类型分发到不同模型实例
5. 评估与优化方法论
5.1 RAG评估指标体系
使用Ragas框架时重点关注：
- Faithfulness：回答是否基于检索内容
- Answer Relevance：回答是否切题
- Context Precision：检索内容是否相关
5.2 检索优化技巧
- 混合检索：结合稠密向量和稀疏向量
- 查询扩展：使用LLM生成相关查询
- 重排序：对初步检索结果进行精排
python复制# 混合检索示例
from rank_bm25 import BM25Okapi
from sentence_transformers import SentenceTransformer
# 初始化模型
bm25 = BM25Okapi(tokenized_docs)
encoder = SentenceTransformer('bge-small')
# 检索
bm25_scores = bm25.get_scores(query)
dense_scores = cosine_similarity(
encoder.encode(query),
doc_embeddings
)
combined_scores = 0.7*dense_scores + 0.3*bm25_scores
6. 实战经验与避坑指南
在多个RAG项目落地过程中，我积累了一些宝贵经验：
文档预处理：
- 对扫描件使用PaddleOCR+TSR组合
- 处理PDF时优先尝试提取原生文本
- 对复杂文档采用"解析-清洗-转换"流水线
表格处理：
- 始终保留表头信息
- 对超大表格采用"摘要+详情"策略
- 使用HTML表格保持二维结构
性能优化：
- 对静态知识库预计算Embedding
- 实现检索结果缓存
- 对长文档采用分层索引
一个典型的踩坑案例：在某金融项目中，我们直接使用字符切分器处理财报PDF，导致表格数据支离破碎。解决方案是先用Camelot提取表格，再单独处理文本部分，最后通过多向量检索整合。
7. 技术选型决策框架
面对琳琅满目的技术选项，我建议采用以下决策流程：
- 需求分析：明确业务场景和技术要求
- 约束评估：考虑算力、预算和时间限制
- 原型验证：快速验证关键技术方案
- 全链路测试：评估端到端效果
- 渐进式优化：持续迭代改进
例如选择Embedding模型时，考虑��素包括：
- 支持的语言
- 输入长度限制
- 推理延迟
- 微调成本
在最近的一个多语言项目中，我们最终选择了bge-m3模型，因为它在保持768维适中大小的同时，支持100+语言，且对长文本处理良好。