概述
缺点:成果转化系统没法落地。都是自己想象的空中楼阁,但是也许我可以开源到网上部署到服务器上,竞品https://www.1633.com/。登科总录和智能客服都是以落地为目标在不断迭代的,可以着重点名,不过两个都偏工程,可以提现技术栈。其中登科总录是Dify,智能客服是AI全流程。Ascend Lavis和无障碍量体都是科研项目,一个表现异构和优化,一个表现机器训练学习的科研能力。接下来再做一个偏硬件的优化性能提升。区块链放最后。主要是知识丰富。
embedding
Embedding 过程:123456789101112131415161718192021222324252627282930313233343536373839404142文本输入 │ ▼┌────────────────────────────────────────┐│ 1. Tokenization (分词) ││ "苹果手机屏幕碎了怎么办?" ││ → ["苹果", "手机", "屏幕", "碎", ...]│└────────────────┬───────────────────────┘ │ ▼┌────────────────────────────────────────┐│ 2. Token Embedding ││ 每个token转换为初始向量 ││ ...
Agentic RAG
超越扁平化文本分块,构建反映知识内在层次和关联的结构化索引 RAPTOP 树状关联图叶子细节,根总结 GraphRAG网络关联图实体,关系通过社区发现算法找出语义上关联的集群,生成摘要。 智能体RAG传统RAG是单向数据流,非智能智能体RAG把知识库检索封装为工具,Agent像ReAct一样,进行”思考,行动,观察“的循环。知道观察到判断已经收集充分的信息,才会综合所有检索的上下文,生成答案。
数据处理
面对企业里最常见的“表格数据”(Excel、数据库表),大模型(LLM)其实很难直接“理解”或“检索”它们。为了让大模型能用上这些数据,工程师们总结出了这两条完全不同的技术路线:一是将部分关键字段按照特定的文本模板拼成一个text段落,去构建文本知识库:这样可以模糊语义搜索,但是丢失精确性:你没法问“GPA 大于 3.5 的人有多少个?”这种数学问题 二是利用Text2SQL的技术,直接去查询结构化数据库表进行生成。不移动数据,而是教大模型写 SQL 语句,让它直接去指挥数据库干活。为了“精确统计”和“逻辑运算”。但是对于复杂表大模型写的SQL可能就会报错或者查不出数据。 检索时:用小切片(Chunk),因为它语义聚焦,更容易匹配到准确的锚点。 生成时:用扩展后的长文本(Context),因为它包含前因后果,LLM 读起来更连贯,幻觉更少。 在建立支持双层检索(Milvus +...
向量搜索前沿调研
Milvus 提供支持Milvus 是一个开源的向量检索中间件,支持常见的向量检索场景,具备以下特点: 支持基于 Python / Java / Go / C++ 的 SDK 和 RESTful API 支持 Annoy、Faiss、HNSW 等多种算法库 支持 CPU 和 GPU 运算 以 collection 为基本的管理单元,在 collection 中再划分 partition 为基准,支持粗粒度与细粒度的数据管理 支持原始向量存储与查询近似最近邻(ANN)向量搜索:有用过谷歌的 Vertex AI 向量搜索, 也试过用Apache Solr 的 ANN 向量搜索处理一些大数据集,还有在垂直扩展的边缘节点里部署 Facebook 的 FAISS 库,专门应对小数据集。 性能:月活11亿的Reddit ,怎么选向量数据库:Pgvector、Redis、Milvus、QdrantReddit的案例主要讲了选向量数据库从需求到评估到测试到选用的全过程: 需求:功能需求?向量和关键词搜索,标签检索,按非向量属性过滤非功能需求?存 10...
检索
本质上都是最近邻检索 Aproxingmate Nearest Neighbor. ES检索(关键字检索)通过paddle的实体抽取模型,从Query中抽取实体信息的关键字段,在ES检索的时候进行不同的加权,ES返回匹配的source文档集合,source可以认为是doc向量索引的parent_id。 向量检索向量查询本质上是将Query向量和collection中的所有向量进行相似度匹配,所以需要确定一个相似度指标,比如欧氏距离、Cosine相似度等。当向量都在单位球面上(即长度为1)时,直线距离(欧氏距离)越短,夹角(余弦相似度)就越小,两者是严格单调转换关系。两个方法严格成反比。 L2 归一化 (L2 Normalization): 它的作用就是把所有长长短短的向量,全部“缩放”到这个单位球的表面上。无论原来的向量多长,归一化后,它们的模长(Length/Norm)都变成了 1。把向量投影到单位球面上(L2 归一化),实际上是会损失信息的。我们丢失了向量的“模长,但在现代深度学习(特别是 NLP 和 Embedding...
知识库构建
先进行数据收集和处理再向量化Embedding后建立索引,这样就构建好知识库了 Embedding的 dense索引给文本数据构建索引,首先要基于清洗好的数据切分成不同的chunk块,每个chunk块称作是一个doc,这是构建向量的最小单位,然后使用Embedding模型在doc上编码出向量,存储到Milvus中并建好向量索引,此时一个知识库就构建好了。 基于ES在每个知识库上构建倒排索引
ReAct工作流
12345678910111213while True: # 每个Agent都有一个自己的死循环 # 1. 阅读收件箱(如果有消息就用 user 身份插进 context 中作为打断提示) # 2. 调用大模型 API 思考 response = client.messages.create(...) # 3. 决定是否调用了工具 if response.stop_reason != "tool_use": break # (或者 return) # 4. 执行自己手里的工具箱并收集结果 for block in response.content: output = handler(...) results.append({"type":"tool_result", ... output}) # 5. 把结果还给 Context,进入下一轮 ...
skill
“用到什么知识, 临时加载什么知识” – 通过 tool_result 注入, 不塞 system prompt。第一层: 系统提示中放技能名称 (低成本)。第二层: tool_result 中按需放完整内容。 123456789SYSTEM = f"""You are a coding agent at {WORKDIR}.Skills available:{SKILL_LOADER.get_descriptions()}"""TOOL_HANDLERS = { # ...base tools... "load_skill": lambda **kw: SKILL_LOADER.get_content(kw["name"]),}TOOLS = [ {"name": "load_skill", "description":...
索引
索引方法如果没有索引,每次你在数据库中搜索“类似图片”或“相关文档”时,计算机必须进行暴力搜索(Flat Search / Brute Force),即把你的查询向量和库里的 1 亿个向量逐一对比计算距离。这在数据量大时是不可接受的 索引的作用,就是通过牺牲一点点精度(从 100% 降到 99%),换取几百倍甚至几千倍的搜索速度提升。 这被称为 ANN(Approximate Nearest Neighbor,近似最近邻搜索)。 Elasticsearch (文本的王者): 倒排索引 (Inverted Index) 原理: 就像书籍末尾的“索引页”。 存储方式: 它不存“文章 1 -> 关键词”,而是存“关键词 -> 出现在哪些文章里”。 例子: 单词 “Python” -> [Doc_1, Doc_5, Doc_9]。 优势: 它是为了精确匹配 (Exact Match) 设计的。查找包含特定单词的文档,速度是 O(1)...

