gyx's blog

AI 如何“主动”调用工具？（核心机制） AI 并不是真的“看到”了搜索按钮，而是通过 Function Calling（函数调用） 机制实现的： 配置描述：你给 AI 一个工具（如 Google 搜索），并配上一段描述：“这个工具可以查询实时新闻”。 模型判断：当用户问“今天金价多少？”，模型发现自己的训练数据（离线）回答不了，但对比发现“搜索工具”的描述符合需求。 输出指令：模型会输出一段特定格式的代码（JSON），告诉系统：“我要调用 Google 搜索，参数是：‘今日金价’”。 执行与返回：后台自动运行搜索，把结果塞回给 AI，AI 总结后再回答你。 具体操作：让 Agent 动起来的三个阶梯第一步：配置“工具箱”（Tools） 在 Dify 的“工具”页签中，你需要完成以下操作： 添加 API Key：接入如 Serper 或 Tavily（专门给 AI 用的搜索引擎），或者 Code Interpreter（代码解释器）。 授权给应用：在你的 Agent...

可靠性1.部件错误，偶发性错误，间歇性错误，永久性错误。系统要容错2.系统失效，处理机错误：fail-silent错误，byzantine错误3.同步与异步系统容错：同步是系统能在确定时间内对一个消息做出响应。异步很难进行容错处理，因为不知道响应时间的上界。解决容错的方式是冗余。海明码，重传，备份（冗余处理机）。指标：MTTF 组织冗余处理机：主动复制（多个处理器完全并行同时工作，一部分失效其他继续工作。所有服务器看作一个大的有限状态机+表决器）；2k+1个服务器可以实现k容错。需要全局顺序编号，保证命令到每个服务器到达顺序一样。 主从备份（一个作为服务器，一个失效，另一个代替）。 若主服务器在处理完请求消息之后并将更新消息发送给备份服务器之后崩溃了◼ 在备份服务器取代主服务器后，该请求消息会再次从客户端传到主服务器，于是该请求消息就会被处理两次。◼ 若这个处理有副作用的话，那么，就可能产生问题。 若主服务器在第4步之后第6步之前崩溃的话，那么，这个请求消息要被执行三次：◼ 第2步主服务器执行一次；◼ 第4步备份服务器执行一次；◼...

核心观点：Redis 解决的不是“CPU 忙不忙”，而是“HTTP 连接能不能等”。我们把你的 RAG 系统拆解来看： 场景一：CPU 密集型任务（PDF 解析、OCR） 现象：服务器 CPU 飙升到 100%，风扇狂转。 如果不加 Redis： Python 的 GIL（全局解释器锁）会导致主线程卡死。 API 服务器完全失去响应，连简单的“健康检查”接口都回不了。 后果：系统崩溃（Crash / Unresponsive）。 Redis 的作用：“隔离”。把重活扔给 Worker 进程，保住 API 服务器的命。 场景二：I/O 密集型任务（DeepSeek / OpenAI 生成方案） 现象：CPU 占用率极低（可能只有 1%），因为服务器只是在傻傻地等待 DeepSeek 返回数据。 如果不加 Redis： HTTP 超时（Timeouts）：这是最致命的。浏览器、Nginx 网关、负载均衡器通常都有 60秒 的默认超时时间。如果 DeepSeek 生成一个长方案需要 90秒，前端连接会被直接切断，用户看到“504...

LRU 123456789101112131415161718class LRUCache:    def __init__(self, capacity: int):        self.cap=capacity        self.list=OrderedDict()    def get(self, key: int) -> int:        if key in self.list:            self.list.move_to_end(key)            return self.list[key]        else:            return -1    def put(self, key: int, value: int) -> None:        if key in self.list:            self.list[key]=value            self.list.move_to_end(key)        else:           ...

一些概念：GIL (全局解释器锁)影响对象：多线程 (Threading)这不是 Python 语言本身的问题，而是 CPython 解释器（官方默认版）的历史遗留问题。为了防止内存管理（垃圾回收机制）出错，它必须保证同一时刻只有一个线程在操作内存。对于CPU密集任务，这个是不好的，因为过一段时间就会强制换出，多线程算数换入换出的时间还不如完全单线程快。对于IO密集，是好的，因为GIL 很智能：只要你在“等”（IO 操作），你就必须换 Event Loop主线程运行同步任务被阻塞。应该把可异步的阻塞任务都await掉，把同步的阻塞任务都扔线程池，或者通过aiosqlite换成异步驱动的相应操作 协程asyncio(协作式调度)高并发IO密集(爬虫,接口服务)协程和线程的主要区别就是await,显式表明了切换是自愿的才能切.有点像js async def fn(): 定义一个协程函数 await something 表示这一步可能要等 I/O，等的时候我可以去干别的任务 await asyncio.sleep(1)（睡觉时把执行权让给别人） await...

Prometheus 与 Grafana 深度技术研究报告摘要本报告旨在为读者提供关于 Prometheus 和 Grafana 这两大云原生监控核心工具的全面技术分析。作为现代可观测性技术栈的基石，Prometheus 负责指标的收集、存储和告警，而 Grafana 则专注于数据可视化和仪表盘展示。本报告将从架构原理、核心组件、高可用部署、安全加固、告警体系等多个维度进行深入探讨，并结合 Kubernetes 环境下的实际部署场景，为生产环境实施提供详尽的最佳实践指导。 第一章：引言与背景1.1 云原生监控的演进在现代微服务架构和容器化技术的推动下，传统的监控系统已经难以满足动态、弹性、分布式环境下的可观测性需求。Prometheus 作为云原生计算基金会（CNCF）的毕业项目，已经成为 Kubernetes 环境中监控的事实标准。Grafana 则以其强大的可视化能力和多数据源支持，成为展示监控数据的首选平台。 Prometheus 的设计理念深受 Borgmon 启发，采用拉取模式的指标采集方式，配合多维数据模型和强大的查询语言...

缺点（作为生产级项目）： 太粗糙了，完全是 Demo 级别。核心问题： 你直接把 Title + Abstract 扔进去 embed。 粒度太粗： 如果论文摘要很长，语义会被稀释。 检索精度低： 没有 Chunking（切片），没有 Re-rank（重排序）。 1. 针对“RAG效果不够”的改进建议你现在的 RAG 是 Top-K Vector Search，在大厂里这叫 “Naive RAG”。要拿 Offer，你得升级成 “Advanced RAG”： **Step 1: 增加重排序 (Re-ranking) 向量检索出来的 Top-50 可能只有 Top-5 是真的相关的。 动作： 引入 BGE-Reranker (BAAI/bge-reranker-large)。先检索 50 个，用 Reranker 精排选前 5 个给 LLM。 Step 2: 混合检索 (Hybrid Search) 单纯向量检索对“专有名词”（比如特定的药物名、缩写）效果不好。 动作： 结合 BM25 (关键词检索) + Vector Search。ChromaDB...

简历项目描述模板版本一：技术深度版（推荐）基于 RAG 的学术论文智能匹配平台 | 技术负责人2024.XX - 2024.XX 核心技术：设计并实现 RAG（检索增强生成）架构，结合 Dense Retrieval 和 LLM Re-ranking 构建多阶段排序 Pipeline，实现企业需求与学术成果的智能匹配，匹配准确率提升 40% 向量化技术：基于 Sentence-Transformers 构建 384 维语义嵌入系统，使用 ChromaDB + HNSW 索引实现百万级论文的亚线性时间检索（<100ms），支持中英文混合语义理解 LLM 工程化：设计 Query Expansion 策略，通过 LLM 将业务需求转化为学术术语，提升召回率 30%+；实现 Listwise Learning to Rank，将精排速度提升 5 倍，API 调用次数从 50 次降至 4 次，成本降低 92% 性能优化：采用截断策略（Top-K Truncation）和批处理优化，通过异步并发控制，QPS 提升至 10+；实现 Graceful Degradation...

目前是一个最基础的框架，不管是嵌入还是向量检索都粒度非常的粗。我想先加一个Ragas对目前的效果进行评估，方便和未来优化后的做对比。Ragas 的评估需要四个要素： question: 用户的问题。 ground_truth: 人工写的标准答案（你需要自己准备几条）。 answer: 你的 RAG 系统生成的回答（你现在的代码只有检索，没有生成，我们需要补上这一环）。 contexts: 检索到的文档原文（注意：你之前的 search_similar 只返回了 ID 和分数，Ragas 必须要看原文内容才能判断检索准不准）。但是我没有标准答案，因为我不可能看过所有论文。我想到的办法是先用比较牛的AI读论文，然后让 AI 出题考 RAG 系统。这叫 “自动化评估集构建（Automated Evaluation Pipeline）”。在简历上写这一条，比写“人工标注数据”要高级得多，因为这代表你具备 MLOps（机器学习运维） 的思维。 读取你的文档，然后利用大模型自动生成三种数据： Question: 根据文档内容生成的复杂问题。 Ground Truth:...