<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Keming on Vchord</title>
    <link>https://vchord.pgsty.com/authors/keming/</link>
    <description>Recent content in Keming on Vchord</description>
    <generator>Hugo</generator>
    <language>en-US</language>
    
    
    
      <lastBuildDate>Tue, 03 Nov 2026 01:15:06 +0800</lastBuildDate>
    
    
      <atom:link href="https://vchord.pgsty.com/authors/keming/index.xml" rel="self" type="application/rss+xml" />
    
    <item>
        <title>Optimize RAG with Contextual Retrieval in PostgreSQL</title>
        <link>https://vchord.pgsty.com/blog/post/optimize-rag-with-contextual-retrieval-in-postgresql/</link>
        <pubDate>Fri, 30 May 2025 00:00:00 +0000</pubDate>
        
        <guid>https://vchord.pgsty.com/blog/post/optimize-rag-with-contextual-retrieval-in-postgresql/</guid>
        <description>&lt;p&gt;In the standard approach to Retrieval Augmented Generation (RAG), a common practice is to break down large documents into smaller, more manageable chunks. This is primarily done to improve the efficiency of the retrieval process, leveraging the sentence embedding and keyword bm25 scoring, allowing systems to quickly find and pull relevant pieces of information. While effective in many scenarios, this method can introduce a significant challenge: the potential for individual chunks to lose their surrounding context.&lt;/p&gt;</description>
      </item>
    <item>
        <title>Introducing Vechord: Turn PostgreSQL into your search engine in a Pythonic way.</title>
        <link>https://vchord.pgsty.com/blog/post/introducing-vechord-turn-postgresql-into-your-search-engine-in-a-pythonic-way/</link>
        <pubDate>Wed, 23 Apr 2025 00:00:00 +0000</pubDate>
        
        <guid>https://vchord.pgsty.com/blog/post/introducing-vechord-turn-postgresql-into-your-search-engine-in-a-pythonic-way/</guid>
        <description>&lt;p&gt;Today, we&amp;rsquo;re thrilled to announce the release of &lt;a href=&#34;https://github.com/tensorchord/vechord&#34;&gt;&lt;strong&gt;Vechord&lt;/strong&gt;&lt;/a&gt;, a new Python library designed to dramatically simplify building robust search infrastructure directly on top of the PostgreSQL database.&lt;/p&gt;&#xA;&lt;p&gt;In the rapidly evolving world of AI and large language models (LLMs), Retrieval-Augmented Generation (RAG) and semantic search have become crucial components. However, setting up the necessary vector search infrastructure often involves learning new database technologies, managing complex integrations, or wrestling with intricate frameworks. This adds friction and slows down development, especially for teams already comfortable with PostgreSQL.&lt;/p&gt;</description>
      </item>
    <item>
        <title>VectorChord 0.3: Bringing Efficient Multi-Vector Contextual Late Interaction in PostgreSQL</title>
        <link>https://vchord.pgsty.com/blog/release/vectorchord-03-bringing-efficient-multi-vector-contextual-late-interaction-in-postgresql/</link>
        <pubDate>Sun, 13 Apr 2025 00:00:00 +0000</pubDate>
        
        <guid>https://vchord.pgsty.com/blog/release/vectorchord-03-bringing-efficient-multi-vector-contextual-late-interaction-in-postgresql/</guid>
        <description>&lt;p&gt;We&amp;rsquo;re thrilled to announce the release of &lt;strong&gt;VectorChord 0.3&lt;/strong&gt;, a major milestone that significantly boosts the performance and applicability of advanced vector search techniques directly within your Postgres database! Building on our 0.2 release, which brought ARM support and faster indexing, version 0.3 tackles one of the biggest hurdles in modern retrieval: &lt;strong&gt;efficient multi-vector search with late interaction&lt;/strong&gt;.&lt;/p&gt;&#xA;&lt;h3 id=&#34;beyond-single-vectors-why-multi-vector-rocks&#34;&gt;Beyond Single Vectors: Why Multi-Vector Rocks&#xA;&lt;/h3&gt;&#xA;&lt;p&gt;For years, vector search primarily represented entire documents or queries as single, dense vectors. While powerful, this approach involves averaging or compressing complex information into one representation, inevitably leading to a loss of nuance. Imagine trying to capture the entire meaning of a detailed technical document in a single sentence – you&amp;rsquo;d lose specifics!&lt;/p&gt;</description>
      </item>
    <item>
        <title>Supercharge vector search with ColBERT rerank in PostgreSQL</title>
        <link>https://vchord.pgsty.com/blog/post/supercharge-vector-search-with-colbert-rerank-in-postgresql/</link>
        <pubDate>Thu, 23 Jan 2025 00:00:00 +0000</pubDate>
        
        <guid>https://vchord.pgsty.com/blog/post/supercharge-vector-search-with-colbert-rerank-in-postgresql/</guid>
        <description>&lt;p&gt;Traditional vector search methods typically employ sentence embeddings to locate similar content. However, generating sentence embeddings through pooling token embeddings can potentially sacrifice fine-grained details present at the token level. &lt;a href=&#34;https://github.com/stanford-futuredata/ColBERT&#34;&gt;ColBERT&lt;/a&gt; overcomes this by representing text as token-level multi-vectors rather than a single, aggregated vector. This approach, leveraging contextual late interaction at the token level, allows ColBERT to retain more nuanced information and improve search accuracy compared to methods relying solely on sentence embeddings.&lt;/p&gt;</description>
      </item>
    <item>
        <title>Benefits and Steps of External Centroids Building in VectorChord</title>
        <link>https://vchord.pgsty.com/blog/post/benefits-and-steps-of-external-centroids-building-in-vectorchord/</link>
        <pubDate>Tue, 10 Dec 2024 00:00:00 +0000</pubDate>
        
        <guid>https://vchord.pgsty.com/blog/post/benefits-and-steps-of-external-centroids-building-in-vectorchord/</guid>
        <description>&lt;p&gt;Clustering is an important component in vector search, and the k-means algorithm remains one of the most widely used techniques. However, its simplicity comes with a significant drawback: resource-intensive computation can render it impractical for large datasets. This blog explores why this challenge arises and how leveraging external builds to overcome it. We also share insights into our approach to implementing this solution.&lt;/p&gt;&#xA;&lt;h3 id=&#34;why-we-need-it&#34;&gt;Why we need it&#xA;&lt;/h3&gt;&#xA;&lt;img class=&#34;td-image&#34; src=&#34;https://cdn.hashnode.com/res/hashnode/image/upload/v1733711948118/a8ca38d3-580f-4f20-90b9-03c826289a7c.png&#34; alt=&#34;&#34; loading=&#34;lazy&#34; decoding=&#34;async&#34;&gt;&lt;p&gt;VectorChord uses IVF + RaBitQ to perform vector search. The quality of the IVF cluster can heavily affect search precision and speed. K-means usually takes dozens of rounds before convergence. For each round, all the sampled vectors need to be assigned to the nearest cluster. This is the most computationally intensive part. The good news is that this process can be easily parallelized.&lt;/p&gt;</description>
      </item>
    
  </channel>
</rss>
