pdf
这一块目前做的太粗糙了 3. 核心短板：Embedding 模型过于“复古”位置： backend/services/vector_service.py现状： 1self._model_name = 'paraphrase-multilingual-MiniLM-L12-v2' 面试官点评： “这个模型是 2019-2020 年左右的产物了。在 2025 年（假设现在的时间点），它的语义理解能力、特别是对长文本和专业术语（如 ‘LoRA’, ‘PPO’）的表征能力，已经被新模型甩开几条街了。你的 RAG 检索质量上限被这个模型锁死了。”优化方案： 开源SOTA：换成 **BAAI/bge-m3**（支持多语言、长文本、稀疏检索混合）。 闭源SOTA：直接调 OpenAI text-embedding-3-small 或 DeepSeek 的 Embedding 接口（如果有）。 代码改动：只需要改一行 model_name，性价比极高。 4. 潜在雷区：PDF 解析器的鲁棒性位置：...
prompt
“泛化（Generic）”是查询扩展（Query Expansion/HyDE）最大的杀手：- LLM 倾向于生成“平均脸”。对于“提高推理速度”，它会生成“我们提出了一个高效的Transformer架构……”。 现实： 你的库里那篇 CALM (2510.27688) 用的不是“标准高效Transformer”，而是 “Continuous Autoregressive”（连续自回归） 和 “Autoencoder”（自编码器）。 差异： “通用高效”的向量与“连续自回归”的向量在空间上可能离得很远。需要让 LLM 做 “技术路线头脑风暴”，而不是写八股文。我们要它列出所有可能解决这个业务问题的技术流派（比如：量化、剪枝、非自回归、SNN、投机采样等），把这些具体的“硬核术语”塞进 Query 里 Query Expansion 负责把网撒得更宽（覆盖更多技术流派）。 Top N 负责把这些流派对应的论文都捞上来。 Listwise Rerank 负责把真正靠谱的挑出来。 把 Prompt 从 “读后感模式” 升级为...
resume_project
项目经历 - 简历版🚀 AI论文智能匹配系统 - 全栈独立开发项目时间：2024.09 - 2024.12项目规模：前后端代码量 15,000+ 行，6个核心模块，10+ API接口技术栈：Python、FastAPI、Vue3、ChromaDB、DeepSeek LLM、SQLite、Redis项目角色：全栈工程师（需求分析、架构设计、开发实现、测试部署） 📋 项目背景企业技术需求与学术研究成果之间存在信息鸿沟，传统文献检索系统仅支持关键词匹配，无法理解用户的业务需求。本项目旨在构建一个基于RAG技术的智能论文匹配平台，实现企业需求与科研成果的精准对接。 💼 核心职责与技术实现1. 系统架构设计与实现（独立负责）技术决策： 设计三层异步并发架构（asyncio事件循环 + 线程池 + 多进程池），单机支持 50+ 并发用户 采用微服务化思想设计6大业务模块（匹配、LLM、向量检索、PDF解析、爬虫、认证） 实现混合任务调度：本地模式（asyncio.create_task）+ 分布式模式（Redis + ARQ），支持弹性部署 技术亮点： 123456#...
幻觉
测试还有幻觉问题，我应该问一些跟这些论文领域相关，但论文里通过只字未提的问题。RAG 应该返回 **”相关度低”**，而不是强行编造一个答案。 除了常规的召回测试，我还引入了拒识机制（Rejection Mechanism）的评估。我构建了 20% 的负样本问题，验证系统在知识缺失时是否能避免幻觉。测试结果显示，在 Re-rank 分数低于 0.3 时截断，能有效拦截 90% 的无效问题。” 解决强化prompt，静止套话1你的核心原则是：**Evidence-Based Engineering（基于证据的工程）**。 ❌ 严禁生成：“我们将使用最先进的模型”、“使用标准的数据清洗流程”这种废话。 ✅ 必须具体：“基于Paper_1的分析，我们将采用其提出的 'Gated-Attention' 机制，而非标准的 Self-Attention，因为Paper_1指出前者在长文本下显存占用降低了40%。” 如果论文中没有提到具体技术栈，请明确说明“论文未提及，建议使用通用方案”，而不是假装那是论文里的内容。
DevOps
性能监控
高并发，性能优化
优化后的当前架构 TD12345678910111213141516171819User((用户)) -->|1. 搜索请求 (等待)| API[FastAPI Server]subgraph "FastAPI 进程内 (Asyncio)" API -->|并发| Search[向量搜索] API -->|并发| Expand[Query扩展] Search & Expand -->|合并结果| Candidates[候选论文] Candidates -->|并发| Rerank[LLM 重排序 (httpx)]endRerank -->|2. 直接返回结果 (2-3s)| UserUser -->|3. 生成详细报告 (不等待)| APIAPI -->|4. 丢入队列| Redis[(Redis)]subgraph "后台 Worker" Redis -->|5. 领取任务| Worker[Worker 进程] Worker...
并发
Redis多级缓存
RAG
不倾向使用 RAGflow 而选择直接基于 Milvus 进行定制化开发，核心原因在于定位差异和深度不臃肿，流程定制化，测试调优掌控力高定制需求： 定位完全不同（组件 vs. 框架） Milvus 是基础的向量数据库（基础设施层），只负责存取和比对向量。 RAGflow 是端到端的 RAG 编排框架/应用。它打包了文档解析、切分、向量化和检索全流程。事实上，RAGflow 底层也需要依赖 Elasticsearch、Milvus 或其他向量库来存储数据。 双层检索架构与 Text2SQL 的深度定制 你的系统设计了高度定制化的 Milvus (语义泛化) + PostgreSQL + Text2SQL (精准业务查询) 双链路，并且有独特的业务混合策略（如“70%商品名+30%语义”的定制排序）。 RAGflow 这种开箱即用的框架主要强项在于纯文档的深度解析（Deep Document...
异构
前端后端架构：controller,service,repositoryservice: pipeline chain(keyword,rewrite,RAG,replacement) 平台123456789101112// 前端平台映射const platformMap = { tb: { // 淘宝 type: "client", name: "千牛", url: "qianniu://" }, jd: { // 京东 type: "web", name: "京东咚咚", url: "https://im.jd.com/" }, electron
Dify
Dify 或 LangChain 的可视化工作流编辑器。